directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tencé, Vincent" <>
Subject RE: Custom authentication
Date Fri, 18 Feb 2005 15:01:45 GMT

It may be time to look into integrating authx with the server. Even if it
does not happen to be a good fit right now, it will for sure shed light on
integration issues and what is needed as a pluggable authentication service.

To proceed, I need a few pointers to know where I should be looking at.

- Vincent

> -----Original Message-----
> From: Alex Karasulu []
> Sent: February 15, 2005 9:21 PM
> To: Apache Directory Developers List
> Subject: Re: Custom authentication
> Endi Sukma Dewata wrote:
> > Hi,
> >
> > I have a question about implementing custom authentication on 
> > ApacheDS. I understand that currently authentication is 
> handled at the 
> > Interceptor level by the AuthenticationService which in version 0.8 
> > only supports plain text password. The way it works now is that it 
> > will look up the userPassword value from the backend partition and 
> > compare it with the user supplied password.
> >
> This is correct.
> > In our virtual directory product we have a need to be able 
> to perform 
> > authentication against different types of servers such as 
> NT server, 
> > LDAP server, etc., that most of which do not give you back 
> the stored 
> > password, not even the hash value. In other words, there is 
> nothing to 
> > compare with the user supplied password. The question is, if we 
> > integrate the virtual directory as a backend in ApacheDS, 
> how should I 
> > handle this kind of authentication?
> >
> Good point. Perhaps we need to use pluggable Authenticators. 
> Would that 
> help?
> > One way is to add a custom authentication Interceptor into the 
> > pipeline of Interceptors.
> >
> Ahh you're already there hehe. Good!
> > However, I don’t think that this would work as long as 
> > AuthenticationService is still in the pipeline too. This is because 
> > the AuthenticationService will get invoked anyway, 
> regardless of the 
> > order of invocation. When it gets to that point, it will 
> still try to 
> > get the userPassword from the backend, compare it the old way, and 
> > throw an exception since the userPassword is not present, 
> so the whole 
> > operation will still fail anyway.
> >
> What we can do is have the AuthenticationService expose some kind of 
> Authenticator SPI. We can have it switch Authenticators based on name 
> space hence the backend being hit. We should make the auth 
> mechanism as 
> plugable as possible. This is something to really discuss.
> > Another way is to replace the AuthenticationService altogether with 
> > the custom authentication, but I don’t think we want to do this.
> >
> Ok let's then build some way in which the service can switch the auth 
> mech based on the parameters of the request. We can register an auth 
> mech implementaion, an "Authenticator" impl, with the service using a 
> subtree spec. If the entry in the target bind DN is matched 
> by the spec 
> then we use that Authenticator and short or continue like a PAM based 
> system. Hmmm let's brain storm this one. It is very interesting.
> > In my opinion, the authentication should be delegated to 
> the backend 
> > partition. So, instead of calling lookup() method, the 
> > AuthenticationService should call something like bind() and 
> pass the 
> > user supplied password as-is to the backend. The backend 
> knows how to 
> > work with the password, whether to compare it directly or 
> to perform a 
> > login operation.
> >
> That is a bad move IMHO. The whole point to using interceptors is to 
> make this service (authentication) something that back end 
> implementors 
> do not have to worry about. By asking backends to do this, all 
> implementations will have to handle auth with most 
> duplicating the same 
> code within the service.
> What we can use a custom Authenticator if we design this 
> correctly. The 
> custom Authenticator may use your backend to do its bidding.
> > Any advice would be very appreciated. Thank you very much.
> >
> Let me know what you think about making Auth mechanisms pluggable by 
> making the AuthenticationService manage these authenticators. If you 
> want to do this then I can help you out.
> Cheers,
> Alex

View raw message