directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Custom authentication
Date Wed, 16 Feb 2005 02:21:17 GMT
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



Mime
View raw message