directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [general] Vision ( Was Vince Tence and AAA )
Date Thu, 04 Dec 2003 15:19:18 GMT
> I am open to and interested in helping with identity/auth services 
> leveraging directory services.  Whether this "belongs" in the Directory 
> project is debatable, but I at least would be +1 to including it.
> I need to understand better, however, exactly what the vision is.  

I presume by vision you are referring to the directory project and
what it will become once it is a top level project.  Everyone I suspect
will have a slightly different vision but if we can fall within a 
ballpark this is good.  To do so you're right we should discuss what
we each think should be the vision of this project.  Most importantly
we need some scope to constrain it since well this can go everywhere.

Here mine POV:

Obviously the directory project includes everything under the sun that
has to do with directories and JNDI based naming.  As JDBC is to the db
top level so will JNDI to the directory top level.  Directory servers like
LDAP and X.500 will be covered under the directory umbrella. 

There will be central efforts that eventually should be spun off as their
own projects or as subprojects of other top levels.  For example we will
need to implment ASN.1 providers for BER, DER and XER encoder, decoders
eventually.  Perhaps we may even build an ASN.1 stub compiler who knows.
This stuff like the security stuff should be centralized so other projects
can use it.  For example SNMP is based on ASN.1 so if there is such an
effort here at Apache I would recommend moving this code to a central 
location so it can be used by both the directory and snmp efforts.  So
since we will be building these things they will probably bud out from us
first.  This is a good example of a subproject to say jakarta or something
central - maybe it's its own tlp.  I don't really know but the goal would
be to make it available to other efforts that use ASN.1.  Where and what is
done with it is upto the ASF.  BTW Jeff as expressed interest in putting
some of the BER encoding and decoding algorithms together as a C library
which can then be used to have an encode and decode facility in the APR.
Perhaps this stuff will eventually go there and no buddy know until it 
happens if it does.

Now take Kerberos (RFC1510): it's based on ASN.1 and can use any
of the encodings.   It has has a close relationship to X.5XX and is best
implemented with a directory as its backing store.  If there were to be
a Kerberos effort at Apache it should IMO be a TLP.  Disclaimer: just 
guessing here not trying to establish policy for the ASF.  However I think
building a directory backed Kerberos implementation after Eve is stable is
best launched out of the directory project.  I could probably implement
one very rapidly once the directory has stabilized.  Anyway it is very 
tightly coupled with our efforts yet not central and it should eventually
bud off into its own project.  BTW some of the AAA providers for services
can be based on Kerberos too but thats OT.

Now I see us doing a lot of things with certificates and generally X.509 
based stuff here since it is a X.500 track standards document.  I think
eventually we're going to have to implement several security packages to
deal with X.509 and to support Eve's internal authentication mechanisms.
Again we're probably going to need to bud this stuff off because it can
be reused by so many other efforts at the ASF.  Alone this is not enough
for a TLP but coupled with AAA and perhaps an identity management solution
based on Eve there is the potential to have a security TLP to deal with
these matters.  I think a good chunk of the code for this will be pulled out
out of the directory effort since we're going to have to implement it.
On just the directory side outside of JNDI providers for java:enc we're 
very tightly intertwined with ASN.1 (X.681 now I think), security namely
X.509 and have complementary relationships with other servers like Kerberos
and can be the basis for frameworks like an identity management system that
includes Authentication, Authorization and SSO.

To summarize the directory TLP will be a one stop shop for your JNDI and non-
Java based directory access API needs, as well as being home to various 
directory servers: LDAP, X.500, Meta directories, Virtual directories et 
cetera.  It will be home to various JNDI providers used throughout the foundation.  From the
directory effort will spin off several software 
libraries, components, frameworks and even servers that will eventually
bud off to be relocated under other TLPs or as their own top level projects.
Perhaps there are incubation stages in between here if that's what wants
to be done.  The areas that may be prone to such a dynamic are:

   - libraries, services, frameworks
   - examples: X.509 libraries, SSO, IM Solutions, AAA Services, Kerberos

   - snickers (a snacc BER runtime replacement which already exists)
   - encoder/decoders: BER, DER, XER in various languages
   - ASN.1 stub compilers
   - XML Schema to ASN.1 to C/C++/Java.. stub compilers

So there's alot of subject matter here.  I think our goals are to
start something off to accomodate our needs but not to take it all
the way.  That I think is the job of a more specialized group which
can offer their solutions to the entire community.

> I 
> would like to discuss that a bit before we decide on incorporating the 
> SF AAA project code base.  In particular, I would like to understand 
> better what the goals are around standards support and applications 
> beyond Avalon containers.

Everything should be standards based without exception.  We're not
here to be a standards body.  The IETF, ITU and OASIS can do that for
us along with the JCP.  I'm absolutely dedicated and governed by 
standards and totally against lame brained home grown ideas unless they
are developed collaboratively under a healthy community.  We're not 
there yet so let's stick to standards.

Now the container issues.  That's a balancing act.  We need to accomodate
various people here at the ASF and in the container community at large to
avoid excluding them and their users from having Eve as an option.  We are
primarily focused on Avalon since it is an ASF effort.  However without 
getting into detail we will need to support various containers.  This 
includes Merlin, Pico, Plexus, Loom to name a few.  We need a layer of 
adapters to establish this support for each container.  It's that simple.

Phil and friends I hope you have my idea of where the directory effort 
should go.  Please add to this or ask more questions.  Also note that 
we have a basic idea and to some degree we need a sense and response 
approach to finding our direction.  So a degree of flexibility is 


View raw message