Re: createSaslClient by the Java LDAP API

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

At 09:56 PM 4/5/01 -0700, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> The dn parameter is the bind name, the authzId parameter is the
>> SASL authorization identity.   That's a one-to-one API parameter
>> to protocol element relationship, I see no ambiguity.
>
>  OK, but if authzId IS null or empty, then the DN should be used as the SASL authorization identity?  Or should the server derive the authorization identity from the authentication identity?

no, yes.

A client should not assert an authorization identity unless it
wishes to assume an authorization identity different from that
implied by the authentication identity.

Also, I note that a client should not assume any authorization
identity it might derive from its authentication identity will
be treated by the server as being equivalent to the authorization
identity it would derived from the authentication identity.

>For my own edification, not having experience with a directory that handles authzIds other than DNs:
>
>  What are the respective influences of the authzId and the bind DN (which is not the authentication DN) on the authority of requests issued after successful authentication?

In general, server implementations ignore the bind name when
provided in a SASL bind request.  However, as the language of
RFC 2251, 4.2 implies (in an odd way), the server might make
use of the bind name when the SASL credentials do not contain
an LDAP DN.

First, I'll elaborate on possible uses in absence of a
client asserted authorization identity.  The server could
just log the bind name.  Or the server could use it to
restrict the realms advertised (there was a thread
discussing this use some years ago).  Or, (as I think the
authors of 2251 had in mind), the server can use the bind
name to locate an entry associated with authentication
identity.  This entry might contain the mechanism specific
secret and/or other information the server needs for the
mechanism.  Upon completion of the authentication, the
DN of this entry (or other information in the entry) might
be used to establish the authorization identity associated
with the session.

Second, in the present of a client asserted authorization
identity, the server may (in addition to the above) rely on
this entry to support evaluation of the proxy authorization
policy.

>Is it possible that one of the two could imply rights which would not be available to the other? Or does the bind DN no longer affect authorization if there is a separate authzId?

It is possible that the server might not be able to establish
the authentication and/or authorization association without a
bind name.  However, the rights granted to the client are
those associated with the authorization identity regardless
of whether it was asserted by the client or derived from the
authentication identity.  The bind name, at most, would be
providing an association between the authentication identity
and an entry used to support the authentication/authorization
process.

Lastly, I note there are a number of security considerations
(namely the bind name is not protected by the mechanism) and
other practical matters (users should need to know their DNs)
which limit cases where a bind name should be provided and
used.  I generally recommend that clients not specify a bind
name and that servers ignore the bind name.

However, I do support the SASL bind() methods having both dn
and authzid parameters as I believe the API should be complete
(support all exchanges allowed by the protocol).

Kurt