Lower case Email letter reformatting

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi All, I have added on to my Transform to now lowercase all of the email per a new requirement. I added it to the transform as it looks to be in documentation but It is not doing as such. Anyone has a second eye for me.? I just need to turn [email protected] to [email protected]

{
    "id": "",
    "name": "Non-employee email Transform",
    "type": "static",
    "attributes": {
        "ignoreErrors": "true",
        "value": "#if($status=='inactive')${email}x#{else}$email#end",
        "status": {
            "type": "identityAttribute",
            "attributes": {
                "name": "status"
            }
        },
        "email": {
            "type": "accountAttribute",
            "attributes": {
                "attributeName": "mail",
                "sourceName": "ACTIVE DIRECTORY NON-EMPLOYEE ACCOUNT SOURCE"
            }
        },
        "type": "lower",
        "name": "Lower Transform"
    },
    "internal": false
}
2

The lowered email wasn’t getting processed by your transform. Try this one where the lower is being applied to the accountAttribute.

{
    "id": "",
    "name": "Non-employee email Transform",
    "type": "static",
    "attributes": {
        "ignoreErrors": "true",
        "value": "#if($status=='inactive')${loweremail}x#{else}$loweremail#end",
        "status": {
            "type": "identityAttribute",
            "attributes": {
                "name": "status"
            }
        },
        "loweremail": {
            "type": "lower",
            "name": "Lower Transform",
            "attributes": {
                "type": "accountAttribute",
                "attributes": {
                    "attributeName": "mail",
                    "sourceName": "ACTIVE DIRECTORY NON-EMPLOYEE ACCOUNT SOURCE"
                }
            }
        }
    },
    "internal": false
}

Let us know if this works.

Alicia

2 Likes
3

Thanks - i see what you did and i should of put it before the call to the identity. Thanks a bunch

1 Like
4

So we hit a bump that not even i was aware. When the email is already on the users profile we are gold. X goes after when they are inactive and everything is lowercase. However when the system tries to create a new user that it finds in AD it errors on this transform for some reason which i am confused because the mapping on the profile should come before the transform as well the account is active so it should just leave it alone but to lower case it.

Browie points to the person that thinks they know the problem of the week…

5

Question; Is the email present on the identity when its coming from SOT?
If no then the issue is that you have to make a null check so that the condition when the user is active and email is empty we populate something like “N/A” depends what you decide.
Why is it happening?
Reason being email is a mandatory attribute on ISC, and if the user is active and does not have an AD account, the transform will try to write the value as empty which on ISC means that email is not present and identity runs into error.

try adding this statement at the first:
"value": "#if($loweremail=='')N/A#elseif($status=='inactive')${loweremail}x#{else}$loweremail#end"

Letme know if the scenario is something else and i went into different direction!

6

If the AD account is not correlated to the cube, then the code will fail, this can be fixed by popping in a first valid like this to catch the error:

"loweremail": {
    "type": "lower",
    "name": "Lower Transform",
    "attributes": {
        "type": "firstValid",
        "attributes": {
            "values": [
                {
                    "type": "accountAttribute",
                    "attributes": {
                        "attributeName": "mail",
                        "sourceName": "ACTIVE DIRECTORY NON-EMPLOYEE ACCOUNT SOURCE"
                    }
                },
                "XXX"
            ],
            "ignoreErrors": false
        }
    }
}
7

yes email is there every time as its needed in AD as well but something to think about down the road

8

Phil, I see what you are doing however the logic to add the email address along with the x when inactive isn’t in your logic. The email should be [email protected] when active but then change to [email protected]

again, this works when the user is already in the system and has that field however when the user gets created in IDN for the first time it will error out for some reason though the ad account has a email. It won’t pick it up and lower case it only as it is as active account.

9

hey got it, so

"status": {
            "type": "identityAttribute",
            "attributes": {
                "name": "status"
            }
        },

this particular one here is referencing identity attribute. But, if there’s a transform on status identity attribute as well then it may fail [as sailpoint also suggests that identity errors may occur by using identity attribute].
See the attached document. Identity Attribute | SailPoint Developer Community

So if there’s a transform attached to that status identity attribute, i would say rather use reference as the type. Reference | SailPoint Developer Community

Next, if there is no transform then maybe directly reference it as “accountAttribute”

Thanks

10

Sadly the new account will not first put the email address that is on AD before it does the lowercase and ignore the other logic that is related to inactive status. All users come and get create active. only users become inactive on end of contract or termed

This is like a bug but idk anymore…

11

Let me try these two as well. I thought the same think but what a pain

12

Just to clarify,

  • Is your AD source your HR source?
  • your code for “Non-employee email Transform” is a transform on an identity attribute and not on the CREATE source for the AD account?

Also, if you are using the following code exactly, you might want to remove the {} from this bit: ${loweremail}x, and put them round the ‘elseif’

"value": "#if($loweremail=='')N/A#elseif($status=='inactive')${loweremail}x#{else}$loweremail#end"

like this:

"value": "#if($loweremail=='')N/A#{elseif]($status=='inactive')$loweremailx#{else}$loweremail#end"

Not sure if that is what is catching you out

13

I know this is a pain tell me about.

This is for non-employees, The clinet uses AD as there HR source for them.

  1. All data is in an OU which contains the email

  2. SP pulls it in only (no provisioning is allowed back)

  3. The profile tries to create a user since it is new to SP and needs the IDN account

  4. Errors on email for some reason though email is on the AD account and the AD account is enabled
    Hope that helps

14

It might be because on account creation, there is no cube for the check to happen against your ‘status’ variable. I’ve stuck in a firstValid to catch any errors there.
Also, I’m also not sure that you can just add an ‘x’ without apache velocity thinking its a different variable.
This might work:

{
  "id": "",
  "name": "Non-employee email Transform",
  "type": "static",
  "attributes": {
    "value": "#if($status=='inactive')$loweremail + 'x'#{else}$loweremail#end",
    "status": {
      "type": "firstValid",
      "attributes": {
        "values": [
          {
            "type": "identityAttribute",
            "attributes": {
              "name": "status"
            }
          },
          "XXX"
        ]
      }
    },
    "loweremail": {
      "type": "lower",
      "attributes": {
        "type": "firstValid",
        "attributes": {
          "values": [
            {
              "type": "accountAttribute",
              "attributes": {
                "attributeName": "mail",
                "sourceName": "ACTIVE DIRECTORY NON-EMPLOYEE ACCOUNT SOURCE"
              }
            },
            "XXX1"
          ]
        }
      }
    }
  }
}
15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.