Delegated RBAC CRUD Via Workflow

OpenIDM provides a powerful delegated administration model, for both REST endpoint access and workflow process access.

A simple way to provide scoped access into the IDM functions, is to simply wrap a workflow process around it and then delegate access to that workflow to a certain of group of users.

A basic example could be that of role based access control administration.  The basic create, read, update and delete tasks often associated with object management.  So RBAC-CRUD to save a few letters.

Each CRUD function can be wrapped into a workflow, with access to those workflows then given members of the rbac-admins internal authorization role.

I created 5 workflows, four for the role-admins and 1 for the end user:



A simple wrapper that takes two arguments and runs an openidm.create() to create the role.


Opposite of create…and does a lookahead using some JS stored within the form HTML to get a list of roles that can be deleted.  Before the openidm.delete() function is called, it clears down the members list first.


So we have a role, now we want to add some users.  Again, does a lookahead to create a dynamic select drop down, then free text to add a username.  You could add some checking logic here I guess to make sure the user exists before submission, but I wrap a conditional check in the workflow before I patch the role anyway.

The other attribute is a timer – this is just based on the Activiti Timer element and I’ve set it to take just a time.  In reality you would accept a date, but for demo’s a time is much easier.  So, after the time has been passed, the initial role to user association is reversed, taking the role away.


Simple manual process to remove a role from a user.  Note all the patches in the workflows work against managed/role.  Whilst you can add and remove roles from the managed/user/_id, by using managed/role endpoint, I can restrict the access the role-admins get via access.js more accurately.

We then have one workflow left – that is available to any user.  Eg it’s a standard end user workflow, and this time for an access request.

This again does a look ahead and performs an approval step before provisioning the role to the user. The default manager approval is in the workflow and remmed out alongside the ability to use any member of the role-admins authorization role.  So you can flip between the two approval journeys.

The use of role-admins leverages the Activiti:Candidate users attribute – eg role-admins could contain 10 users – the approval goes to all 10 and the first one to claim the task can approve.

A couple of points on access.  The workflow access is governed by the ../conf/process-access.json file.  In there add in the pattern of the role _id along with the internal authorization roles that should have access – note internal role and not just managed/role.

The access.js file in the ../script directory also needs updating to allow full control to the managed/role endpoint to the role-admins users.

Code for this set is available here.

Note, thanks should also go to Marek Detko and some code crib from his role collection example.

This blog post was first published @, included here with permission from the author.

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:!/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 "' + + '"'}).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.


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.





Configuring Roles in ForgeRock OpenIDM 4

This blog post was first published @, included here with permission.

Merry Christmas!

For those interested to know how to configure Roles in ForgeRock OpenIDM, here’s my Christmas gift. A video at the end of this post will walk you through the installation of both ForgeRock OpenIDM and ForgeRock OpenDJ, configure the latter as an external resource in OpenIDM, performing reconciliation to bring in users from OpenDJ to OpenIDM. That’s not it, because all of that I’ve shown you earlier as well. Then, what’s more? Here it is:

So we go on and create Roles in OpenIDM, which has Managed Assignments that in turn has Attributes associated with an external resource (ForgeRock OpenDJ). So when a Role is assigned to a user in OpenIDM, based on the value of Attribute that is attached to the Role, the user will be subscribed to a group in the OpenDJ. If it sounds confusing,please don’t waste time reading it again, instead watch the video below, it’ll all be crystal clear.


Ansible roles for OpenDJ

My colleague Warren, who I had the pleasure to work with at Sun and again with ForgeRock, has been playing with Ansible and has produced 2 roles to install OpenDJ and to configure replication. Check Warren’s blog post for the details, or go directly to the Ansible Galaxy.

Filed under: Directory Services Tagged: ansible, devops, directory, directory-server, ForgeRock, ldap, opendj, roles