directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Boorshtein" <>
Subject Re: [ApacheDS] Specifying application level subtrees?
Date Sat, 22 Sep 2007 00:11:07 GMT

On 9/21/07, Emmanuel Lecharny <> wrote:
> Hi Marc, Alex,
> just a small comment in the body
> > > IMO LDAP was too lightweight in an adverse reaction to the
> > > OSI
> > > weight of X.500.  So now people realize we have to embrace X.500 concepts
> > > and in particular the admin model.  Lookie here ..
> > >
> > >
> > >
> >
> > OK, so this is starting to get really philosophical but I think LDAP
> > is just fine.  LDAP is a directory ACCESS protocol.
> LDAP _was_ a directory access protocol. It's not anymore the case. Do
> you know any X.500 server around there? We are all working on an world
> of LDAP servers, not on a world of people using LDAP protocol on top
> of X.500 servers. let's fact the fact : LDAP servers need to evolve
> now.

Not to get too academic here but this statement is not true.  Two
examples are CA eTrust which is an X.500 directory with an LDAP layer
and Windows Active Directory which is the Windows identity and network
management system that is exposed and accessible via LDAP.  AS/400's
identity system is built in the same mold as AD where the it's
accessible by LDAP.

For instance, lets take this group discussion.  Lets say for the sake
of argument an rfc is written.  There would be two pieces, an extended
operation that would allow the user to request if a user is a member
of a group and an rfc for what Alex has described.  Now ApacheDS can
implement both rfc's, but OpenDS might only implement the extended
operation to test if a user is in a 'role' while an AD implementation
would be checking its own internal group check system.

As for your assertion that LDAP servers need to evolve now, I don't
know that thats true.  LDAP has been utilized for how long now very
successfully?  Sure there has been some judical use of extended
operations where LDAP doesn't cover something and virtual directories
have emerged as a response to the difficulty of application
integration but for the most part it works rather well.  There is a
diverse set of players with their own features that distinguish them.

I would instead assert that it is identity in general that needs to
evolve to encompass not only authentication and data, but workflow and
provisioning and audit and integration and ... The directory is
important to that, but what do you think is the driving factor that
the directory has to evolve?

> How that
> > directory is implemented shouldn't matter.  As a matter of practice I
> > prefer simple to complex.  There are many good things about X.500
> > (which are the roots of virtual directories), but I don't think we
> > should confuse the access protocol and the implementation protocol.
> The LDAP RFCs aren't confusing the protocol itself and the
> implementation. if you read carefully all those RFCs (4511 to 4520),
> the sentence 'implementors should ...' is all over them.

Exactly.  Anyone who chooses to implement this access method.  The
very fact that virtual directories exist is a testament to the notion
that LDAP is not equivalent to Directory Server.  I've implemented
virtual directories (which are really only an LDAP protocol layer,
router and adapters) that expose other directories, databases, web
services, XML files, NT4 Domains and more through LDAP.  Penrose has
exposed NIS through LDAP.  So there is in fact a difference between
the access protocol and the directory.


View raw message