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:

1. “manager” is an identity attribute which refers to the manager of the employee/contractor.
2. “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.

1. Finding list of identities without managers.
2. 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.

Implementation:

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.

1. Type of attribute is “Identity“.
2. 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.

1. 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.
2. Using Searchable attributes.
   Avoiding the use of non-searchable attributes for identity attributes of type identity.