Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of antoine@gmx.de designates
 213.165.64.23 as permitted sender)
Message-ID: <4CE3DDDC.1070109@gmx.de>
Date: Wed, 17 Nov 2010 08:51:24 -0500
From: Antoine Levy-Lambert <antoine@gmx.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Delegation of Authentication
References: <4CE2B053.6050607@gmx.de>	<4CE2B2C9.8040109@gmail.com>
 <AANLkTim6E9wdDpwJwP2=U=SGTjP7FbS+A5ZvOtaC6sAq@mail.gmail.com>
In-Reply-To: <AANLkTim6E9wdDpwJwP2=U=SGTjP7FbS+A5ZvOtaC6sAq@mail.gmail.com>
OpenPGP: id=265B4C63
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 11/16/10 10:20 PM, Kiran Ayyagari wrote:
> On Tue, Nov 16, 2010 at 10:05 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>> On 11/16/10 5:24 PM, Antoine Levy-Lambert wrote:
>>>  Hi,
>>>
>>> I am going to start today writing an implementation of the delegation of
>>> authentication. Once I will have written something that works I will attach
>>> my code to JIRA [1].
>> Great !
> yeap, Great !!
>>> I plan to use the JNDIRealm [2] [3] of tomcat as a reference to know how
>>> to configure and implement the delegation of authentication.
>> What would be better is to use the Apache LDAP API which is available and
>> works pretty well at this point. It's available in the client-ldap-api
>> project.
> right, and as your code will be part of the server, you have all that
> needed to talk to a LDAP server.
>>> Funny, I thought that perhaps there was a magic LDAP API to know whether a
>>> password is valid and it turns out that JNDIRealm actually binds the user to
>>> the target LDAP server to find out whether his/her credentials are valid.
>> There is no way to check that a password is valid. Passwords aren't stored
>> in the server, we just keep a Hash value. So you have to compare the hashed
>> value of the Password you just got with the stored hashed value of the
>> user's password. This is done internally in the server, so the best solution
>> is always to do a bind, which handle the comparison (including the selection
>> of the algorithm) with the stored hashed value.
> instead of doing a bind to remote server there is another way if the
> user entries are stored locally on ApacheDS, it is a two step process
> 1. get the user entry from the ApacheDS
> 2. use the PasswordUtil class to compare the given password with the
> stored one, this method will
>     work for hashed passwords too
I was planning to do this for user entries which are not stored locally
on ApacheDS.
>>> What would be the steps to implement this ? I guess I should start by
>>> listing the attributes needed to do this delegation of authentication, then
>>> create a new object class in the adsconfig schema, for instance
>>> adsAuthDelegation and the corresponding attribute types for instance
>>> adsAuthDelegationURL.
>> The problem is mostly to know when to call the remote server. If you can
>> know that a user credential is not managed by the server, then you can do a
>> bind to the remote server and if it succeed, bind the user locally. All of
>> this should be done in the AuthenticationInterceptor, in the BindMethod, by
>> adding a specific Authenticator. Sadly, we don't currently have a way to
>> tell that a user should be authenticated outside of the server, so we try
>> all the existing authenticator until at least one authenticate the user.
>>
>> But OTOH, that just means you simply have to implement an Authenticator and
>> add it into the configuration, possibly putting it at first place in the
>> Authenticator list.
>>
>> I hope I'm not 100% wrong, but checking the current code, it seems I'm not
>> totally off base...
>>
> yes, as Emmanuel suggested the best solution would be to implement a
> Authenticator
> (we may call it DelegationAuthenticator) and just need to register
> with AuthenticationInterceptor
> once you get this working I can add the support for configuring it in the DIT.
Thanks, I will do it that way then.
>> Anyway, I'll be around to give an hand if needed.
> yes, Emmanuel lives in IRC room #apache-directory-dev on irc.freenode.net ;)
> joking aside, you are welcome to join for any assistance if required
>
OK, I will install an IRC client on my Mac. I think I used IRC only once
long time ago, I forgot all about that.

Regards,

Antoine