Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Content-Class: urn:content-classes:message
Message-ID: <3FCF65ED.4040505@steitz.com>
Date: Thu, 04 Dec 2003 09:50:53 -0700
From: "Phil Steitz" <phil@steitz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
MIME-Version: 1.0
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Subject: Re: [general] Vision ( Was Vince Tence and AAA )
References: 
 <20031204151918.NNUZ1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net>
Content-Type: text/plain;
	format=flowed;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.
> 

Actually,  I was just referring to the vision for AAA, but thanks for 
providing the full perspective.  This is the kind of discussion that needs 
to happen early on. In general, I like the direction and thinking.  There 
are (as you point out) obviously lots of decisions that will need to be 
made once the "buds" start emerging.  I agree with the basic idea of 
focusing first on Eve and what Eve needs internally as well as basic JNDI 
services, but trying to stay religiously standards-based as we build out 
from the core.  Some more comments below.  I am looking forward to others' 
perspectives.

> 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. 

For the Java platform.  I would say ldap is the "top level" logically 
speaking for the directory.

> 
> 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.

I like these ideas.  There may be some synergies with Jakarta Commons 
Codec for the Java stuff.  Here again, I agree with the program of 
starting with what Eve needs internally.

> 
> 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.

This is a tough one.  The "backing store" is really sort of the tail of 
the dog here, and there are alternatives to Kerberos.  I would not 
necessarily want to see us tightly couple all of the AAA stuff to Kerberos 
(could be talked out of this).  We will need to think carefully about 
this.  I agree, however, that there could be significant value in some 
kind of ASF-provided Kerberos implementation.

> 
> 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.

I agree. The tricky bit will be how to implement what we need internally 
so that it can be reused/extracted.

> 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.

What we need to think carefully about is the nature of these 
"complementary relationships" and what we should take on within the 
Directory project.

> 
> 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.

Amen to that.

> 
> 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.

Yes.  That's why I wanted to at least look at XACML. Another reference for 
that, btw is the Sun OSS implementation: http://sunxacml.sourceforge.net/ 
  Also, I assume that we are also including J2EE (I see our friend 
catalina in the AAA code :-)

> 
> 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 
> required.

Thanks for getting this discussion going :-)

Phil

> 
> Alex
>