Delegation of Authentication

[Antoine Levy-Lambert <an...@gmx.de>]

  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].

I plan to use the JNDIRealm [2] [3] of tomcat as a reference to know how 
to configure and implement the delegation of authentication.

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.

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.

Then write a new bean class to hold the connection parameters for the 
delegation of authentication.

Does the adsAuthDelegation fit in the DIT under adsLdapServer ?


Regards,

Antoine


[1] https://issues.apache.org/jira/browse/DIRSERVER-1422

[2] http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm

[3] 
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java

Re: Delegation of Authentication

[Antoine Levy-Lambert <an...@gmx.de>]

On 11/16/10 10:20 PM, Kiran Ayyagari wrote:
> On Tue, Nov 16, 2010 at 10:05 PM, Emmanuel Lecharny <el...@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

Re: Delegation of Authentication

[Kiran Ayyagari <ka...@apache.org>]

On Tue, Nov 16, 2010 at 10:05 PM, Emmanuel Lecharny <el...@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

Re: Delegation of Authentication

[Emmanuel Lecharny <el...@gmail.com>]

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 !
>
> 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.
>
> 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.
>
> 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...

Anyway, I'll be around to give an hand if needed.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com