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

Re: SASL authentication for OpenLDAP (ITS#477)



My thesis defense:


> ldap.h: ldap_negotiated_sasl_bind()
>   should not eliminate binddn as argument.  routine should
>   independent specification of bindDN, authcId, and authzId.
>   Note: it usually for bind == NULL and authzId is often
>   NULL, but authcId is rarely NULL.
> 
>   should remove if(!authzId) authzId = authcId statement,
>   an empty authzId field should be sent instead.

I looked at this and the SASL code and as far as I can tell, SASL
authentication can only use 2 DNs, not 3. The bindDN gets sent with the
first bind call, and it gets put in c_cdn in the server's Connection
structure. SASL can then use the authorizationId in the SASL_CB_USER
callback. The 3rd DN that was in negotiated_bin(), called authenticationId
and used in the SASL_CB_AUTH, was never used. 
I wanted the server side SASL to force an authorization from the SASL name
to the bindDN, so that server side binds are always to a DN (keep LDAP
binds in the LDAP namespace).  That's why I did the "if !authzId"
statement. On the server, when the PROXY callback is being set up, the
"context" stored contains both the Connection structure AND the bindDN the
client used. The callback function then receives the SASL ID, the
authorizationID, the Connection, and the original bindDN. The function
makes sure the bindDN maps to the SASL ID, then a second check is done to
see if the bound DN is allowed to change to the authorization ID (if an
authorization change was requested)
  If you prefer that server side binds can be made to arbitrary names
outside the LDAP namespace, this can be changed around.  But that does
bring up some concerns. If I bind as some name in the SASL namespace, such
as "postman@cmu.edu", and I request that I be allowed to act on the behalf
of another identity, how does slapd know if "postman" is allowed to do
that, and where is that information stored? By making all binds happen in
the LDAP namespace, such information can be stored as attributes.



> options.c:
>   change should be extraneous

It's not. In several places in the SASL code that Luke wrote there are
checks that ld->ld_version is >= 3 for SASL.  The set_options code had
only been setting ld->ldo_version, leaving ld_version at the default value
of 2.  The version>=3 checks would fail and the client code would never
even attempt to connect to the server.

> 
> sasl.c
>   don't remove param error detection

There is an assert() for that param just above. One or the other can go.

> 
>   s/"ldapserver"/"ldap"/  ("ldap" is the registered service name).
> 
Oh yeah. My fault. I had been working with K4 authentication and was using
an "ldapserver.hostname" instance for a server key, as it required. When I
started work on SASL I just reused that instance.



> I also think we need to further discuss appropriate separation
> of authentication identities, authorization identities, and
> subject DN (for ACLs).

Yes, this loops back into the whole bindDN / authenticationDN /
authorizationDN issue.