What's wrong with the ANSI RBAC standard? Part 1 - Sessions should be optional
By jeff.shukis on Aug 01, 2008
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?