[general] Vision ( Was Vince Tence and AAA )

[Alex Karasulu <ao...@bellsouth.net>]

> 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

RE: [general] Vision ( Was Vince Tence and AAA )

[Alex Karasulu <ao...@bellsouth.net>]

<snip/>
> Actually,  I was just referring to the vision for AAA, but thanks for

Oooops my bad!

<snip/>

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

I never really looked at the commons Codec stuff but I should.  Perhaps
Rob Penoyer knew about it when he worked on snickers and can comment.

> 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

Oh I agree everything needs to be pluggable! 100%.

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

It's a nice add on to an LDAP server setup used for NOS directories like 
the way AD does it today.  I have to hand it to Microsoft for building 
Kerberos 5 into Active Directory.

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

We can design for this in mind and we'll definitely fall short.  Not 
will be designed with reusability in mind.  But that's what refactoring is
all about.  We can re-factor continuously and should looking for more
ways to reuse our code.  The key is to write as little code as possible 
because the more you have the more you must support.  Code replication
is the enemy.

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

+1 - think carefully to minimize scope creep.  Lots of things are cool
but we need to remember why this project was begun.

<snip/>

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

Sounds like your getting religious on me Phil :-).

<snip/>

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

I definitely need to make time to take a look at that.

Alex

Re: [general] Vision ( Was Vince Tence and AAA )

[Phil Steitz <ph...@steitz.com>]

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
> 

Re: [general] Vision ( Was Vince Tence and AAA )

[Chad Cromwell <ca...@yahoo.com>]

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