NetIQ IDM - Birthright Role Driver

NetIQ IDM is a very powerful event driven engine to perform account and password synchronization to various endpoint directories, databases, applications, cloud platforms, and more. Using near real-time provisioning using change events enables very quick time-to-value for Lifecycle Management of identities and accounts. With this great power, comes some nuances of handling Birthright Role provisioning.

I use the term Birthright Role provisioning, because this is the best fit for the NetIQ IDM solution to accomplish. It excels in account synchronization and create, update, move, delete actions. The real-time engine is not terribly well suited for permission management however, unless there are some extreme use cases requiring almost 100% control from the IDM system. There are other software solutions such as NetIQ Identity Governance which are fit-for-purpose for extensive permission management and Identity Governance and Administration functionality.

How do I do Birthright Roles correctly?

The RBAC question is the IT world age-old question, almost unanswerable. It is because RBAC, like Security, is a process and not a destination or product. The goal of this post is to identify the best practice to build a flexible role processing policy that is maintainable and extensible for Birthright Roles. The flow of processing is as follows:

1- Initialize

• Initialize XML in operation-data or similar to store state information on current Identity and what target state of Identity should be.
• Build the current state information for the nrfRoleAssignedRoles and nrfInheritedRoles along with any additional information such as sunset dates, assignment paths, role container structure.

2- Business Role Logic and Membership Criteria

• Extensible policy to contain the business requirement or logic for assignment.

1. This is your typical location for logic or membership criteria such as:
   1. Active + Employee
   2. Active + Employee + Department Number IN ["ABC1234","ABC593"]
   3. Active + Contingent Worker + JobTitle LIKE "Systems Engineer*"
2. Any other qualifications of processing such as temporary assignments, reason text, sunset dates will be kept in the XML around assigning these.

3- Set Evaluations and API Calls

• Evaluate the set logic for current and target role assignments to determine the add-role calls and remove-role calls.
• Perform the Role API calls passing the already built information.

What is the benefit of this?

The immediate feedback may be

• "I have written IDM DirXML policy to do Role granting before and didn't have a problem. This seems overly complicated when I just want to add a role or remove a role."
• "I've used dynamic groups with Roles and Resource Service Driver in NetIQ IDM, and I didn't have to write a bunch of policy."

I also have written simpler Business Role granting and have been exposed to a myriad of different access control logic and policy. My argument very simply is:

When the business requirements changed, or there were exceptions to the standard, how well did the simpler policy extend and stay maintainable over time?

The logic that needs to be maintained is generally just in the "Determine applicable roles" step. Not in any of the other policy. That is merely the generic boilerplate of performing the set calculations and then endpoint API calls to perform the Business Logic coded once. This reduces any of the typical logical concerns that pop up through changing, contradictory, and exception case requirements that the business must have implemented such as:

• Have I already added this role?
• What took priority? The general case or an exception access add or remove later.
• This particular group must have immediate access removal.
• This other group must have a grace period or sunset added. But not this particular user.

All of these use cases should be discussed for accuracy and actual need from the Business; but most often, the requirements must be met and codified into policy. Having the logic determine a list of applicable roles for a user (along with qualifications of processing) in some mutable XML form instead of directly submitting everything to API allows for these exceptional rules to be implemented with visibility into the target state before submission to the API for processing. This means easier visibility, supportability and maintainability over the course of the IAM system process for Birthright Role access granting.

And for everything beyond the Birthright access, look at the fully featured Business Role implementation in a product solution targeted for IGA comprehensive functionality such as NetIQ Identity Governance.