24 January 2014

Role Mining & Peer Analytics in OpenIDM

I created a few custom endpoint extensions for use with OpenIDM, that allows for the analysis of users and their entitlements.  I won't go into the virtues of roles and role based access control, but these endpoints are a simple way to quickly identify similarities between groups of users and then quickly find any differences or exceptions.  These exceptions would then be analysed either by a certification system or perhaps manually by the security admin teams.

Peer Analysis

Peer Analysis JSON
The first endpoint simply groups users (generally managed users) together based on a functional similarity.  This is generally known as 'top down' mining in full blown role mining projects.  The endpoint returns a JSON object with role names and an array of users that are part of that functional grouping.


Peer Entitlements

Peer Entitlements JSON
The role object on it's own it's much use.  What we're really interested in, is what entitlements should be associated with that role.  This makes the onboarding of new users really simple and less error prone.  If we know what entitlements the role should have, we can simply associate a new user, based on the previously identified functional grouping, and the user can then be provisioned those entitlements.  But how do we know which entitlements to associate with the role?  The peerEntitlements.js endpoint is a really robust way of finding out which entitlements are common for a given group of users.  Using the JSON output from the peerAnalysis.js endpoint, we can simply pull out the entitlements for any system known to OpenIDM. The peerEntitlements.js endpoint then identifies every entitlements that is common across every user in that grouping and adds it to the role.

For example if Billy (grp1, grp2), Ann (grp1, grp5) and John (grp1, grp6) were all in the same role, the entitlements endpoint would see that only "grp1" was common across all users and push that into the entitlements array.  The other entitlements we'll come to in a second....


Peer Exceptions

Peer Exceptions JSON
Any entitlements that do no find themselves added to a role due to their similarity (or lack of), need to be handled.  Generally these entitlements are known as exceptions and are managed through long and complex access certification and attestation projects.  There are several fully blown compliance products on the market place, that can take several months to configure and deploy.  The idea behind the peerExceptions.js endpoint, is to quickly identify only the high risk exception entitlements and get those entitlements cleaned up in a timely fashion.  By focusing just on the high risk exceptions, this can cut down the access review process by 80%.  The exceptions in this example, are simply entitlements associated with a user that fall outside of the role model.  Taking user Billy (above), he has "grp1" and "grp2" associated with him.  "grp1" landed in the newly found role, leaving "grp2" as an exception.  He has that entitlement, but other users who perform a similar business function do not.  Maybe he is a manager, or perhaps is new to the job and has experienced privilege creep.  Either way this entitlements don't match those of his peers and that needs investigating.  The peerExceptions.js endpoint performs a diff between the effective entitlements directly associated with the user, and the effective entitlements from the roles the user has.

All code from the above examples is available from Github here.  Note this is an example endpoint and is no way supported by ForgeRock.  It is released simply as a community contribution.  Use as-is!

No comments:

Post a Comment