A Framework for Dynamic Roles and Assignments in OpenIDM

This solution article demonstrates how to add and delete users to ldap groups, statically and also dynamically using custom mappings in reconciliations. I attempt to present a framework in OpenIDM that can be used for setting up a simple entitlement framework where you can automatically attach roles to assignments, making RBAC easier to implement.
This blog article uses sample2b and is specifically referring to the following doc link:
https://backstage.forgerock.com/#!/docs/openidm/4/samples-guide%23provrole-add-assignments
Let us begin by laying the groundwork first, and describe how to create roles and assignment manually in OpenIDM. This solution article assumes you have gone through the doc-link above and are familiar with sample2b.

Static Assignments

The key idea is to create an assignment, and add the group you want assigned under “Attributes” as shown below:
Inline image 1
And then of course, “attach” this assignment to the Provisioning Role you reconciled from DJ:
Inline image 2
Now, it is a matter of assigning the Provisioning Role to the user in order to have the LDAP group “cn=impersonation” assigned to the user in OpenDJ.
Inline image 3
DJ’s ldapsearch will validate the correct group was assigned:

./ldapsearch –port 1389 –hostname localhost –baseDN “dc=forgerock,dc=com” –bindDN “cn=directory manager” –bindPassword xxx –searchscope sub “(uid=user.10)” dn uid isMemberOf

dn: uid=user.10,ou=People,dc=forgerock,dc=com

uid: user.10

isMemberOf: cn=impersonation,ou=groups,dc=forgerock,dc=com

Once you remove the role, ldapsearch will validate that the group was deleted in DJ:

Inline image 4

./ldapsearch –port 1389 –hostname localhost –baseDN “dc=forgerock,dc=com” –bindDN “cn=directory manager” –bindPassword xxx –searchscope sub “(uid=user.10)” dn uid isMemberOf

dn: uid=user.10,ou=People,dc=forgerock,dc=com

uid: user.10

 

Note that, each one of these IDM UI steps can be performed over REST as well.

Dynamic Assignments

Creating assignments dynamically from incoming LDAP groups can also be performed by setting “managed/assignment” and “managed/role” as Recon targets with the help of some scripting involved in the attribute grid.
Begin by creating the following two mappings:
system/ldap/group to managed/assignment
Screen Shot 2016-05-25 at 5.15.43 PM
and, system/ldap/group to managed/role
Screen Shot 2016-05-25 at 5.17.15 PM
The idea here is to automatically create two managed entities from the LDAP Groups container in OpenDJ.
The first managed entity (“managed/role”) is created to hold the named LDAP group objects – deemed Provisioning Roles – in our use case. These LDAP groups you want the users to be automatically added to (or provisioned to in OpenDJ) whenever “same-named” provisioning roles are assigned to a user. These “same-named” provisioning roles happen to be attached to “same-named” assignment objects! (magically!.. not quite, but via transform-scripting as shown below).
The second managed entity (managed/assignment) is created to hold the “same-named” assignment object that you will setup in such a way that it references (internally) the “same-named” provisioning role!
This will become clearer, read on.

Mapping called sourceLdapGroup_managedRole

Screen Shot 2016-05-25 at 5.29.05 PM
This mapping is simple and aims to create “named” provisioning roles inside OpenIDM from the LDAP group objects in OpenDJ. Cannot get simpler than that in this use case- but keep your seat belts fastened, and read on!

 

Side bar for the advanced OpenIDM user: Under reconciliation behavior policies configuration, you want to set Missing condition to Unlink in order to “reset the state” if you will, in the case where you delete a provisioning role accidentally in OpenIDM, but want the next LDAP recon on managed/role to fix it. Just remember to run recon twice!

Mapping called sourceLdapGroup_managedAssignment

Screen Shot 2016-05-25 at 5.20.52 PM

The picture above shows which attributes to map for this particular mapping definition.

For the /attributes map, use the following transformation script:

([{assignmentOperation:'mergeWithTarget',unassignmentOperation:'removeFromTarget',name: 'ldapGroups',value: [ source.dn ]}])

This transformation script sets up the incoming group object as an OpenIDM assignment and also sets up the value of the “ldapGroups” attribute to the DN of the incoming group object.

For /roles, use this one:

([{_ref: 'managed/role/'+( openidm.query('managed/role',{'_queryFilter':'/name eq "' + source.cn + '"'}).result[0]._id)}])
This script queries the managed/role container in OpenIDM for a “named” provisioning role whose CN happens to equal the CN of the incoming group object. This assumes that you reconciled the managed/role objects first- and this is the only dependency for this use case. You cannot really search for a provisioning role’s CN value before you reconcile it from LDAP. After retrieving the correct role object, the script sets the _ref property of the assignment to that particular provisioning role. This is what you would do if you were manually “attaching” a provisioning role to an assignment as shown in the Static Assignments section above.

Demo

Now it is a matter of running reconciliation on sourceLdapGroup_managedRole first, followed by running a reconciliation on sourceLdapGroup_managedAssignment. You should see roles such as:

Screen Shot 2016-05-25 at 5.38.38 PM

And you should see assignments as well- these are basically “named” after the LDAP group objects that have an ldapGroup attribute setup and also an “attachment” setup to a provisioning role:

Screen Shot 2016-05-25 at 5.40.17 PM

 

For example, lets look at the impersonation assignment in detail.

This picture shows the mapping for this assignment object, and the description reconciled from the OpenDJ groups org unit.

 

Screen Shot 2016-05-25 at 5.40.59 PM

 

The picture below shows how the DN of the incoming LDAP group object was mapped to an attribute called “ldapGroups”.

Screen Shot 2016-05-25 at 5.41.05 PM

 

The picture below shows the provisioning role, with the same name of course, that is “attached” to this assignment object.

Screen Shot 2016-05-25 at 5.41.16 PM

 

Now we have an “entitlement” framework for automatically creating assignment and role objects in OpenIDM using single or multiple “source” LDAP group containers, and then attaching these provisioning role objects to assignments. We have simply demonstrated a one-provisioning-role to one-assignment mapping in this use case, but far more complex mappings such as many-to-many or many-to-one are possible. This framework can serve as the foundation for an RBAC type scenario in your deployments! Good luck.