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 authenticator and custom partition
Date Wed, 25 May 2005 05:10:04 GMT
Marc Boorshtein wrote:

>  
>  
>
>>-          When the AuthenticationService.process()
>>loops through the
>>configured authenticator, it will try the
>>SimpleAuthenticator first by
>>default. Is there any way to disable this and just
>>loops over the
>>configured authenticator (see server.authenticators
>>properties)?
>>
>>
>>    
>>
>
>To be honest i don't really like the authenticator
>framework anyway...I think there should be a "bind"
>method in the partition.  The current setup seems to
>be tailor made for the jdbm partition implementation.
>  
>
Totally off Marc.  Bad pun :-) sorry. 

I disagree with the bind impl in the partition .. we might need some 
config or session info that can be accessed by the partition to get to 
this info but thats another story.   IMHO you are mixing protocol with 
storage mechs.  Not everything is designed for a VD implementation even 
though we want to virtualize so we need to be careful.

BTW ContextPartition is not tailored for a jdbm specific implementation 
at all.  Actually my first impl was using a relational database.  Boy 
that was slow anyway ...  the interface is tailored around the least 
common denominator for dealing with addressing LDAP namespace addressed 
entries, storing them and accessing them.  If we must warp this 
definition for a VD it must be within these bounds.  I've made sure the 
design followed these particular rules of thumb after 2-3 years of 
experimenting with the interfaces. 

I'm stressing this point (don't get bothered by it though) because your 
suggestions regarding the need for a bind op and that it is specific to 
a jdbm impl are missleading.  Either that or you're interests in 
virtualization are making you a bit myopic.  Again not trying to haze so 
please don't take this in the wrong way ... just being direct.

Take a step back and start thinking about the vanilla directory then the 
needs of a VD.  I think you'll see that we need an interface for 
ContextPartition to be the least common denominator ... simple as 
possible and it should not have protocol aspects mixed into it. But we 
do need more just don't have an idea of exactly what it may be.  David 
Borham had some good suggestions as well as yourself. 

>>-          In SimpleAuthenticator.authenticate(), if
>>the user DN is not
>>found it will throw an LdapNameNotFoundException
>>exception. But this is
>>preventing the AuthenticationService.process() 
>>to call the next authenticator. 
>>I think it should just throw an
>>LdapAuthenticationException exception.
>>What do you all think?
>>
>>    
>>
>
>In most directories i've seen this is the case (a dn
>that can't be found response with error 32, name not
>found).  I'm not sure if this is in the rfc or not.
>
>  
>
+1

>> 
>>
>>-          In the method authenticate() of my custom
>>authenticator, I
>>created an LdapPrincipal and returned it. I also
>>created a connection to
>>my own database, based on the 
>>principal that we are trying to authenticate, and
>>added that to the
>>ServerContext. 
>>Later on in my custom partition code, I want to be
>>able to retrieve both
>>the LdapPrincipal and the connection to my own
>>database.
>>It looks like only the method search() has an input
>>parameter (Map env)
>>with the environment associated with the
>>ServerContext. 
>>But I want to be able to retrieve this environment
>>also from other
>>methods (like modify, add and delete). 
>>Is that possible?
>>
>> 
>>    
>>
>
>Well, if youa re keying off of a bind dn then you can
>allways maintain a map based on that dn as an instance
>variable.  Though I do think there should be something
>to tie information to both a request and a connection.
>  
>
I htink Endi made some very good recommendations as well as Dave about 
propagating some kind of session information that contains relavent info 
like this so all methods can access it to make decisions.  Thread local 
sessions perhaps?   Anyway we need to foster the best ideas around 
this.  I added the env to search because it definately needed it.  I 
thinmk we might need it in every function and/or there should be an 
initialization of backends that gives them a context/session information.

We need more discussion on this.  Let's get a wiki page going with the 
options and try to make some descisions after lookning at all the pros 
and cons.

Alex



Mime
View raw message