directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <mboorsht...@yahoo.com>
Subject Re: custom authenticator and custom partition
Date Wed, 25 May 2005 10:47:34 GMT

> >
> Totally off Marc.  Bad pun :-) sorry. 
cute :-).

> 
> 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.
> 

It's not that i am mixing protocol with storage
mechanisms, but that i see the Authenticator API as
being an over complification of a process that is
invariably tied to the partition when dealing with
anything except a jdbm based partition.  ie if you
have an ldap partition you want the remote server to
handle the bind.  If you are using a database you
would want to get the user from that DB and then
perform the password compare.  Either way the addition
of a bind (or authenticate or whatever you want to
call it) should be tied to the partition instance.

> 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. 
> 

Let me restate, the interface is tailored for local
storage.  You may not have been thinking that at the
time, but thats what it is.  LDAP is it's self almost
a lowest common denominator (minus DNs).  This is why
most web services either use or are very similar to
DSMLv2 with respect to identity information (SPML is
basicly DSMLv2 with async calls and a wider range of
naming options, SAML's attribute assertions are very
close to LDAP entries).

I really don't see the issue with having the auth
method as part of the partition.  It just seems to
make the most sence (even from a pure packaging
standpoint).  You're going to want to know which
context the person is a member of in order to make a
lot of desisions about how to authenticate and you
can't allways assume you are going to search for the
user and then perform the auth.

> 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.
> 

I understand your concern but just remember that i
have 2+ years in building and deploying virtual
directories in production environments.  I've seen
what works and what doesn't so dont mistake myopia
with good advise :-)  I've only scratched the surface
on what's at issue in apache ds to make it a virtual
directory.  I wasn't kidding when I said a VD is a
hell of a lot more then a mapping tool :-)


> 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. 
> 


what's more LCD then a partition interface with:
1.  Add
2.  Modify
3.  Delete
4.  Rename
6.  Search
7.  Bind/authenticate
8.  Each method can take an object that has connection
information and request information (including a map
for arbitrary data and a list of controls)
9.  Name's need not be DN's (flat namespace INSIDE the
partition)..if the partition doesn't recognize
namespace then something higher is responsible for
forming a DN.

I really don't see what can be less of an LCD.  If the
underlying mechanism doesn't support a particuler
call, thrown an error 53 (or whatever else is
appropriate).  

How about this, instead of making assumptions based on
a vanilla directory, why don't you analyze how
smoothly data should flow through a system?  the fewer
branches and breaks in logic the faster the river will
ultimatly flow.

> 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?   

+1

>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.
> 
+1

> 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.
> 

+1

Marc
> 
> 
> 


Mime
View raw message