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

[Karp, Alan H]

Jed wrote:
>
> 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.
>
You got my definitions of ZBAC and NBAC backwards.  The taxonomy, such as it is, is

NBAC - autheNtication
        IBAC - Identity
        RBAC - Role
        ABAC - Attributes
ZBAC - authoriZation
        capabilities
        split capabilities
        authorizations not passed as arguments
        others?

Orthogonal to those is DAC/MAC.

IBAC, RBAC, and ABAC are just different ways of managing the data used to make an authorization decision for either NBAC or ZBAC.  Roles were introduced to avoid changing all the ACLs when somebody changes jobs.  Attributes were introduced to allow the expression of more complex policies, such as Risk Adaptive Access Control (RAdAC).  For example, someone with an attribute "Brit" might be able to use a particular US service in peace time but not during a war.

> In a typical market leading OS (e.g. Windows or
> Unix) processes maintain their association with an identity
> by the rule that forks retain the same identity.  This of
> course doesn't work across a network which acts more like
> sending data through a pipe or TCP to a process with a
> possible different identity.
>
Single Sign-On (SSO) and Federated Identity Management (FIdM), ala the Libery Alliance, are supposed to make that identity work across the network.  Of course, "It doesn't quite work, but next year we'll show you how to do it." to paraphrase the session at RSA 2007.
>
> What you refer to as NBAC (autheNtication based access control) seems
> to me an entirely different approach that goes off in another
> direction.
> It still requires an autheNtication to start things off - so I really
> don't see that distinction.

Change N to Z in the above.  With autheNticationBAC, authentication is used to make an authorization decision at request time in the service's domain.  With authoriZationBAC, authentication is used to make an authorization decision in the client domain before the request is made, often at login time.  Roles and attributes are also assigned before request time, but the authorization decision is delayed until the request is made.

> The key difference to me seems the way
> authorizations are controlled for which subjects (active entities that
> can make requests).  With capabilities (NBAC) it is running programs
> (with whatever "identity" or no identity) that are authorized or
> not - depending on whether they have the required capability token.
>
Change N to Z in the above.  You still want to track the identity of the responsible party for audit purposes.  That requires something like Horton with ocaps, but it's automatic when using SAML assertions.
>
> With capabilities (NBAC?) authorization decisions are divorced
> from identities are instead based on capability (authorization?)
> that can be independently associated with subjects (active
> objects/processes).  With NBAC an authentication still provides
> a bootstrap access to a collection of capabilities
> (authorizations sound
> too much more like actions rather than like tokens to me).  After that
> there is some mechanism for transferring capabilities.  I
> could imagine
> such a mechanism to be independent of the means for transferring data.
>
Change N to Z in the above.  Correct, but I like to be more explicit.  I use the word "authorization" as the granting of the right.  I use the words "access decision" to denote whether or not to honor a request.  In many systems, such as ocaps and ACLs, these steps are combined.  In ZBAC, they can be separated.  You are granted a SAML assertion denoting your right to do something.  Later, you exercise that right, and some component verifies the validity of that assertion before honoring your request.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp