Hi Chirag,
Maybe I could explain with an example. We have a role called ‘Basic IT Users’ where the entitlements simply allow members to log into the the IT domain and access email and the intranet. This role doesn’t provide other entitlements various workers need to do their jobs, but they need the entitlements for this role before they would be able to use any other entitlements. The ‘Basic IT Users’ role has about 16 lines of criteria configuration, which is continually evolving, and encompasses over ten thousand identities. Now let’s say we have other roles such as ‘Finance Users’ and ‘Marketing Users’, etc. where the criteria which differentiates them from all the ‘Basic IT Users’ is just their department name. To define the criteria for ‘Finance Users’, we have to restate all 16 criteria from the ‘Basic IT Users’ role plus one more criteria for the finance department, and likewise for the ‘Marketing Users’ and other roles. As the criteria for ‘Basic IT Users’ evolves, we have to change it not only in that role but the Finance and Marketing and all the other roles. That is quite cumbersome. What we would rather do instead, for example, when defining the ‘Finance Users’ role is to configure one criteria which states that the identity has the ‘Basic IT Users’ role, plus one more criteria which states that the identity is in the Finance department. However, the only kinds of criteria allowed for roles are based on identity or account attributes or entitlements. Working within those constraints, we can achieve our goal by creating a source in which the entitlements are the various roles in IDN. Then, for example, when configuring the ‘Finance Users’ role, the first criteria would be that the identity has the entitlement which represents the ‘Basic IT Users’ role, and the second criteria would be that the identity is in the finance department. Does that help you understand the challenge I’m trying to address? I’d love to hear how other folks would deal with the same kind of challenge.
All my best,
Thad