Adrian Chadd wrote:
We'd be glad for any and all help you're able to provide!
Thanks for the warm welcome. I've started reviewing the LDAP-aware
helper programs to make them use a unified library, since they currently
duplicate lost of code. After this, they will all benefit of common
enhancements.
Right now, I've added detection of some LDAP related functions in
configure.in; a lib/ldaputil.c file that gets built into Squid's
miscutil library, a include/ldaputil.h header to be shared among
helpers. Please let me know if this makes any sense, or better
naming/location should be used.
Among the enhancements I plan to work at I see:
- support for SASL bind, if provided by the underlying libldap. This
would allow, for example, password-less binding using SASL EXTERNAL
based on IPC (ldapi:// URL, inheriting the credentials from the user the
helper is running as).
- support for password policy (draft-behera-ldap-password-policy; mainly
in squid_ldap_auth); this means that the related control can be added to
LDAP bind (and compare) requests and, in case of failure because of
password policy (like the account is locked, or so) the failure
notification can be augmented by appropriate logging. How this is
supposed to be dealt with by Squid it is yet to be decided; right now,
what I consider is to append the error message to the "ERR" string
that's returned by the helper. The draft also discusses returning
informative messages e.g. for approaching expiration or for being in a
grace period. This could also be worth logging.
- support for proxy authorization (RFC 4370); this would be mostly
useful when passwdattr is defined in squid_ldap_auth; in this case, when
performing an LDAPCompare, one could require the operation, which is
performed on a connection bound as the binddn identity, be actually
performed after authorizing as the user's identity. In squid_ldap_group
it could allow to access the group entry with the user's identity.
- support for session tracking (draft-wahl-ldap-session). This, if
considered useful, will require some changes to the way squid_ldap_auth,
squid_ldap_group and any other helper are used, since for each request
it will need to know the IP, the host and any user-related string Squid
is willing to pass to the DSA. In this case I think we'll need to
discuss if it is worth, and how this information can be best passed.
The rationale consists in letting the DSA know, for purely informative
reasons, where and who originated an LDAP operation that is run by a
middleware client (in this case, Squid) with a generic identity. This
can be quite important when tracking operations in very complex
deployments. OpenLDAP supports this draft in 2.4; when the control is
present, the related information is shown in logs, and forwarded to
chained DSAs.
I'm working at a relatively slow pace, so don't expect anything to be
ready within days. If you want to check the progress, I can regularly
post patches to current HEAD (squid3) code.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: [EMAIL PROTECTED]
---------------------------------------
