I must first say that the ANSI 359-2004 RBAC standard* is absolutely critical. While RBAC has been around for about two decades, ANSI and its predecessors only (relatively) recently gave us a shared language and got us talking about roles and role management. Some of that talk is about how flawed the rather academic ANSI standard is when applied to real-world identity management, but at least we're all talking!
I could spend time talking about what's right about the current standard. Perhaps I will some day soon. For now, however, to fulfill my promise of at least one post per week, here is the first item in a fairly long list of gripes about the standard. Remember, we only complain about those we love!
Issue 1: Sessions and Role Activation don't belong in core RBAC
The RBAC standard specifies four sets of features. The first and most basic set is known as Core RBAC. The features in Core are required, whereas those in the other sets (Hierarchical RBAC, Static SSD, and Dynamic SSD) are optional.
The problem is that Sessions and the notion of 'activating" a role are specified in Core RBAC and are therefore required in order to claim support for the ANSI RBAC. Why is this a problem? Sessions are very relevant to role-based access control (you must "activate" one or more of your roles before the Access Management system can figure out what you can and can't do) but are irrelevant for role management. Given a definition of Core RBAC that requires support for sessions and role activation, no role management product on the market can claim to support ANSI RBAC. These role management products are in production use now, they work, and are part of almost all identity management deployments. Any standard that ignores them risks being ignored itself.
The solution is quite simple: Acknowledge that sessions and role activation should be part of a separate and optional extension to Core RBAC, bringing the standard into alignment with a world that already agrees that role managment is far more than just a feature of an access management sytem.
Do you agree? Disagree?
Comments (2)
I agree. The core standard should separate the management and enforecement aspects inherent in RBAC mechanisms; in order to allow a rich set of vendors to participate and provide these solutions (separately if necessary but assuring interoperability) .
Regards
Srinivasan
Posted by Srinivasan Varadarajan | August 7, 2008 12:57 PM
Posted on August 7, 2008 12:57
Jeff,
You make perfect sense. Certainly, the management of roles and use of those roles should be separate and distinct in the standard.
Kevin
Posted by Kevin Moulton | August 10, 2008 6:40 AM
Posted on August 10, 2008 06:40