LDAP as trusted third party authentication service (Re: RFC2256: userPassword)

[Frank Siebenlist <frank@dascom.com>]

Believe what you really need is a protocol that allows the authentication handshake to be proxied from the client through the application server to the ldap server.
This would allow one to use the hashing-based algorithms on client and ldap such that the intermediate app server never ever sees the password, not even for an instance.
The proxy-path from the app server should be secured separately, i.e. tunneled through an authenticated and integrity protected communication channel, such that the "verify" operation can be ACLed with respect to the requester, i.e. the app server.
The client wouldn't need the whole ldap client, just the authentication piece.
The authentication protocol itself should be initiated and driven by the app server.
The end result is the ldap server telling the app server whether the client is authenticated.

Not sure if the described protocol is equivalent to Novell's "verify password" or the before mentioned "proxy authentication".

To use ldap as a generic authentication service, wouldn't we need this kind of protocol?

-Frank.


Bruce Greenblatt wrote:
> 
> Novell Directory Service has this extremely useful operation "Verify
> Password" that is available through its API set.  This allows third party
> applications to authenticate users to its service in a way that is
> integrated with the directory without acutally have to log in to the
> directory on their behalf.  So, the application knows the user's password
> for an instant...  Is this type of operation generally useful???
> 
> Bruce
> ... 

-- 
Frank Siebenlist              DASCOM, Inc. 
Chief Architect               3004 Mission Street
Email: frank@dascom.com       Santa Cruz, CA 95060, USA
Phone: +1 831/460-3600        Fax: +1 831/460-0255