Identity attributes in SailPoint IdentityIQ are central to any implementation. They usually comprise a lot of information useful for a user’s functioning in the enterprise.
Purpose: The blog speaks about a rare way of configuring the identity attributes in SailPoint which would lead to a few challenges.
Requirements Context: By nature, a few identity attributes need to point to another identity. 2 such use-cases would be:
- “manager” is an identity attribute which refers to the manager of the employee/contractor.
- “assistant” can be a custom attribute which refers to the assistant of the employee/contractor. Action items of an employee/contractor can be delegated to this assistant when employee/contractor is on a vacation.
Any identity attribute in IdentityIQ can be configured as either searchable or non-searchable attribute. A searchable attribute has a dedicated database column for itself. In case of attributes like manager, we would ideally need a lot of filtering capability on the attributes and this makes a perfect case for being searchable attribute. A few use-cases where having manager as searchable attributes would help are.
- Finding list of identities without managers.
- Finding a list of identities with inactive managers.
However, usage of assistant attribute is not quite similar. Not a lot of searching/filtering would happen in a typical IAM implementation based on assistant attribute. It would be preferable to have this attribute as a non-searchable attribute.
As part of the implementation, an extended attribute is configured in the Identity Configuration for assistant attribute as follows.
The following configuration details are to be observed.
- Type of attribute is “Identity“.
- Identity attribute is not configured to be searchable as there is no extended number that is configured on this attribute.
Attribute population logic: The attribute is configured to fetch the assistant attribute from Active Directory application and populate the assistant attribute based on the assistant attribute from Active Directory.
Challenge faced: A specific challenge is faced when this type of configuration is used with identity attributes.
Scenario: There will be certain situations where the assistant attribute in Active Directory points to itself. For example, John.Doe’s assistant would be John.Doe himself. This configuration has lead to failure of a lot of operations/tasks due to a SailPoint behavior described below.
Root Cause: SailPoint uses a hibernate for object relational model. Tables in IdentityIQ database are represented by java classes in Identity IQ. In this case, spt_Identity table is represented by the class “sailpoint.object.Identity”. Objects of “sailpoint.object.Identity” class shall correspond to rows in the “spt_Identity” table.
SailPoint has to serialize this Identity objects in the process of storing them in the tables. Non searchable attributes are all stored in an XML CLOB in spt_Identity table. As per the SailPoint’s default behavior, non-searchable attributes are going to be serialized in a recursive fashion. Following the same, serialization shall be attempted on the identity pointed by the assistant attribute.
In the scenario mentioned above where an identity is his/her own assistant, a sub-serialization of same identity as part of assistant attribute serialization is attempted as shown in below diagram.
Possible Solutions: Above problem can be solved in 2 ways.
- Adding checks to avoid self-references.
Logic to populate such type of identity attribute shall include a check to avoid self-referencing of non-searchable identity attributes.
- Using Searchable attributes.
Avoiding the use of non-searchable attributes for identity attributes of type identity.