Re: AuthzIDs or DNs, but not both

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

I'm going to respond to Paul response and Bob's subsequent response in one shot.

Bob Blakley wrote:
> This is the heart of a discussion we've had several times before in this WG and which 
> I thought we'd resolved.

Well, I actually checked the archives before posting my authzid creatorsname thread.
I actually found very little on the topic.  Then, again, the discussions could have
taken place on ASID lists or offline.

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

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

would work just fine as well.  I plan to add general support for the above
in OpenLDAP as a "friendly bind" mechanism (which doesn't rely on anonymous
search).

I would like to hear from someone with operational experience using uAuthzIDs.
In particular, what impact did your use of uAuthzIDs have upon required and
optional requirements of LDAP protocol and information model?

> Essentially this amounts to the question of whether an LDAP server has a notion of its
> users' identities *AS LDAP USERS* or whether it's merely allowing all kinds of platform
> (and maybe non-platform) users into its DIT.

All authentication mechanisms described by RFC specify that authorization identity
is provided as an string of LDAP DN syntax.   It does not state whether or not this
DN is usable by the client in any other context.  That is, the DN used by the
client to bind to the directory not be necessarily be usable in any other
context.

> The position of the working group has consistently been (both on the mailing list and
> in the FTF meetings) that interoperable security for LDAP should be specified, rather than
> simply exposing the underlying platform security.

Which implies that we must have one representation of authorization principles that
can be used consistently in the information model.

> Paul wrote:
>>Users who are accustomed to a given principal 
>>name form should not have to learn the DN form. 

My suggestion is to restrict the protocol and information model to DN representations
of principals.  Client applications can easily map user provided principal
representation to a DN representation so that it may be carried by the protocol
as currently defined by RFC2251.  I've suggested one possible mapping to make
such generally usable and interoperable.

>This sounds plausible but carries many assumptions.  Users are accustomed to a variety of 
>different principal name forms, and to allow them to use these completely transparently
>*and* still have an interoperable environment, it would be necessary to have every server:
>  
>(1) be able to distinguish all principal name forms, and to determine to which name
>        form a given principal name conforms -- in the absence of explicit name-type >	indicators in some cases.

I believe my suggestion adequately addresses this issue.

>(2) be able to map all principal name forms to DNs.  Furthermore, in order to prevent
>        "identity mutation" when visiting different servers, it would be desirable to have
>        every server map every form of name to a DN in exactly the same way -- hence we'd
>        need a separate RFC describing the mapping for all "interesting" name forms
>        to enable heterogeneous, interoperable configurations.

Yes, I believe that the mapping should be made an RFC which describes both the
form and scope limitations.  (That is, the uauthz DNs are unique only within
the local context).

>(3) to be able to support authentication of all name forms (this would require doing the
>        mapping as a prerequisite to looking up authentication data in LDAP on the bind)

I suggest only one name form, DN.

>or else it would be necessary to have every client map the name form provided by the user
>into a DN prior to sending it to the LDAP server, but this is what Paul wants to avoid 
>in the paragraph below.

Well, the client needs to either map the user provided string into an authzid or
needs to map it into a DN... and the server needs to decode it.  The amount of
real work is the same.  The difference is one on-the-wire representation or two.
 
>>Client software should not 
>>have to turn the platform user name into a DN, only to have the server turn 
>>it back into the platform user name -- they should just take what the user 
>>typed and use that as the uAuthzId. Client software can't do this in a platform independent way.

>?? I'm confused... if there's a canonical way to turn each name form into a DN, then 
>the client can perform the transformation just as easily as the server.

Exactly.

>>So, yes, I believe it makes sense to have more than one representation. Unless 
>>that representation is UTF-8 string. 
>>And I think it makes clients and servers simpler, not more complicated. 

>I don't get this.... can you explain why?

The syntax of the uAuthzId attribute type can be DirectoryString.

>>> The fact that a server can map the uAuthzId to a DN implies 
>>> that the client can map a uAuthzId to a DN. 
>> 
>>That's a fallacy in all except the most trivial sense (that both sides are Turing complete).


>>The client may not, and sometimes should not, have all the information available at the server.

The server need not provide any information to the client to do the suggested mapping.

All the client needs to do is instead of creating an AuthzID of uAuthzID scheme
as suggested by the AuthMeth draft and instead maps the uAuthzID value to a DN
of the form uAuthzID=string.   This eliminates the need for a second on-the-wire
representation of authorization principals, eliminates the ripple of changes
to the information model cause by adding a second representation, and at no
apparent loss in functionality.