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 @ http://www.theidentitycookbook.com/, included here with permission from the author.