Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of greg@wind.enjellic.com
 designates 209.243.13.15 as permitted sender)
Message-Id: <200612010326.kB13Qj3X008742@wind.enjellic.com>
From: greg@enjellic.com
Date: Thu, 30 Nov 2006 21:26:45 -0600
In-Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>,
 akarasulu@apache.org
       "Re: Open architecture identity and authorization efforts." (Nov 29,
  9:32am)
Reply-To: greg@enjellic.com
To: "Apache Directory Developers List" <dev@directory.apache.org>,
        akarasulu@apache.org
Subject: Re: Open architecture identity and authorization efforts.
Cc: john.grosen@hurderos.org
Received-SPF: pass (wind.enjellic.com: localhost is always allowed.)

On Nov 29,  9:32am, "Apache Directory Developers List" wrote:
} Subject: Re: Open architecture identity and authorization efforts.

Good evening Alex, thanks for the note.  Hope your day has gone well.

Apologies for the delay in responding.  I've been riding herd on a
cranky fibre-channel problem this week.

> g.w@hurderos.org wrote:
> > Enrique Rodriguez and I have been discussing issues surrounding
> > identity in general and authorization in particular for some time.  We
> > both feel the need for the Open-Source community to have a technology
> > strategy to counter Active Directory and its increasingly pervasive
> > influence on enterprise IT architectures.

> First off I'm very glad you're approaching the entire community.
> Community is at the heart of any great and successful OS project.
> Most of us share a similar vision of handling various authZ
> concerns.

A common vision is certainly helpful.  It would be great if everyone
could even agree a problem exists and Open-Source is the arena to fix
it in.

> Regarding the AD influence on IT and a lack of a strong OS solution
> I personally agree.  The prevalence of AD in IT is IMO a double
> edged sword in several respects.  It has increased the understanding
> and utilization of the LDAP/Kerberos duo which is a good thing.
> However some protocol aspects have been bastardized in their
> implementation and this is not so good.

There has been a positive impact on the acceptance of LDAP/Kerberos.
Unfortunately a solution was essentially 'inflicted' on the industry.
By and large no one has seemed to understand or take notice of the
potential impact of a 'de-facto' solution in this arena.

But I've railed on this issue to a lot of luminaries in the OSS
community to little avail so I just don't waste my time anymore.

The consensus of opinion is that Samba4 will simply ride in and fix
the problem.  Unfortunately the model is different in the middleware
arena.  The strategy which was effective for Linux, BIND, Apache
webserver to work their way into the enterprise doesn't work in this
venue.

> I do think there is a lot of room for something better if some good 
> people are brave enough to build it.
> 
> However officially for the record I'm obligated to say the following:
> 
> <pmc-chair-hat-on>
> Although we would like to offer the best directory and related security 
> solution we can, our primary goal is not to compete with any particular 
> implementation or implementor of directory/security solutions.  Although 
> competition is fine and healthy we will not define our objectives on 
> that basis alone.
> </pmc-chair-hat-on>

Certainly understandable, your efforts are focused on building a
directory server and the goal should be to build the best LDAP server
possible.

The more fundamental problem is that the industry needs a complete and
integrated solution which requires multiple and disparate technologies
to be merged.  There is not a large body of individuals with the scope
and skillsets needed to tackle such a problem.

> > I've been involved for almost a decade now in research and development
> > on the issue of identity generation and its role in defining
> > authorization.  If I have learned nothing else over this time period
> > I've learned the field of identity is ill defined, conceptually
> > abstract, difficult to understand and in most organizations a
> > political minefield.... :-)

> I could not have said it better myself.  Let me add just a little to 
> these shortcomings.
> 
> The identity problem is a subset of a greater more general problem: the 
> integration problem.  It's the most wide reaching integration problem 
> modern IT organizations have been confronted with up until now and 
> they're completely messing it up.
> 
> Most solutions are difficult to comprehend, extremely convoluted, and 
> wind up introducing complex integration problems in themselves.

Also an excellent analysis.

After watching and working on the problem for a long time I believe
the problem comes down to the fact that no one has gotten the model
right.

An interesting experiment is to ask technology people what an
'electronic identity' is.  I've done that multpiple times and most
people can't answer the question.

So by and large the industry is confronted with developing
sophisticated and complex solutions for managing something which no
one can define.

> > Our work has primarily focused on a methodology for defining
> > identity.  This is in contrast to a large number of other initiatives
> > such as OpenID, Shibboleth, Liberty Alliance etc. which have focused
> > on the problem of asserting identity between organizations and/or
> > individuals.
> > 
> > In a paradigm similar to the UNIX philosophy of 'everything is a file'
> > our strategy focused on the concept of 'everything is an identity'.
> > Interestingly, this has proven to be a very powerful paradigm and has
> > resulted in a methodology which has demonstrated considerable
> > flexibility as different usage scenarios have been poised against it.
> > 
> > For want of a better term we refer to our model as IDfusion.
> > Conceptually it involves the heirarchical combination of identities
> > within the context of an organization.  Primitive identities (user,
> > services) are combined to form derived identities which represent a
> > users ability to access a service or role

> Very interesting!  Can you provide some example situation of how these 
> derived identities come in handy?

The derived identities serve as an identity/label for an object which
encapsulates information on whether and how to delivery, vend or
authorize a service.

A pragmatic example can be taken from how an LDAP directory is
populated in the IDfusion model.  Combining the identity of a user and
service results in a unique N-bit number within the context of an
organization's identity namespace.

