Hi,
For example, with the following transform in an Account Provisioning Policy:
{
"name": "contractType",
"transform": {
"type": "static",
"attributes": {
"empType": {
"type": "identityAttribute",
"attributes": {
"name": "employeeType"
}
},
"contractType": {
"type": "identityAttribute",
"attributes": {
"name": "contractType"
}
},
"value": "#if($empType && $contractType)[{\"id\":xxxx,\"value\":$contractType}]#{else}[]#end"
}
},
"attributes": {},
"isRequired": false,
"type": "string",
"isMultiValued": false
}
When creating an account, I get the following error:
An unexpected error occurred:
com.sailpoint.seaspray.template.TemplateException:
Invalid get reference: $contractType - seaspray [line 1, column 18]
This happens for external users because the contractType identity attribute is not mapped in the External Users Identity Profile.
The same configuration works correctly for internal users because the contractType identity attribute is mapped in the Internal Users Identity Profile.
I observed this behavior some time ago, and we’ve always worked around it by using for example a lookup transform with employeeType as input and returning an attribute only when it is mapped.
Currently, I am looking for a cleaner solution that would simply ignore unmapped identity attributes instead of throwing an exception when a transform references an idenity attribute that is not mapped in the Identity Profile.
Has anyone encountered this issue before? Do you have any recommendations or best practices for handling this scenario?
Thanks.
Hello @baoussounda
The reason you are getting an issue is because in the IF ELSE statements, you are checking for empty value which is not possible in the velocity syntax that you are using inside the static transform.
The best way to perform a null check is for variables named as “empType” and “contractType”, use a firstValid transform where 1st priority should be given to respective identity attribute and 2nd priority should be given to a static value such as “null” or “NA” or “N/A” something like that. And , in the IF ELSE logic, just make the required adjustment like if($empType != ‘NA’ && $contractType != ‘NA’), then, …
Hi @rohit_wekhande ,
Thanks for your response.
It seems like the error that we facing is not linked to if else statement, because many of our transforms use this same logic.
For example I have the same error with this :
{
"name": "contractType",
"transform": {
"type": "identityAttribute",
"attributes": {
"name": "contractType"
}
},
"attributes": {},
"isRequired": false,
"type": "string",
"isMultiValued": false
}
And it occur when the identity attribute is not mapped in the current identity Identity profiles.
And for this case, I make to not use directly an Identity Attribute when it is not mapped.
Thanks
Hello,
If the mapping is not there in identity profile, then, your IF ELSE statements will fail that way you have coded them. Hence, using the above approach which I have mentioned, you will get away from seaspray error irrespective whether the identity attr is mapped or not. Hence, use a FIRSTVALID transform inside your static transform input, give 1st priority to identity attr, give 2nd priority to account attr from authz source and provide a default value as 3rd priority, in this way, you can go ahead from seaspray exception, and your provisioning policy will work as expected.
Thanks @rohit_wekhande
I have also tested :
"name": "contractType",
"transform": {
"type": "static",
"attributes": {
"empType": {
"type": "identityAttribute",
"attributes": {
"name": "employeeType"
}
},
"contractType": {
"attributes": {
"values": [
{
"type": "identityAttribute",
"attributes": {
"name": "contractType"
}
},
""
]
},
"type": "firstValid"
},
"value": "[{\"id\":133,\"value\":$contractType}]#{else}[]#end"
}
},
"attributes": {},
"isRequired": false,
"type": "string",
"isMultiValued": false
}
When testing account creation for an external user, the error occurs as soon as $contractType is referenced. Since the corresponding Identity Attribute is not mapped in the Identity Profile, I get the same exception even when using a firstValid transform.
For internal users, however, the transform works correctly whether contractType contains a value, is empty, or is null, because the attribute is mapped in the Identity Profile.
It seems that ISC throws this exception during runtime when resolving the transform variables. If an Identity Attribute is not mapped in the Identity Profile, ISC is unable to resolve the reference and throws an exception instead of returning a null or empty value.
But when the value is referenced only for internal users, it has always worked :
"value": "#if($empType=='Internal')\[{\\"id\\":133,\\"value\\":$contractType}\]#{else}\[\]#end"
Hello @baoussounda ,
Just curious, If Identity attribute is not mapped in Identity Profile, Is that mean that there is no attribute/value for the contractType coming from auth source? If there is an attribute/value, why can’t we use account attribute transform instead?
@JackSparrow ,
We’re currently implementing this configuration in a new Account Provisioning Policy, and I’m in the process of testing account creation.
We are planning to synchronize the attributes, and we also have other Identity Profiles and more complex transforms to consider.
My initial approach was to use this Identity Attribute directly since it already contains the final value. However, we will also evaluating the option of working directly with account attributes from different authoritative sources.
I’ve observed this exception for quite some time, which is why I wanted to ask whether anyone has encountered it before or has any recommendations.
Thanks for the explanation @baoussounda !
Yes, if there is no mapping configured for the Contract Type in the External Users Identity Profile, it means that the identity does not have that attribute available.
If we try to retrieve the value using an Identity Attribute Transform for an attribute that does not exist on the identity, the transform will throw an error, which is what you are seeing now. In this scenario, even a null check cannot be performed because the attribute itself is unavailable.
I would recommend using an Account Attribute Transform along with a First Valid Transform