How to manage entitlement attributes - source code control? Rules?

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

I’m working to setup 8.5 in our DEV environment, but I’m thinking ahead to when I move code to QA and eventually Production. I’m not sure how to manage my entitlements. I read that since entitlements (Active Directory groups in my case) are dynamic data, most of which is aggregating in from the domain, that I don’t want to put these in source control. That makes sense, but how can I manage and promote the attributes that don’t aggregate in from the domain - things like the requestable status, owners and a custom attribute for requiring comments?

I know about the Group Aggregation Refresh rule and I have one in place to set the display name and description on the entitlements in IIQ from the values in the domain and that is a very simple rule and it’s working great. Should I try to use that rule to set the requestable status, owners and a custom attribute for requiring comments? My concern is that I’ll end up with a huge mess of if then statements or something similar because only certain entitlements are going to have owners and only certain ones will require comments. As far as requestable status, I still need to figure out how we’re going to manage that! But is this rule the right place to do this?

I’ve read all the documentation but haven’t really found anything that addresses this question. How do you manage it?

3

I think Group refresh rule is required to set owner and requestable fields.

Make sure to write optimized code to add logic.

4

@karen_delucia If you already know the entitlements before hand, you can also explore importing it via EntitlementCatalogue. This is an operational workaround and OOTB approach.

5

You are right the entitlements should not be part of source code since they are very dynamic and specific to each environment. But the logic (rules) that can set the metadata on entitlement (comments required, requestable, owners etc) should be in source code. Ideally the rule should set the metadata wherever it is sure. Any cases where the metadata cannot be decided unambiguously , it should be handled through manual intervention (bulk export/import or some kind of utility (run rule task) to do bulk update on metadata).

6

Thanks everyone for the responses. I’ll likely use a combination of rules and manual import/export to manage these. Good to know that I’m on the right track.

7

Yes, the Group Aggregation Refresh rule is an appropriate place to enrich entitlements with:

  • requestable status

  • owner

  • custom attributes

  • approval metadata

But:

  • you should avoid hardcoded if/then logic

  • and instead externalize the configuration.

That’s the scalable pattern most mature IIQ implementations use.