Subject: RE: AuthzIDs or DNs, but not both

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 11:56:01 -0800

At 01:47 PM 11/15/99 -0500, Curtin, William wrote:
>Perhaps the use of the word INTERNAL was a poor choice. By internal I meant
>that the server would map the uAuthzId used for authentication into the
>distinguished name associated with the uAuthzId to support operational
>attributes, access control, etc. Is there a better way to phrase it?

The key issue I am raising is whether or not it makes sense to have more
than one protocol representation of authorization principals.  I believe
only one is necessary and that a second is an unnecessary complication.

The fact that a server can map the uAuthzId to a DN implies
that the client can map a uAuthzId to a DN.  Hence, there is
no need for the second protocol representation as the client can do
this mapping.  We just need to describe how the mapping should be
done to make it generally useful.

Kurt

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: [email-masked] (Mark C Smith)
Date: Mon, 15 Nov 1999 16:05:03 -0500

> done to make it generally useful.

I don't think we should mandate a single algorithm to map a given kind
of authorization ID to a DN.  Why not?  Because the right solution is
likely to be site / deployment specific.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 13:43:52 -0800

>likely to be site / deployment specific.

I did not mean to imply a "mandate".  I want to provide a mechanism
to allow clients to represent uAuthzId as DNs to eliminate the need
for a second representation.  The same mechanism can obviously apply
to other authzid scheme that might be suggested.

As for you point that the site / deployment may want to map the
authorization identifier to some other DN, I see no problem with
allowing it do so.  This can be done by the client or the server
and doesn't require an authzid on-the-wire representation.

Kurt

----

---

From: [email-masked] (Mark C Smith)
Date: Mon, 15 Nov 1999 17:31:54 -0500

> and doesn't require an authzid on-the-wire representation.

But if the LDAP server is the entity that knows how to perform the
mapping, you need to send the authorization id to the LDAP server,
right?  I don't think it is safe to assume that clients will know how to
perform the correct mapping; this kind of policy is typically managed by
server administrators.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 1999 05:26:30 -0500

At 11:56 15.11.99 -0800, Kurt D. Zeilenga wrote:

>this mapping.

Not necessarily - the mapping may be done by:

1) data in the directory that is not accessible to the client before the
    BIND operation is done
2) data that is not accessible to the client at all

Examples related to things I've heard or seen:

- AuthzID is a Kerberos identity, with the mapping stored in the Kerberos
   database
- AuthzID is an NT domainname/username combo (cn=user,cn=domain), with a
   mapping to a globally unique DN stored in the server
- AuthzID is an Unix login, with the DN created by appending the DN of
   the organization from a server-side config file

In all these cases, the reasoning is that the client should only specify
what he can reasonably be expected to know, and that configuration should
be done on the server side only.

                       Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Nov 1999 05:07:37 -0800

>Not necessarily - the mapping may be done by:

Yes, my statement only applies to mappings which are not dependent
upon private information.   The mapping I suggest, actually, it's
more of an encoding, only requires that both client and server
implement a common specification for transporting arbirary user
provided authentication identitiy strings.

Authmeth/Start_TLS suggest that such strings be encoded by the
client as an AuthzID of the form:
	"u: string".

I suggest that such strings be encoded by the client as a DN
of the form:
	"uauthzid=string"

In both cases, the user provided authorization identity string
is transported to the server.

In both cases, the server may translate the provided
information into some other DN space.  (In the authzid case,
IMO, it SHOULD translate into some DN space).

The difference is that authzid requires adding a new on-the-wire
representation of authentication identifiers and only works
with operations which have been extended to support authzids.
The uauthzid, becauses it utilizes the existing on-the-wire
representation, may be more widely used.

Regards, Kurt

----