On 11/16/10 10:20 PM, Kiran Ayyagari wrote: > On Tue, Nov 16, 2010 at 10:05 PM, Emmanuel Lecharny <[email protected]> > 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
