My Next Attempt at Controversy: Roles and the (ir)relevance of NIST
By Nishant Kaushik on Jul 09, 2008
Well, I think I am done talking about directories now, especially after reading Ian Yip's hilarious recap of the debate, as it were. Having now appeared as a significant bit player in this drama, I have decided to leave it in the hands of more capable people like Clayton and am moving on to familiar (and hopefully fertile) ground.
Day 2 of the Catalyst Conference turned towards the more pragmatic topics of role management and provisioning. It was with a great deal of interest that I heard Tim Weil discuss a standards effort he is leading to promote the implementation and interoperability of RBAC components. As I understood it, the goal is to make it easy for roles defined in one system (say ORM or SailPoint) to be used in another system (OIM or Sun IM), without having to do massive integration projects. Burton's Kevin Kampman has blogged about this if you are interested.
Tim's perspective on this is very relevant, having dealt with such practical issues through numerous implementation projects while at Booz Allen Hamilton. It was this very perspective that I wanted to tap into by asking him a question that vexes me a lot, but he gracefully sidestepped since it wasn't directly related to the talk he was giving. However during a Twitter exchange with Ian Glazer I promised to explain my side fully in a blog post, so here goes.
My Question To Tim
Is the NIST RBAC standard fundamentally flawed, given that it is missing a key element in access control decisions - relationships, the very thing that Burton spent day 1 of the conference stating was the missing link for IdM to tackle?
It is, and companies looking to the NIST RBAC standard as the template for how to approach role management are going to end up missing the boat.
In a conversation later with Ian and Lori, I illustrated my case with the following access control examples:
A doctor wants to enter a hospital he is assigned to, presumably using a physical access device like a Honeywell card. In order for the doctor to get into a hospital, all he needs is for his identity in the system to have a "Doctor" role that is checked for when he enters the hospital. This is a simple scenario that the NIST RBAC standard can easily take care of.
However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a "Doctor" role, but also needs to have the "Attending Doctor" role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role. NIST RBAC seems to be wholly unequipped to handle this use case.
NIST RBAC is an important tool to any discussion on role structures. But it should not be treated as complete by any means, merely a start. The use case illustrated in Scenario B is rapidly becoming the more common use case, as Fine-Grained Authorization needs and Data Security come front-and-center in the discussion around Access Control. Yet work on resolving such scenarios is currently excluded from discussions on RBAC and left up to the ABAC (Attribute-Based Access Control) crowd. Having two different mechanisms to implement security (often in the same systems) will surely lead to more holes than a chunk of swiss cheese.
Those that feel this is promotion for our ORM (formerly Bridgestream) product should know that it is not, since the relationship-based roles concept that they created has so far been limited to approval use cases, and has not made its way into any access control discussions. One reason I feel this isn't happening is because it seems no one has figured out how to express this in an XACML policy, which can easily handle ABAC, but not Relationship-based RBAC. This led to the next controversial question I asked at Catalyst, which I will bring up in a later post.
I'd love to hear other perspectives on this, so leave me some comments.