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

SASL LDAP plugin



Fyi, I've just gotten this LDAP auxprop plugin working with the Cyrus sample
server. So now arbitrary servers can perform SASL authentication against the
secrets stored in LDAP.

Any suggestions on where to put the source file? It's a single C source
file, needs to #include ldap.h and a variety of sasl header files. The
resulting shared object needs to be installed in /usr/lib/sasl2 (or wherever
the SASL2 plugins are installed).

The code has these basic pieces:

plugin_init - grabs ldap_uri, ldap_id, ldap_pw, ldap_mech, and ldap_rc from
the server's SASL config file. The ldap_uri is required, the rest are
optional. You can use the ldap_rc keyword to point to an LDAP config file
that will be read when the LDAP library initializes itself.

lookup - calls ldap_initialize, sets the LDAP session to LDAP_VERSION3, does
an interactive SASL bind with ldap_id as the authcid, and the SASL client's
username as the authzid. Then does a WhoAmI, then does an ldapsearch on the
returned name (which must be a DN) to retrieve the requested SASL
attributes,
and then does ldap_unbind.

I chose this approach because it requires minimal setup on a remote
machine - you just need to know the LDAP server's URI, and a valid SASL
username and password.
All the "picky" configuration details are taken care of in slapd, you don't
need to specify search bases and filters on the remote machines.
The chosen SASL ID must map to an entry that has the privilege to
proxy-authenticate as any other SASL user. You obviously must establish
mapping rules to associate valid DNs with all your SASL users.

For my test, I configured slapd with an ldapi listener, then created a
"cn=root" user with saslAuthzTo set to "cn=.*,<user subtree>". I added
saslAuthzTo, saslAuthzFrom attributes and OpenLDAPsaslProxy aux objectclass
to my copy of openldap.schema just to get things rolling. So my SASL
sample.conf file contained
	ldap_uri: ldapi://
	ldap_id: root
	ldap_pw: secret
	ldap_mech: PLAIN

For a remote test I use
	ldap_uri: ldaps://somehost
	ldap_rc: /some/ldap/config/file

and in the LDAP config file I set the TLS certificate parameters to allow
binding with a client X.509 cert, SASL_MECH EXTERNAL, etc... I suppose it
would be good to provide a SASL config keyword to choose StartTLS instead of
using ldaps.

For the remote case I'd like to use back-ldap to consolidate the SSL
traffic. Since we currently can't associate different IDs with individual
operations, this would require back-ldap to serialize all of the traffic
over the shared connection. Also, back-ldap currently doesn't support
extended requests, so the WhoAmI request will be lost. I think these
limitations really hurt the usefulness of this plugin at the moment, at
least from a performance standpoint. But it's a step forward...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support