[Date Prev][Date Next]
Is ->LDAP->SASL->SASLAUTHD->LDAP the only way... further information
I have found the following note from Kurt Zeilenga:
"To find out exactly what it is, you'll likely have to read the source
SASL in-directory storage of authentication secrets provides a mechanism
to use authentication secrets held in the directory in lieu of secrets
held externally (e.g., SASLdb or other store accessed through Cyrus
SASL). This is not yet detailed in the OpenLDAP 2.1 Admin Guide.
I believe both are working... but I don't necessarily consider them
finished... I assume they will be refined over time."
Is this feature still not documented outside the source code?
Sent: Thursday, April 01, 2004 10:01 AM
Subject: Is ->LDAP->SASL->SASLAUTHD->LDAP the only way...
My application needs to allow people to use their web browsers to access
a web server over the Internet to update their LDAP identity details on
OpenLDAP. In effect, slapd's client would be the web server acting on
behalf of the end user. It looks to me as though a good way of doing
this would be proxy authorization to slapd. In other words, the web
server would authenticate to slapd using a "service account" and
authorize as the end user. After that, the web server could update the
end user's details on slapd. It makes sense that all the end user's
information - including his credentials - should be stored in the
After 50 or more hours research on the Internet, including reading
scores of posts on this forum, reading the man pages for OpenLDAP and
Cyrus SASL and actually trying various configurations, I am left with
few options. OpenLDAP uses SASL for proxy authorization. If SASL is to
use LDAP identities and credentials, it looks as though it needs to use
If necessary, I will go down this path, but it does look a little
circuitous. Are there any alternatives which satisfy the following
1. Allows web server to act on behalf of end user (impersonation, proxy
authorization, pass-through of credentials)
2. Allows the directory - and preferably the user's entry in the
directory - to be the single store for user information, including
3. Minimizes complexity.
My fantasy is that OpenLDAP could handle proxy authorization without the
need for an external daemon which itself has to authenticate to slapd.
The information contained in this e-mail message and any attached files may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete all copies of this transmission together with any attachments.