RE: Is ->LDAP->SASL->SASLAUTHD->LDAP the only way... further information

["GLASSON,Michael" <michael.glasson@dewr.gov.au>]

Thank you for your prompt response. Is the relevant section of the Admin
Guide, "Mapping Authentication identities to LDAP entries"? I am
guessing that if there is a mapping from the authentication identity to
an LDAP entry, then that entry's userPassword attribute would be used?
Or is it done another way?

If you could tell me which part of Admin Guide Chapter 10 to look at, I
might be able to work it out.

-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com] 
Sent: Thursday, April 01, 2004 10:42 AM
To: GLASSON,Michael; openldap-software@OpenLDAP.org
Cc: mg@netspeed.com.au
Subject: RE: Is ->LDAP->SASL->SASLAUTHD->LDAP the only way... further
information


> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of 
> GLASSON,Michael

> I have found the following note from Kurt Zeilenga:
> 
> "To find out exactly what it is, you'll likely have to read the source

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

Why not read the Admin Guide and see for yourself.
http://www.openldap.org/doc/admin22/sasl.html

saslauthd is completely unnecessary when using OpenLDAP as the
authoritative database for authentication.

I'm not sure if mod_auth_ldap for Apache supports LDAP SASL Binds. The
code you need on the web server also depends on what forms of
authentication you plan to support for the actual web pages.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support 
 
>  -----Original Message-----
> From: 	GLASSON,Michael  
> Sent:	Thursday, April 01, 2004 10:01 AM
> To:	'openldap-software@OpenLDAP.org'
> Cc:	'mg@netspeed.com.au'
> 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
> directory. 
> 
> 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 SASLAUTHD.
> 
> If necessary, I will go down this path, but it does look a little 
> circuitous. Are there any alternatives which satisfy the following
> criteria:
> 
> 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
> credentials.
> 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.
> 
> Michael Glasson
> 
> 
> Notice:
> 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.
> 
> 
> 
> 

Notice:
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.