From directory-dev-return-283-apmail-incubator-directory-dev-archive=incubator.apache.org@incubator.apache.org Thu Dec 04 15:19:27 2003 Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 86001 invoked from network); 4 Dec 2003 15:19:26 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 4 Dec 2003 15:19:26 -0000 Received: (qmail 27001 invoked by uid 500); 4 Dec 2003 15:19:21 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 26947 invoked by uid 500); 4 Dec 2003 15:19:21 -0000 Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Apache Directory Developers List" Reply-To: "Apache Directory Developers List" Delivered-To: mailing list directory-dev@incubator.apache.org Received: (qmail 26922 invoked from network); 4 Dec 2003 15:19:21 -0000 Received: from unknown (HELO imf23aec.mail.bellsouth.net) (205.152.59.71) by daedalus.apache.org with SMTP; 4 Dec 2003 15:19:21 -0000 Received: from mail.bellsouth.net ([205.152.59.157]) by imf23aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031204151918.NNUZ1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net> for ; Thu, 4 Dec 2003 10:19:18 -0500 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [65.81.198.151] From: Alex Karasulu Organization: Solarsis Group To: "Apache Directory Developers List" Subject: [general] Vision ( Was Vince Tence and AAA ) Date: Thu, 4 Dec 2003 10:19:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031204151918.NNUZ1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > 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 and response approach to finding our direction. So a degree of flexibility is required. Alex