8

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?

Tetsujin no Oni
  • 7,300
  • 2
  • 29
  • 46
  • Curious - why the downvote without even a comment? This seemed to be a relevant question when I asked it three years ago... Particularly for the project I was working on at the time. – Tetsujin no Oni May 01 '12 at 16:10
  • 1
    As the OP, I see that this is a duplicate of [Role-based security implementation in LDAP](http://stackoverflow.com/questions/8020237/role-based-security-implementation-in-ldap) which actually has some useful guidance. – Tetsujin no Oni Sep 26 '13 at 13:09
  • And in the latest update: I'm finding that claims-based access control in .Net is a nice mechanism, and ADFS seems reasonably capable as a mechanism for marshaling claims out of an application database into the authentication/authorization structure. – Tetsujin no Oni Mar 05 '14 at 13:49

2 Answers2

4

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

jwilleke
  • 10,467
  • 1
  • 30
  • 51
  • While you're expanding the discussion, I can't accept this answer as it really isn't an answer to the questions I was posing.... Throwing more (useful!) terminology at the discussion definitely doesn't address the case of "simple example(s) of actually building out an implementation" ... – Tetsujin no Oni Sep 26 '13 at 13:07
1

Check out Fortress which is a real-life, open source implementation of ANSI RBAC (INCITS 359) that uses LDAP. http://iamfortress.org/

and yes it was fairly difficult to implement but we've been working on this problem for over 10 years. ;-)

Shawn McKinney
  • 308
  • 1
  • 8
  • I know this is very old but do you happen to know if that Fortress (iamfortress.org) was officially absorbed (or turned into) Apache Directory Fortress ? What's the story there ? Did Symas run iamfortress.org and then handed over to Apache Foundation? Looking for press releases or any other fino on what happened there and couldn't fine anything. Also, do you happen to know if anyone has done some work on schemas for ABAC ? – aimass Apr 23 '23 at 12:00
  • Symas purchased JoshuaTree Software, which was the sponsor of Fortress. Later Symas 'donated' Fortress to Apache and it was renamed Apache Fortress. Since then, iamfortress.org has been my personal blog. I still monitor and will answer questions although better to route them to the fortress mailing list. WRT ABAC schema support, yes, Apache Fortress does have partial support for attributes in its RBAC sessions. There are numerous articles written about it on the symas and iamfortress sites. Full disclosure: I work for Symas and also a maintainer of Apache Fortress. – Shawn McKinney Apr 24 '23 at 13:40
  • correction: iamfortress.net is personal blog. iamfortress.org has been discontinued. – Shawn McKinney Apr 24 '23 at 14:46