directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Re: [general] Vision ( Was Vince Tence and AAA )
Date Thu, 04 Dec 2003 15:39:16 GMT
Thanks,

Chad I appreciate your input and don't stop.  But this project's 
Eve server is LDAPd.  The entire LDAPd Group and some Apache peeps 
got together to form this project.  The LDAPd Group was disolved 
after the LDAPd server code was given to the ASF.

I know it's not that apparent - sorry for the confusion.

Eve, the server formerly known as LDAPd btw is going to be the
next step and beyond ...

Alex

> 
> From: Chad Cromwell <cacjmd_98@yahoo.com>
> Date: 2003/12/04 Thu AM 10:28:43 EST
> To: Apache Directory Developers List <directory-dev@incubator.apache.org>
> Subject: Re: [general] Vision ( Was Vince Tence and AAA )
> 
> Hi. Have any of you look at LDAPd? This might be
> something to look at before you get started from
> scratch.
> 
> http://ldapd.sourceforge.net
> 
> Chad
> 
> 
> --- Alex Karasulu <aok123@bellsouth.net> 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
> http://antispam.yahoo.com/whatsnewfree
> 


Mime
View raw message