Adding a slice of reality to user entitlement policy definitions

Role Based Access Control (RBAC) as a means of defining user entitlements is as ubiquitous across the Identity Management industry as Facebook is to the 21st generation - there were several key players before it and it isn't always the best tool for the job, but it sure is popular.

Since its very inception and initial rollout, RBAC has forced the implementer to carryout some quite intensive business analysis tasks, which to name a few include:

• The need for (sometimes massive amounts of) role 'mining' to understand what business functions currently exist and how these map to a set of logical roles.
  
• Mapping logical roles to user entitlements within target business applications
  
• In very large deployments, the need to create role hierarchies to rationalise the overall number of roles

Instead of simply documenting the existing processes and entitlement sets, RBAC requires an organisation to interpret the discovered information in an RBAC manner. Anyone who has ever attempted to learn a foreign language will know that translating a concept back into your mother tongue before attempting to understand it is always fraught with difficulty and can be subject to misinterpretation. Instead a more reliable approach is to capture and understand the subtleties of a concept in its original form.

Capturing common user entitlements and exceptions is obviously an extremely useful business analysis task, which is required during any Identity Management implementation. A risk that must be mitigated through such an activity is the loss of user entitlement fidelity. By trying to force 'square pegs into round holes' organisations can actually find that their resultant Identity Management solution is costly to build, difficult to maintain, and inflexible. Primarily this is because the real user entitlements on the ground must be (re)mapped to a set of roles during the initial deployment and regularly throughout entire lifecycle of the Identity Management solution. This is a key point that Attribute Based Access Control (ABAC) is able to alleviate through the implementation of standards such as XACML. For those with even a basic RBAC/ABAC knowledge this view is nothing new, however I think that its worth outlining a real-world use case that conclusions that are being made on the ground to back this up.

Before I jump in with the real world examples, it might be useful to briefly cover XACML and how it relates to user entitlement definition. Oasis (who published the XACML specification originally in 2003) provide the following useful description "XACML is a general-purpose access control policy language. This means that it provides a syntax (defined in XML) for managing access to resources".

Through XACML definitions, an organisation are able to model user entitlements in the form of roles (to preserve legacy implementations) and/or as direct application-specific attributes. Such functionality within XACML may finally allow organisations and implementers of IdM to break away from an entitlement interpretation stance and start defining user entitlements with never before seen expressivity.

Returning to RBAC, a business requirement that I am currently working on with a customer quite plainly shows the significant limitations of RBAC, as opposed to ABAC, in an easy to appreciate manner. The implementation is specifically tasked with the definition of Separation of Duties (SoD) policy. Tivoli Identity Manager (TIM), and many of its peers, implement SoD policy using roles, allowing the IdM administrator to define which role combinations are invalid in their organisation. The prerequisite of this task is clearly that an organisation must have already distilled the existing user entitlements found across the business into a set of roles. To attain the level of role granularity required to implement even a simple set of SoD rules for a small set of business applications (COTS and infrastructure such as Active Directory) requires the definition and management of a massive number of subtly different roles. Such an implementation within even a small to medium sized business can led to so called 'Role Explosion'.

TIM tries to address this deficiency through the usage of role hierarchies. The approach of chaining together roles, thereby reducing their overall number does not increase an organisation's ability to freely express its user entitlements. Instead it could be argued that this approach swaps the problem of role explosion for another - increased role complexity.

A better approach would be to give an organisation the ability to define SoD policies on the actual account entitlements that are under scrutiny, instead of a set of logical interpretations that do not actually exist anywhere. At Pirean we have worked hard to alleviate this problem for TIM customers by supplementing the existing product with our own Pirean Risk Manager (PRM) solution. PRM which is directly integrated into TIM and appears as an onscreen menu item, allows IdM administrators to express SoD rules in terms of business application attributes, thereby moving away from an RBAC centric approach and more towards ABAC. Of course if an application under SoD policy itself uses RBAC then this can also be supported as the role (or group) attribute within a business application will be viewed as just another user attribute.

Within the IBM portfolio ABAC is appearing in products such as IBM Tivoli Security Policy Management (ITSPM). This product is currently more focused towards the real-time processing of authorization requests from an access management entity (or Policy Enforcement Point in XACML terminology).

To wrap up, whilst the the main Identity Management vendors already have ABAC compatible products in their portfolios I believe that over time begin these will be brought directly into their Identity Management and Compliance offerings. This will result in the products taking a more ABAC-based approach as their customers look to express their user entitlements with greater clarity and increase the flexibility of their Identity Management processes.