Web Blog_blogentry_020117_1


RBAC is not RBAC and RBAC on paper is difficult ( StackOverflow 2012)#

RBAC is not RBAC is not RBAC and RBAC on paper is difficult, but nearly impossible to implement in a real-life.

Everyone has their own "idea" of RBAC and most everyone uses different terms for everything associated with RBAC. Generally from an LDAP implementation perspective you seldom have all the "pieces parts" to do a proper implementation within LDAP.

The "pieces parts" in simple terms are:

  • S = Subject = A person or automated agent or Users
  • P = Permissions = An approval of a mode of access to a Target Resource
  • T = Target Resources = The Object to which you want to assign permissions

The Role, at minimum, needs to associate a Permission and a User. The Target Resource could be outside of LDAP entirely. So it could be an Application on a Tomcat server or simply the right to read "other" entries within the LDAP Server.

So typically the best you will do within LDAP is to setup an object which has a list of users and if there are some resources that are within LDAP, assign the proper directory permissions for those target resources.

Then there is the little problem implementation.#

We have now need a Policy for implementation of our Role. So our role, we will call it USER-READ-ONLY, is not useful without a policy on how it is to be used.

In our case, we could just say the USER-READ-ONLY Role can read anything in our Organization.

So we now have a Policy. Where is this policy stored? The Digital representation of a Policy is stored in the "Policy Information Point" or PIP.

How do we interpret the Policy Supplied from the PIP? Policies are interpreted by the Policy Decision Point (PDP).

Who decides if a Subject (user) can access a resource? The Policy Enforcement Points (PEP).

Putting all this policy stuff together we end up with the digital representation of the Policy is provided by the Policy Information Point to the Policy Decision Point which then passes the decision to the Policy Enforcement Point where the access is permitted or denied.

So in our RBAC story, where is the PIP, the PDP, and the PEP? Well if the Target Resource is in the LDAP directory, then it is the LDAP directory that is the PIP (which we probably hardcoded and is not abstracted, the PIP likewise and the PEP too, and that was easy.

But if it is our Tomcat Application, it MUST be a method within the Tomcat Application that can interrupt knows must use a method to say "I have this Subject (user) and he wants access to this Target Resource (inventory) to perform this Permission (READ-ONLY)".

Sure there are some standards for all this stuff. (Google XACML, RFC 3198, ISO 10181-3, NIST) but they are Standards with wide gaps for practical implementations.

So keep in mind REAL implementations of RBAC is hard.

Sure IMHO, we should know about RBAC, study the papers and make it a strategic direction, but the real life implementation across a broad base of vendors and applications, well we are just not there yet.


More Information#

There might be more information for this subject on one of the following: ...nobody