Idea ID: 2790536

Make It Scalable

Status: Accepted
The whole process around the population of entitlement values for consumption by User Application is inefficient and affects day to day transactions that are time critical (e.g. Password Changes).

The Entitlement policies that build items, such as the Group_Values MAP object, are slow and resource intensive when the number of groups exceeds just a few thousand. This not only stops other time critical transactions from occurring, but results in CODE MAP REFRESH timeouts and the data never becomes available to the User Application.

Two stages to allow migration/coexistence:

Stage 1: Create an "entitlement thread" within the engine that simply responds to query documents from the CODE MAP REFRESH call, does not get processed by policies, and allow the CODE MAP REFRESH to be scheduled (time of day as well as frequency) per entitlement.

Stage 2: Allow configuration of entitlement value "filters" for the query that CODE MAP REFRESH initiates within the User Application interface - "decoupling" the reliance on the driver specific code from User App and centralising the Entitlement process.
  • More than a year later this may have been fixed - but if so I have found nothing.

    For your stage 2 - if I read it correctly - you would like a means to include filters in the query that is sent to the connected Application - e.g. to be able to filter the group query to AD.

    I recently had to resolve an issue where our group entitlement returned over 40,000 groups from AD - did this by adding a policy to the subscriber CTP that captured the group query on its way out and injected XML to add a filter to the query.  Tried it successfully three different ways - "cn=ABC*", "info=IDMManaged" and "managedBy=dn of my service account" - as below

    <rule>
    <description>Group Query</description>
    <comment xml:space="preserve">Capture group entitlement query and filter for names staring ABC</comment>
    <conditions>
    <and>
    <if-operation mode="nocase" op="equal">query</if-operation>
    <if-xpath op="true">$current-op/@event-id='ENTITLEMENT:Group'</if-xpath>
    </and>
    </conditions>
    <actions>
    <do-append-xml-element expression="$current-op" name="search-attr"/>
    <do-set-xml-attr expression="$current-op//search-attr" name="attr-name">
    <arg-string>
    <token-text xml:space="preserve">cn</token-text>
    </arg-string>
    </do-set-xml-attr>
    <do-append-xml-element expression="$current-op//search-attr" name="value"/>
    <do-set-xml-attr expression="$current-op//search-attr/value" name="type">
    <arg-string>
    <token-text xml:space="preserve">string</token-text>
    </arg-string>
    </do-set-xml-attr>
    <do-append-xml-text expression="$current-op//search-attr/value">
    <arg-string>
    <token-text xml:space="preserve">ABC*</token-text>
    </arg-string>
    </do-append-xml-text>
    </actions>
    </rule>

     

  • I believe stage 1 is addressed in the Subscriber Service Channel in IDM 4.7.x. www.netiq.com/.../releasenotes_idm47.html
  • Agreed. We have several improvements in the work for the coming release and are very sensitive to issues seen around this. Thank you for the suggestions.