directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: Delegation of Authentication
Date Wed, 17 Nov 2010 13:51:24 GMT
On 11/16/10 10:20 PM, Kiran Ayyagari wrote:
> On Tue, Nov 16, 2010 at 10:05 PM, Emmanuel Lecharny <> 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 ;)
> 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.



View raw message