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:

role-admins: createRole.bar

 

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

role-admins: deleteRole.bar

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.

role-admins: addRoleToUserTemporal.bar

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.

role-admins: removeRoleFromUser.bar

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.

openidm-authorized:requestRole.bar

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.

Optimized Role Based Access Control

RBAC.  It's been around a while.  Pretty much since access control systems were embedded in to distributed operating systems.  It often appears in many different forms, especially at an individual system level, in the form of groups, or role based services, access rules and so on.  Ultimately, the main focus is the grouping of people and their permissions, in order to accelerate and simplify user account management.


Enterprise RBAC
Enterprise role management has become quite a mature sub-component of identity and access management in the last few years.  Specialist vendors developed singularly focused products, that acted as extensions to the provisioning tooling.  These products developed features such as role mining, role approval management, segregation of duties analysis, role request management and so on.  Their general feature set was that of an 'offline' identity analytics database, that could help identify how users and their permissions could be grouped together, either based on business and functional groupings or system level similarities.  Once the roles had been created, they would then be consumed either by a provisioning layer, or via an access request interface. The underlying premise, being that access request management would be simplified due to business friendly representations of the underlying permissions and the account creation and fulfillment process would be accelerated.

The Issues & Implementation Failures
The process of developing an RBAC model was often beset with several problems.  IAM encompasses numerous business motives and touch points - which is why many still argue identity management is a business enabler more than a security topic - and developing roles across multiple business units and systems is time consuming and complex.  A strong and detailed understanding of the underlying business functions, teams, job titles and processes is required, as well the ability to perform analysis of the required permissions for each functional grouping.  Whilst this process is certainly mature and well documented, implementation is still an effort laden task, requiring multiple iterations and sign off, before an optimal model can be released.  Once a model is then available for use, it requires continual adaption as systems alter, teams change, job titles get created and so on.  Another major issue with RBAC implementation, is the often mistaken view, that all users and all system permissions must be included in such an approach.  Like any analytic model, exceptions will exist and they will need managing as such, not necessarily be forced into the RBAC approach.

Speeding up Role Creation
Role creation is often accomplished using mining or engineering tools.  These tools take offline data such as human resources and business functional mappings, as well as system account and permissions data.  Using that data, the process is to identify groupings at the business level (known as top down mining) as well as identifying similarities at the permissions level (known as bottom up mining).  Both processes tend to be iterative in nature, as the results are often inconsistent, with difficulties surrounding agreement on user to functional mapping and of function to permissions mapping.

One of the key ways of speeding up this process, is to use what is known as 'silent migration'.  This approach allows roles to be created and used without change to the users underlying permissions set.  This instantly removes the need for continual approval and iteration in the initial creation step.  The silent migration consists of initially mapping users into their functional grouping.  For example, job title, team, department and so on.  The second step is to analyse the system permissions for users in each functional grouping only.  Any permissions identified across all users in the grouping are applied to the role.  No more, no less.  With it, no changes are therefor made to the users permissions.  This process is simply performing an intersection or each users' permissions.

Focus on the Exceptions
Once the users of each functional grouping have had their permissions migrated into the role, it's now important to identify any user associated permissions that are left over.  These can simply be known as exceptions, or permissions of high risk.  They're high risk, as they are only assigned to specific individuals and not the group.  This association could well be valid - a line manager for example may have different permissions - but as a first pass, they should be reviewed first.  To identify which are exceptions, a simple subtraction can be done between the users current permissions (as identified by their target system extract) and the permissions associated with their functional grouping.  Anything left needs reviewing.

This approach can also help with the acceleration of access review strategies.    Instead of looking to review every user, every permission and every functional grouping, simply analyse anything which is anomalous, either via peer comparison or functional grouping.

RBAC is a complex approach, but can provide value in many access review and access request use cases.  It just isn't a catch all, or perhaps approach for every system and user.  Specific application using a more simplified approach can reap rewards.

By Simon Moffatt