[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: KerberosId/UserID/access-id (two)



At 11:07 PM 4/17/00 -0500, Ellen Stokes wrote:
>Kurt,
>
>I'm a bit confused here about your authzID proposal.
>
>I understand that you want to change access-id to authzID as defined
>in the authmeth spec.   authzID is carried in the SASL credential field.

Or otherwise implied.

>The problem I have with this that one of the mandatory methods of
>authentication (per authmeth spec) is simple password over TLS
>which does not even use SASL so no authzID can even be carried
>in that flow.

Which form of authentication used does not limit the forms of
authorization.  If "simple" authentication is used, I presume
that the authorization identity implied dn:bindDN were bindDN
is the name of the entry provided in the bind operation.

>So, if the ldapACI specifies authzID, there is no way to
>ascertain that information short of providing some type of internal
>mapping of authenticationID by the server.

How the server maps a given authentication identity (form is
mechanism dependent) to an authorization identity (who's form
is defined by AuthMeth) is implemenation specific.

>Perhaps the assumption
>is that if simple password over TLS is used, then the authzID equates
>to the authentication identity passed in the bin?

Actually, this is a bad assumption.  The server is free to map
the provided authentication and/or authorization identity upon
receipt.

The question here is one of syntax.  What forms of authorization
identities (access-id) should LDAPaci's support?  I suggest that
there be one form, authzid.  This allows both DN and arbitary
UTF-8 forms of identities and provides a mechanism for future
extension.