- “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.
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.
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.
Possible Solutions: Above problem can be solved in 2 ways.