directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Delegation of Authentication
Date Wed, 17 Nov 2010 03:20:22 GMT
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
>> 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.

> 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

-- 
Kiran Ayyagari

Mime
View raw message