Representing RBAC actors in LDAP

Question

When implementing an RBAC model using an LDAP store (I'm using Apache Directory 1.0.2 as a testbed), some of the actors are obviously mappable to specific objectClasses:

• Resources - I don't see a clear mapping for this one. applictionEntity seems only tangentially intended for this purpose
• Permissions - a Permission can be viewed as a single-purpose Role; obviously I'm not thinking of an LDAP permission, as they govern access to LDAP objects and attributes rather than an RBAC permission to a Resource
• Roles - maps fairly directly to groupOfNames or groupOfUniqueNames, right?
• Users - person

In the past I've seen models where a Resource isn't dealt with in the directory in any fashion, and Permissions and Roles were mapped to Active Directory Groups.

Is there a better way to represent these actors? How about a document discussing good mappings and intents of the schema?

Answer 1

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 every thing 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, assigne 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 XAML, RFC3198, ISO10181-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.

-jim