This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 35 lines
!!!NIST RBAC "fundamentally flawed"
In his [blog|http://blog.talkingidentity.com/2008/07/my_next_attempt_at_controversy.html], [Nishant Kaushik], points out the common real life Scenarios that [NIST RBAC] appears to not do well.
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?
! My Thesis
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.
! My Rationale
In a conversation later with Ian and Lori, I illustrated my case with the following access control examples:
! [Scenario A|Use case]
Hierarchical RBAC 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.
! [Scenario B|Use case]
DrReadingChart 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.
!!! Exchange of Roles and Attributes
There has long been an issue when separate organizations do not utilize the same RBAC system. How does the Patient's RBAC system deal with the role assigned DrReadingChart from some other hospital?
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]