This N-bit number is used as the terminal component of the DN for an
object which is placed in the directory.  In the simplest implemention
the presence or absence of the object in the directory indicates
whether or not the user is authorized to access the service.

The directory object, of course, also can have attributes associated
with it.  These attributes can be used to execute more complex
authorization decisions.

> > One fruitful area of work has been the application of identity
> > generation technology to the problem of authorization.  This has
> > proven to be particularly productive with respect to defining a
> > standardized scheme for implementing authorization.
> > 
> > I should emphasize that our focus is on 'implementing' authorization
> > rather than 'executing' authorization.  IDfusion is best thought of as
> > a methodology on which higher levels of abstraction, for example
> > TripleSec, can be layered upon.
> 
> Do you have more information available on IDfusion and how authorization 
> is implemented?

I believe you noted below having found some references to the model.

> > We currently have a working implementation of our authorization model
> > using payload injection into Kerberos tickets.  All of our work is GPL
> > and has, up to this point, been based on MIT Kerberos and OpenLDAP.
> > The identity engine and management client are Java based.  Multiple
> > licensing methods are certainly something we would have no issue
> > discussing.

> That's most excellent.

> > Our hope is to work with Enrique and others in the Apache community
> > who are interested in furthering a standardized approach to identity
> > generation and authorization.  

> This is one of the primary concerns for us and the Triplesec effort
> which we are currently moving over to the ASF from Safehaus.

I think there are some obvious and significant synergies between our
efforts.

As I noted previously, from an authorization perspective, IDfusion is
more about implementation rather than execution.  Stated another way
our focus has been on a method of securely containerizing and
transporting information which can be used to make authorization
decisions.

With respect to identity generation itself I believe the concepts and
architecture of IDfusion are unique.  One of my colleagues is a
theologian and trained in the philosophy of science.  He is convinced
that one of the problems I've had with all this is that it represents
a paradigm shift.

Whether or not that is true is probably irrelevant.  I do know that
one of the most intrigueing things about IDfusion is that it has
consistently solved problems which were never anticipated when the
underlying architecture was laid down.

The only consistent problem has been communicating the problem that
its trying to solve.... :-)


> > I'm trying to get a new release rolled up and out before the holidays.
> > The primary focus of this release will be a standardized ASN encoding
> > scheme for the authorization payload field of Kerberos tickets.

> We love ASN.1 :).

Very powerful technology actually.  It took a bit of groping through
source code to understand how to do things with OpenSSL but the effort
has certainly paid dividends.

> > With this work in place I would be very much interested in
> > demonstrating compatibility between Kerberos tickets generated by the
> > Apache server and our plug-ins for the MIT Kerberos server.

> Excellent.

The authorization strategy is actually quite simple.  It should be a
straight forward exercise to get the authorization identity injection
working in the Kerberos component of ADS.

I think it would be a significant accomplishment to be able to
demonstrate a standard and straight forward Kerberos mediated
authorization strategy between the two platforms.

> > I will keep the list advised on future releases.  In the meantime I
> > would be happy to entertain any discussions or questions which people
> > may have, either privately or on the list.
> > 
> > Congratulations on your 1.0 release and best wishes for the continued
> > success of your project from the northern plains.

> Thanks Greg.  I'm sure I will be asking several questions.

Hopefully the read wasn't tiresome.  Please feel free to forward any
specific questions.

> BTW after a brief scan of the materials you've listed, I think there's a 
> lot of room for collaboration, and possibly consolidating our efforts. 
> I don't know if this is of interest to you but I would like to give you 
> an open invitation.
> 
> You're welcome to join us here to implement IDfusion within ApacheDS as 
> part of our Triplesec effort which will be a subproject of Apache 
> Directory for now.

I'm certainly confident we can collaborate on the implementation
level.

My main handicap is not understanding your codebase.  A more
significant problem than that is that everyone on the list would seem
to be competent Java developers, I'm not much more than a Java hack.

> Unlike the MIT Kerberos + OpenLDAP solution which involves two
> separate moving parts, an ApacheDS solution would be integrated into
> a single process and embeddable.  These factors would allow the
> uptake of IDfusion into several application servers and products on
> the market in addition to a stand alone offering.

I'm actually of the architectural camp that thinks authentication
tokens/secrets should not be admixed with identity/authorization
information.

One of the central tenants of the security design of IDfusion was to
provide a strategy for authorization which was robust in the face of a
compromise of the directory.  One of the most encouraging aspects of
the IDfusion model was how naturally it blended with Kerberos to
provide a security guarantee for the authorization identity objects in
the directory.

I can certainly understand the arguements for using an LDAP directory
as a common information store but I believe the motivation came about
due to the lack of an integrated service management and provisioning
architecture.  The design of ISME in the Hurderos/IDfusion
architecture is an attempt to correct that.

Most fundamentally IDfusion works in either model.  Having a shared
goal and vision toward a common identity architecture is more
important than implementation details.

> I'm glad you contacted us.  There are some exciting possibilities here.
>
> Regards,
> Alex

Hopefully this opinion will be retained as everyone becomes more
familiar with the technology.... :-)

Thanks for the comments, best wishes for a pleasant weekend.

}-- End of excerpt from "Apache Directory Developers List"

As always,
Greg

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"We are confronted with insurmountable opportunities."
                                -- Walt Kelly