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

Re: comments on draft-ietf-ldapext-authmeth-01.txt



Mark Wahl wrote

>Authorization identities presented to LDAP servers by clients through
>SASL mechanisms are and should remain the string form of LDAP Distinguished
>Names.

I strongly agree with this.  The subject namespace used by LDAP servers for
authentication and authorization should be the LDAP native namespace -- i.e.
LDAP DNs.  Anything else creates not only complexities in the parsing mechanism
but also complicated trust problems involving who's empowered to assert names
in which parts of the namespace, and which parts of the namespace any given
server
is willing to recognize.

>There are already specifications and/or conventions of mechanisms for
>representing other forms of identifiers, such as URLs, domain names and RFC 822
>mail addresses, as attributes, and I believe it would be possible to specify
>most any other type of authorization id as a representation in an attribute
>type and value and thus be usable in a DN.

I too believe this is true and in fact we'll describe a way to do it
at the LA meeting (this is part of our access control draft.)

>Allowing arbitrary strings in place of DNs would lead to a significant
>interoperability problem: how does a server recognize a string as belonging to
>a particular method of authorization, how could it route the authorization
>process to the appropriate component for verification, and how could a set of
>cooperating servers interwork without a common or replicatible mechanism for
>performing access control checks?

Agree again.  LDAP servers maintain a nice convenient namespace and have a
defined user schema in which we can store authorization data such as privilege
attributes etc....  Ignoring this pre-existing structure and instead allowing
subjects to be represented completely arbitrarily requires a large amount
of work for very little benefit I can see.

--bob

Bob Blakley
IBM Lead Security Architect
+1 512 838-8133
blakley@us.ibm.com