Re: Authmeth/DIGEST-MD5

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

On Fri, 23 Jul 1999, David Chadwick wrote:

> Bob (Morgan) said:
> 
> > A client binds as some authorization identity so as to exercise the
> > privileges associated with that identity.  The client asserts an
> > identity that it wants to use via any or all of:
> > 
> 
> Can I clarify my understanding of this please.
> 
> A client binds as an authentication identity, and presents an 
> authentication token to prove his identity. 

And also, optionally, an assertion of the authorization identity it wants
to use.

> There then has to be some 
> internal mapping in the server between the authenticated identity 
> and the authorisation identity. This mapping is beyond the scope of 
> the LDAP work, but in the simplest case is null. (In other cases it will 
> be to map a LDAPDN into a username as present in an ACI.)

Yes.  I think that establishing some common approaches to doing this
mapping (eg mapping a Kerberos principal to a DN) is useful to provide
some consistency, but this would be in the category of suggested
conventions for server ops, not protocol specs.

> The text below uses authentication and authorisation identity almost 
> interchangeably, and I believe this is wrong. 

Well, I was trying to use these terms carefully and think I did so, and
was consistent with the descriptions of these concepts in authmeth.
Perhaps you can clarify what sentences you have a problem with.

> A client first authenticates and if successful is then authorised.
> Does anyone disagree with this?

As Bob Blakley suggests, this is a little too simple.  The client presents
authentication info, and possibly other info about what identity it wants
to use.  The server verifies authentication credentials, then determines
whether the presented info is acceptable to proceed with the connection;
otherwise it sends an error response (we might call this "authorizing the
connection").  If the connection is acceptable, the server performs
whatever mapping magic it wants and ends up with some state about this
connection, possibly (probably) including a single identity that
represents the derived concept of the client's identity (the
"authorization identity").  When the client subsequently sends operation
requests on that connection, the server uses the per-connection state
(which I would call "authorization state"; might also include IP address
etc) and whatever else it needs (time of day, load, etc) to decide whether
to perform (ie, to "authorize") that operation; this will obviously also
involve expressions of access-control on the directory resources involved
in the operation.  The per-operation authorization is IMHO the point of
all of this.

 - RL "Bob"