RE: AuthzIDs or DNs, but not both

["Curtin, William" <curtinw@ftm.disa.mil>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.Org]
> Sent: Monday, November 15, 1999 8:30 PM
> To: Bob Blakley
> Cc: Paul Leach (Exchange); 'Kurt D. Zeilenga'; IETF LDAP Extensions WG
> Subject: Re: AuthzIDs or DNs, but not both
> 
> 
> I only raised this issue now because I just now realized the 
> impact of the addition
> of authzid to the protocol and information model.  The 
> functionality of authzid
> can be provided by mapping uAuthzIDs onto DNs.  It just as 
> easy for a client to
> provide DN "uauthzid=kdz" as it is to provide AuthzId "u: 
> kdz".  There is NO
> difference to the user!
> 
> (note: I switch to uauthzid attribute type to reflect that I 
> am mapping the
> uauthzid scheme of the authorzid).

I'm trying to understand this proposal. 

So are you proposing that there be a new object class, say 
authorizedUser, which MUST contain the uauthzid attribute and 
which is supported by a structure rule which allows this new 
object class to reside at the same level as Country, Organization, 
and Domain? If so, is this object class outside of the server's naming 
context? Does it carry other attributes about a user (e.g. phone, 
address, email, etc.) or are they found elsewhere in the DIT?
 
> As far as the issue that servers may want to provide some 
> other mapping, they
> are free to do so.  We have operational experience with 
> servers mapping the
> bind DN onto another DN.  I did this with "uid=kdz" -> 
> "uid=kdz,dc=openldap,dc=org".
> It works fine and doesn't require any protocol changes.  I 
> would suspect that
> 	uauthzid=kdz -> uid=kdz,dc=openldap,dc=org

Agree. From the server perspective there is probably no difference
between mapping u:kdz -> uid=kdz,dc=openldap,dc=org or
uauthzid=kdz -> uid=kdz,dc=openldap,dc=org

				bill