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 Sat, 19 Feb 2005 04:49:05 GMT
Tencé, Vincent wrote:

>Alex,
>
>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.
>  
>
That sounds like a good idea in general however it might be a good idea 
for you to look into LDAP RFCs on authentication and authorization to 
get an understanding of how authx is done in LDAP according to RFCs. 
Namely we need to be up to speed with a couple of the following 
specifications.  Please note: you probably don't need to look at them 
all :).  Start with 2829 which is fundamental for LDAP authentication 
mechanisms.  Oh and 3112 is another good one to know too - this is a not 
much of a big deal though.

RFC 2820 - Access Control Requirements for LDAP
--------------------------------------------------------------------------------------------
http://www.ietf.org/rfc/rfc2820.txt


This document describes the fundamental requirements of an access 
control list (ACL) model for the LDAP directory service. It is intended 
to be a gathering place for access control requirements needed to 
provide authorized access to and interoperability between directories.


RFC 2829 - Authentication Methods for LDAP
--------------------------------------------------------------------------------------------
http://www.ietf.org/rfc/rfc2829.txt

This document specifies particular combinations of SASL mechanisms and 
extensions which are required and recommended in LDAP implementations.

RFC 3112 - LDAP Authentication Password Schema
--------------------------------------------------------------------------------------------
http://rfc3112.x42.com/

This document describes schema in support of user/password 
authentication in a LDAP (Lightweight Directory Access Protocol) 
directory including the authPassword attribute type. This attribute type 
holds values derived from the user's password(s) (commonly using 
cryptographic strength one-way hash). authPassword is intended to used 
instead of userPassword.


RFC 3062 - LDAP Password Modify Extended Operation
--------------------------------------------------------------------------------------------
http://www.faqs.org/rfcs/rfc3062.html

This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state and 
status of this protocol. Distribution of this memo is unlimited.

Also hese drafts might also interest you ...

draft-ietf-ldapext-acl-model -- Access Control Model for LDAP

This document describes the access control list (ACL) model for an LDAP 
directory service. It includes a description of the model, the LDAP 
controls, and the extended operations to the LDAP protocol. A separate 
document defines the corresponding APIs.

Cheers,
Alex

>To proceed, I need a few pointers to know where I should be looking at.
>
>Thanks,
>- Vincent
>
>  
>
>>-----Original Message-----
>>From: Alex Karasulu [mailto:aok123@bellsouth.net]
>>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
>>
>>
>>    
>>
>
>  
>


Mime
View raw message