[cap-talk] Abstractions that subsume capabilities (was: Re: What sparked interest in capabilities)

[Rob Meijer]

On Fri, March 7, 2008 06:27, Jed Donnelley wrote:
> At 02:10 PM 3/6/2008, Karp, Alan H wrote:
>>Jed wrote:
>> >
>> > Hmmm.  I spent a bit of time looking around on the Web and
>> > didn't find anything that I would consider a 'taxonomy' for
>> > access control schemes.
>>
>>I'm working on a study group for the Navy chartered with creating a
>>position paper on SOA IA Security.  (Services Orientented
>>Architecture Information Assurance, for you non-military types.  I
>>usually apologize for the lack of acronyms in my notes to that
>>group.)  They use DAC/MAC to describe who determines access and IBAC
>>(identification), RBAC (role), ABAC (attributes) to define the
>>authentication used to make an authorization decision.  Because of
>>the acronym collision, we use NBAC (autheNtication) for the those
>>three and ZBAC (authoriZation) for what I'm pushing.  That's sort of
>>a 2-dimensional taxonomy.
>
> Am I wrong in considering RBAC and ABAC really just forms of IBAC?
> That is, they are all properties of an identity -> an 'authentication'.
> If access is controlled for a "role" it is controlled for identities
> that (who?) have that role.  If access is controlled for an "attribute",
> it is controlled for identities with that attribute.  As you say it
> is really controlled for anybody/thing that can authenticate to
> an identity - and then for roles or attributes associated with the
> identity.

I believe there are two distinctly different interpretations of RBAC.
The first one fits your understanding, and is IMO just a administratively
convenient abstraction on IBAC. The second interpretation (of RBAC)
however seems to be somewhat different in that the roles are bound to the
identity as some sort of trivial state machine rather than statically.
IMO that means:

* Static RBAC == IBAC
* Statefull RBAC != IBAC

With 'statefull' RBAC, the identity can switch roles according to a state
machine definition, and the current state (role) determines the 'active'
access controls for that identity.

It is IMHO rather inconvenient that both forms of 'role' based access
control (static and state full ) are addressed with the same name, given
that they are conceptually very different.

Rob