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:40:47 GMT
Sorry I meant 
Chad,

Thanks

The brain is wired incorrectly this morning - need another cup o joe!
> 
> From: Alex Karasulu <aok123@bellsouth.net>
> Date: 2003/12/04 Thu AM 10:39:16 EST
> To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
> Subject: Re: Re: [general] Vision ( Was Vince Tence and AAA )
> 
> 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