directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Cromwell <>
Subject Re: [general] Vision ( Was Vince Tence and AAA )
Date Thu, 04 Dec 2003 15:28:43 GMT
Hi. Have any of you look at LDAPd? This might be
something to look at before you get started from


--- Alex Karasulu <> wrote:
> > 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:
> security
>    - libraries, services, frameworks
>    - examples: X.509 libraries, SSO, IM Solutions,
> AAA Services, Kerberos
> ASN.1 
>    - 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 
=== message truncated ===

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

View raw message