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

Re: createSaslClient by the Java LDAP API

"Kurt D. Zeilenga" wrote:
> 
> At 08:06 AM 4/5/01 -0700, Rob Weltman wrote:
> >"Kurt D. Zeilenga" wrote:
> >>
> >> At 08:11 PM 4/4/01 -0700, Rob Weltman wrote:
> >> >"Kurt D. Zeilenga" wrote:
> >> >>
> >> >> The Java LDAP API appears to be responsible for
> >> >> calling createSaslClient() method of the Sasl class
> >> >> which requires as a parameter:
> >> >>
> >> >>       authorizationID The possibly null protocol-dependent
> >> >>                      identification to be used for authorization, e.g.
> >> >>                      user name or distinguished name. When the SASL
> >> >>                      authentication completes successfully, the entity
> >> >>                      named by authorizationId is granted access. If
> >> >>                      null, access is granted to a protocol-dependent
> >> >>                      default (for example, in LDAP this is the DN in
> >> >>                      the bind request)
> >> >>
> >> I would suggest the addition of a separate argument to the
> >> SASL bind() methods:
> >>         authzId         If not null nor empty, an LDAP authzId (RFC2829).
> >>                         This parameter SHOULD be passed to the SASL layer
> >>                         unmodified.
> >
> >  That would cause ambiguity if both a DN and an authzId were supplied.
> 
> 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?

  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? 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?

Rob