[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.