Setting existing entitlements in the entitlement catalog to false

[#1]

I had a question in class regarding a situation where the Entitlement Catalog had been built up over time to include all entitlements for a given enterprise. Unfortunately, this customer wanted to enable LCM at a later date and all the entries in their Entitlement Catalog were marked as requestable (this being the default when entitlements are loaded into the system.) They wanted a simple way to walk through all the entitlements in the catalog and set the requestable flag to "false".

Here is some rule code that will effectively accomplish this:

        import java.util.Iterator;

        import sailpoint.object.*;

        //

        // Find managed entitlements and iterate. Note, you could use queryoptions here to narrow the query to certain applications, etc.

        //

               QueryOptions qo = new QueryOptions();

               //qo.addFilter(Filter.eq("group",(Boolean)true));

               Iterator maResult = context.search(ManagedAttribute.class, qo);       

        //

        // Iterate through all the MAs  one at a time.

        //

                int count = 0;

                int commitLimit = 100;

               while (maResult.hasNext()) {

                   ManagedAttribute ma = (ManagedAttribute)maResult.next();

                   ma.setRequestable(false);

                   context.saveObject(ma);              

                   count++;

                   if ( (count %  commitLimit) == 0)  {

                               context.commitTransaction(); 

                   }

               }

              // commit the last remaining updates.

              context.commitTransaction();

              return "Processed  " + count + " objects.";

This will process EVERY SINGLE managed attribute object and set the requestable flag to false. The code also makes sure to commit the changes every 100 objects to conserve memory while processing through the managed attributes.

If you wanted to only set those entitlements that represent account groups, you could modify the QueryOptions filter as needed to only modify those specific entitlements:

Add a QueryOption filter like so:

qo.addFilter(Filter.eq("group",(Boolean)true));

Also, let's say you only wanted to do this for entitlements for an application called "AD", you could do the following:

qo.addFilter(Filter.eq("application.name","AD"));

Note that this rule could also be used to set the owner for each entitlement as well.

To set an owner, use the setOwner() method, just make sure to use an Identity object instead of the name to set the owner.

Enjoy!

[hari_mailvaganam]

Thanks Chris!

[#3]

Hi Chris,

The approach which you shared seem to be workaround that resolves my existing usecase. However I have couple of questions running at back of mind, which i'm not sure if it can be achieved with mere configuration. Please share your thoughts.

1. I have jdbc application with managed attribute for entitlementgroup and permissions defined in application schema.

2. when you run group aggregation on the jdbc app, it populates managed atttribute in entitlement catalog feature with default requestable.

3. I wanted to restrict these entitlement to be accessed by group of users ( not workgroups but list of users manually) only, so i defined scope on IIQ based on identity attribute (business logic) and assigned it users based on "Identity refresh on assigned scopes".

4. Now that we have hundreds of entitlements in catalog for which i don't want to associate scope manually, however i see with your rule approach i can set requestable, owner and also set scope for the entitlement based on IIQ API, but is there a way that we can associate a rule to group aggregation on the app, so that when any new entitlement grows in target system, through aggregate it automatically assigns scope to the entitlement, instead manually running rule each time.

5. Also does assigning scope at application level, does it inherit the same scope to entitlements belonging to the app, if so we dont have to deal with it at entitlement level

Thanks,

SM

[gaurav_jain]

Soochi,

I think "Managed Entitlement Customization Rule" rule is meant for this purpose.

Thanks,

Gaurav

[chris_hajdu]

There is a rule allowed for updating groups as you aggregate.

In your group aggregation add the line below:

<TaskDefinition name='Some Group Refresh'...>

       <Attributes>

         <Map>

            <entry key='accountGroupRefreshRule' value='Your Rule'/>

See How to set owner in accountgroup refresh rule

I'm not sure if assigning scope at the app level will trickle-down to the entitlements. Would need to try an experiment to see...

[chris_hajdu]

Managed Entitlement Customization Rule only runs the first time attributes are promoted, so keep that in mind.

[#7]

Thanks Chris... Assigning scope at application level, drills down the scope to entitlement as well. That's something cool.

[#8]

Is there an option inside of the Account Aggregation and/or Group Aggregation that will force the Managed Entitlement Customization rule to run on every managed attribute in the scope of the aggregation.  We have recently identified a native attribute that will hold group ownership.  Now I want to promote that attribute up to the ownership attribute in the Entitlement Catalog. 

Is it better to write a "true up" rule or refresh task (I'm also seeing the next discussion in this thread) to back fill the existing managed attributes, or manipulate the Managed Entitlement Customization to run on all entitlements.

Regardless of how we back fill existing attributes, it looks like the Managed Entitlement Customization rule is the correct place to promote the ownership of NEW entitlements.  Would you agree?

[chris_hajdu]

The rule you've mentioned was renamed to ManagedEntitlementPromotion rule in 6.2 to describe it's behavior a little better.

There are two options to accomplish what you want:

Look at ResourceObjectCustomization rule as a good hook to do what you want. This gets run every time you aggregate. In the UI, this is the rule listed as Customization Rule in the UI under the "Rules" tab of the application configuration.

Also look at my other post below regarding using the accountGroupRefreshRule. This could also be used to accomplish what you want.

The Rules in IdentityIQ.pdf whitepaper has details on each rule type AND examples of how to use them.

[madhu_kidambi]

Hi Chris,

Can I use the same code above to change the application Name of entitlements? (Say managedAttrib.setApplicationName("New Application Name");

Is it safe to call setApplication Name and context.saveObject without impacting Role/Identity assignments ?

Thanks,

Madhu

[chris_hajdu]

You can use that code to make that change and it will work, however, the impacts of doing so(especially how it impacts Role/Identity Assignments) would need to be tested thoroughly.

Personally, I would advise against doing so as there could be other ramifications that are unknown.

If you are just trying to change the application associated with the entitlements, why not just rename the Application itself which would have the same effect?