[cap-talk] What we have here is a failure to communicate

[Karp, Alan H]

Jed wrote:
>
> To me the OCap model does "conflate" authentication and authorization.
> That is, the possession (as evidenced by communication) of a capability
> demonstrates that the communicating subject is authentic (in that it
> apparently possessed the communicated capability) and is authorized to
> access (in the sense of "access control") whatever the capability
> grants (permits) access to.
>
Monty Zukowski wrote:
>
> What would really help me is an example of authentication without
> authorization and vice-versa.
>
Rob Meijer wrote:
>
> When defining authentication in general, I feel an important point to
> make
> is that what is needs to be authenticated for the sake of access
> control
> is the "source of authority", while what needs to be authenticated for
> the
> sake of auditing is the "source of accountability".
>
While there seems to be a single, agreed to meaning for "authorization", there isn't for "authentication."  For example, people talk about authenticating the integrity of a document and authenticating a letter of authorization.  That means we have to be sure to say what we mean when using the term.  Henceforth, I will try to use the "subject authentication".

I divide the access control process into four steps.

1. Identification: When I started work at HP, the security office checked my driver's license, took my fingerprints and verified my DNA.  (OK.  Not the DNA part.)  That's how they know who to throw in jail if I do something bad.  The security office then granted me the means to authenticate as an HP employee who works at HP Labs.

2. Authentication: My login authenticates me as a subject who is an HP employee who works at HP Labs.

3. Authorization: The system knows that an HP employee is granted the authorization to use the Corporate portal, and an HP Labs employee gets the authorization to use the research library.

4. Access decision: The authorization is checked when a request is made to see if it is valid for the request.

Not all of these is applicable for every access control mechanism.  None of the access control models I know deals explicitly with identification, but it's necessary for responsibility tracking.

Consider ACLs.  Adding an account allows that user to authenticate as a particular subject.  Adding an ACL entry for that user for a resource is an act of authorization.  The access decision depends on the result of checking the ACL when a request is made.

Ocaps don't authenticate the subject, and the access decision is implicit in the authorization.

The last three steps are explicit with ZBAC.  A SAML assertion is an authorization issued to a public key.  I consider proof of knowledge of the corresponding private key to be an authentication.  The SAML assertion is checked to make an access decision.

Unfortunately, I still run into statements that conflate two or more of these steps, such as the one that started this thread.

________________________
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