Why Role Based Provisioning is not RBAC

Talking with peers in the Identity space, it continues to strike me how two fundamentally different concepts remains a topic of confusion. I am specifically referring to Role based provisioning versus Role Based Access Control (RBAC).

RBAC is an approach to restrict system access to users with the appropriate authorization and enforced on the access control layer. RBAC is a non-discretionary access control mechanism which promotes the central administration of an organizational specific security policy.

This pattern of modelling access control has been around for a long time and with the raised compliance concerns of Segregation of Duties (SoD), RBAC have shown to be an effective model to enforce this within the enterprise - therefore also widely used.

Role based provisioning is the concept of clustering or grouping the way entitlements and attributes are being provisioned to target resources, for instance a particular role might imply a set of groups in the corporate Active Directory (AD) as well as access to a financial reporting system. The groups in AD would be entitlement carrying attributes, but the provisioning role wouldn’t be limited to these and could of course also define other attributes such as department and division.

Role based provisioning relies upon the target system to be the enforcer of the authorization layer. Of course the provisioning of entitlements can contain policies ensuring that SoDs are being considered and honored. Perhaps this is where the confusion occurs? Perhaps the terminology is being used too relaxed among identity vendors.

In the modern world of mobile users, connected wirelessly on portable devices such as tablets or smartphones creates a new set of challenges which quickly introduces the discussions around context aware access controls. Context of course being nothing more than a set of key value pair attributes defining where you are, what device you are one, time zone you are in or whatever it might be, but still simply attribute data derived from or provided by the user and associated device.

Analysts, such as Gartner, predict that by 2020, 70% of enterprises will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from less than 5% today.

Fair enough, even though i believe that statement when i see it in reality - but lets not confuse this with role based provisioning, which serves a completely different purpose. Lets try to defuse the confusion by defining the two models.

• A role-based access control (RBAC) model grants access to resources based on a user role, such as the user's job title or work responsibility. (Here we are talking authorization and its enforcement)

• A role-based provisioning model, automates the access entitlement provisioning process for a specific managed resource, based on the roles to which the user belongs. (Here we are talking how to set attributes, entitlements carrying or regular attributes, not how to enforce them)

What’s funny about Gartner’s predictions, is the specific explanation on how “RBAC is one-dimensional because it cannot take context in the equation and will therefore fail to address challenges.”, the analyst seems to have missed the specific paragraphs in the NIST standard about static and dynamic constraints as well as temporal constraints, addressing the topic of contextual information and recent publications and research such as http://csrc.nist.gov/groups/SNS/rbac/documents/kuhn-coyne-weil-10.pdf. Basically allowing for attributes to dynamically impact the roles.

Having said the above, i do believe that context will become increasingly important but when jumping in to these discussions, please note the difference between these two concepts.

Native REST in OpenDJ and the REST2LDAP gateway

Directory Services are an ideal way to structure and store, identity data reaching exceptional scale. The long serving protocol of choice is LDAP and of course integrating with or building solutions around directories often involved LDAP SDKs designed some 15 years ago with almost zero standards to build on.  For Java platform developers, however, the JNDI API emerged.

Though the intent was for JNDI to be that standard on the Java platform, it hasn’t evolved with the rest of the platform and lacks basic properties such as Generics and Concurrency support.

ForgeRock’s OpenDJ SDK and the likes are providing an answer to this issue but are still very LDAP oriented with the learning curve associated for LDAP operations and data model.

Development using JNDI is time consuming and far from intuitive for even seasoned engineers. Annoying problems such as the domain separator being a slash instead of a dot results in confusion and difficult debugging, especially as we are dealing with URLs.

The future of LDAP is often debated since its tricky and time consuming to use which results in higher development. Considering that LDAP is pretty much unavoidable in today’s enterprises, it’s surprising that fundamental LDAP training is not part of the required  curricula for software engineers.  At great cost, this important knowledge is ignored by most students out of university and is also often neglected by most startups building new and innovative solutions.

ForgeRock has spent a tremendous amount of effort to provide a RESTful interface around our directory OpenDJ, exposing all the power of the LDAP protocol and OpenDJ but with the simplicity of REST while at the same time maintaining the high performance and scalability.  Technically this means that OpenDJ exposes its directory data, such as users, organizations and groups over HTTP as JSON resources.

The business benefits from using the REST interface to OpenDJ because it  means that applications relying on directory services have a significantly shortened time to market and development time. The simplicity of REST also ensures a higher quality assurance and and more thorough testing.  As an example, in only a week’s time, one of our partners built a web application for a hospital that included different views for different personnel (physicians, nurses etc) without having to train its staff on LDAP and its best practices.  It is clear that using the REST API reduces development costs and accelerates time to revenue for new services and applications.

Friday reflections on Software Releases

Imagine a car with state of the art navigation system, aerodynamic body and fantastic ceramic brakes, doing 0-60 mph in 4 seconds - but lacks the capability of putting the car into reverse. Now, imagine a smartphone that has fantastic new features, slick design and innovative human-computer interaction via touch screen - but lacks the capability to copy and paste text.

My guess is that you wouldn’t buy a car that you can’t reverse but clearly when apple launched their iPhone without copy and paste capability, people bought it. The Apple team made well thought thru decisions to launch a product before all the details were fully implemented and i can smell Agile development behind the scenes.

The goals of Agile development is efficiency and velocity. Allowing a product to fail quickly if that is its ultimate destiny or to adapt and include customer requirements, new or previously known but at the same time get features and functionality quickly in the hands of customers. Either to solve business problems they might have and/or get more feedback to improve the software on implemented features.

In my mind the “release early, release often” is critical to a young products success. A software development philosophy that was popularized by Eric S. Raymond in his

The Cathedral and the Bazaar, where Raymond stated "Release early. Release often. And listen to your customers”. This model is of course ideal for companies providing Open Source software such as ForgeRock, where i work.

The Agile Manifesto states four important things to improve software development,

• Individuals and interactions over Processes and tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

Each individual sprint should provide viable features solving real problems and capturing the feedback from customers. Evolving the product is what makes the product ultimately successful, and of course that is done by interacting with the customers. Having said all of the above, i do believe its important not to neglect the details.

Agile development should never be an excuse for a lazy product manager (or owner if you wish) not scribbling down the details and explaining the requirements part of a user story. The balance is to understand as a Product Manager and dev team, that not all details are necessary to be implemented in order for the software to work and to stick true to the Release early and release often philosophy.