{"id":771,"date":"2019-05-21T14:45:37","date_gmt":"2019-05-21T10:15:37","guid":{"rendered":"http:\/\/www.enhisecure.com\/isecureblog\/?p=771"},"modified":"2019-05-21T14:45:37","modified_gmt":"2019-05-21T10:15:37","slug":"sailpoint-identity-attribute-configuration-challenges","status":"publish","type":"post","link":"https:\/\/www.enhisecure.com\/isecureblog\/2019\/05\/21\/sailpoint-identity-attribute-configuration-challenges\/","title":{"rendered":"SailPoint Identity Attribute – Configuration Challenges"},"content":{"rendered":"\n

Identity <\/a>attributes in SailPoint <\/a>IdentityIQ<\/a> are central to any implementation. They usually comprise a lot of information useful for a user’s functioning in the enterprise<\/a>.<\/p>\n\n\n\n

Purpose<\/strong>: The blog speaks about a rare way of configuring the identity <\/a>attributes in SailPoint <\/a>which would lead to a few challenges.<\/p>\n\n\n\n

Requirements Context:<\/strong> By nature, a few identity <\/a>attributes need to point to another identity<\/a>. 2 such use-cases would be:<\/p>\n\n\n\n

  1. “manager<\/a>” is an identity <\/a>attribute which refers to the manager <\/a>of the employee<\/a>\/contractor<\/a>.<\/li>
  2. “assistant<\/a>” can be a custom attribute which refers to the assistant <\/a>of the employee<\/a>\/contractor<\/a>. Action items of an employee<\/a>\/contractor <\/a>can be delegated to this assistant<\/a> when employee<\/a>\/contractor <\/a>is on a vacation.<\/li><\/ol>\n\n\n\n

    Any identity <\/a>attribute in IdentityIQ<\/a> can be configured as either searchable or non-searchable attribute. A searchable attribute has a dedicated database <\/a>column <\/a>for itself. In case of attributes like manager<\/a>, 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 <\/a>as searchable attributes would help are.<\/p>\n\n\n\n

    1. Finding list of identities <\/a>without managers<\/a>. <\/li>
    2. Finding a list of identities <\/a>with inactive managers<\/a>.<\/li><\/ol>\n\n\n\n

      However, usage of assistant <\/a>attribute is not quite similar. Not a lot of searching\/filtering would happen in a typical IAM <\/a>implementation based on assistant <\/a>attribute. It would be preferable to have this attribute as a non-searchable attribute.<\/p>\n\n\n\n

      Implementation:<\/strong> <\/p>\n\n\n\n

      As part of the implementation, an extended attribute is configured in the Identity <\/a>Configuration for assistant <\/a>attribute as follows.<\/p>\n\n\n\n

      \"\"
      Assistant identity attribute configuration<\/figcaption><\/figure>\n\n\n\n

      The following configuration details are to be observed.<\/p>\n\n\n\n

      1. Type of attribute is “Identity<\/a>“.<\/li>
      2. Identity <\/a>attribute is not configured to be searchable as there is no extended number that is configured on this attribute.<\/li><\/ol>\n\n\n\n

        Attribute population logic<\/strong><\/em>:<\/strong> The attribute is configured to fetch the <\/span>assistant<\/a> attribute from <\/span>Active Directory<\/a> application and populate the <\/span>assistant<\/a> attribute based on the <\/span>assistant <\/a>attribute from <\/span>Active Directory<\/a>.<\/span><\/p>\n\n\n\n

        Challenge faced<\/strong>: A specific challenge is faced when this type of configuration is used with identity<\/a> attributes.<\/p>\n\n\n\n

        Scenario<\/strong><\/em>:<\/strong> There will be certain situations where the assistant attribute in Active Directory<\/a> points to itself. For example, John.Doe’s assistant <\/a>would be John.Doe himself. This configuration has lead to failure of a lot of operations\/tasks due to a SailPoint <\/a>behavior described below.<\/p>\n\n\n\n


        Root Cause<\/strong><\/em>:<\/strong>         SailPoint <\/a>uses a hibernate <\/a>for object relational model<\/a>. Tables <\/a>in IdentityIQ <\/a>database <\/a>are represented by java <\/a>classes <\/a>in Identity IQ<\/a>. In this case, spt_Identity table <\/a>is represented by the class “sailpoint.object.Identity”. Objects of “sailpoint.object.Identity” class <\/a>shall correspond to rows in the “spt_Identity” table<\/a>. <\/p>\n\n\n\n

        SailPoint has to serialize <\/a>this Identity <\/a>objects in the process of storing them in the tables<\/a>. Non searchable attributes are all stored in an XML CLOB <\/a>in spt_Identity table<\/a>. As per the SailPoint’s <\/a>default behavior, non-searchable attributes are going to be serialized <\/a>in a recursive <\/a>fashion. Following the same, serialization <\/a>shall be attempted on the identity<\/a> pointed by the assistant <\/a>attribute.<\/p>\n\n\n\n

        In the scenario mentioned above where an identity <\/a>is his\/her own assistant<\/a>, a sub-serialization <\/a>of same identity <\/a>as part of assistant <\/a>attribute serialization <\/a>is attempted as shown in below diagram. <\/p>\n\n\n\n

        \"\"
        Recursive Serialization of assistant attribute<\/figcaption><\/figure>\n\n\n\n

        Possible Solutions<\/strong>: Above problem can be solved in 2 ways.<\/p>\n\n\n\n

        1. Adding checks to avoid self-references.<\/em>
          Logic to populate such type of           identity <\/a>attribute shall include a check to avoid self-referencing <\/a>of non-searchable identity <\/a>attributes.<\/li>
        2. Using Searchable attributes.<\/em>
          Avoiding the use of non-searchable attributes for           identity <\/a>attributes of type identity<\/a>.<\/li><\/ol>\n","protected":false},"excerpt":{"rendered":"

          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 […]<\/p>\n","protected":false},"author":2,"featured_media":781,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,15,14,16],"tags":[40,11],"class_list":["post-771","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-identity-governance","category-implementation-problems","category-sailpoint","category-technology","tag-active-directory","tag-sailpoint"],"_links":{"self":[{"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/posts\/771","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/comments?post=771"}],"version-history":[{"count":22,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/posts\/771\/revisions"}],"predecessor-version":[{"id":807,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/posts\/771\/revisions\/807"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/media\/781"}],"wp:attachment":[{"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/media?parent=771"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/categories?post=771"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.enhisecure.com\/isecureblog\/wp-json\/wp\/v2\/tags?post=771"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}