directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Open architecture identity and authorization efforts.
Date Thu, 07 Dec 2006 16:51:45 GMT
On Dec 6, 11:00am, "Apache Directory Developers List" wrote:
} Subject: Re: Open architecture identity and authorization efforts.

Good morning David, thanks for the note, I hope your day is starting
out well.

> I haven't had a chance to look at the more detailed documentation
> but based on this email and what I want to do with triplesec to
> integrate it with Geronimo I have a question....

Yes, I read with interest your note on October 14th where you
discussed methods for implementing EJB/Geronimo security permissions
on top of the TripleSec security model.

> Currently triplesec's idea of permission "implies" is equality of
> the "permission string".  This doesn't map well to java permissions
> where often some computation is involved.  For instance a JACC ejb
> method permission might be for all methods on an ejb, or one
> specific method.  A request will generate a permission "Specific"
> with one specific method, and a role might be granted a permission
> "General" for all methods on that ejb.  To see if we should allow
> the request we evaluate General.implies(Specific), which involves
> some computation involving the contents of the permissions.
> Something similar goes on for web permissions, where you might be
> granted access to /foo/* except for /foo/private/*.  A specific
> request will have it's url evaluated against these patterns, but the
> evaluation is more compiicated than equality.

I will readily admit to very little domain knowledge in the field of
the JACC/EJB permissions model.  It would seem from your discussion
that the security context attached to a specific request represents a
delineation of the methods in an object which can be executed by the

In web permissions the security context would seem to be a list of
regular expressions which represent allowed and denied URL paths.

For the purposes of further discussion I will assume that the
application loads the data needed to formulate the requestor's
security context for an application or web request from some datastore
such as a directory server.

> From the discussion below it looks to me a bit as if the permissions
> in IDfusion are stored in an opaque form and authorization decisions
> are based on comparison of this opaque form, which AFAICT would make
> the kind of permission evaluation described above impossible.  So...
> Can IDfusion deal with permission objects of this kind, where code +
> data must be executed to determine permissions?  If not is there
> some other way to deal with these infinite sets of specific
> permissions such as those from url pattern matching?

If my assumptions above are correct I don't see an issue with IDfusion
supporting the web or EJB security model, either directly or through
the TripleSec model.

I mentioned previously that IDfusion focues on 'implementing' rather
than 'executing' authorization.  The difference is subtle but

The primary objective of IDfusion is to securely 'containerize'
information which is passed upward to an application which implements
a higher order authorization decision based on that information.  The
only inherent limitation to a directory based implementation of
IDfusion is that the information to be fed to a higher level
authorizer be expressible as attributes of a directory object.

In the C API implementation the equivalent of a HashMap is returned to
the caller if the authorization succeeds at the IDfusion level.  The
keys correspond to directory attribute names while the values are the
data associated with the attribute.  The application is free to
execute whatever extended authorization decision it chooses based on
those returned values.

The lower level authorization decision has proven to be very useful in
practice.  As you noted above the actual data implementation of
sophisticated authorization models may be quite complex.  The ability
to generically turn on or off access without disturbing the actual
data model has proven to have a great deal of utility.

The IDfusion API is also responsible for implementing data inheritance
from the Sii identity to the SIii identity.  The returned values
represent the outcome of that inheritance.

Lets consider a WEB permissions example.  Assume that an Sii identity
object representing access to a corporate WEB server is expressed in
the directory in the following manner:

	allowed: .*
	svcname: WEB_ACCESS
	state: enabled

The allowed: attribute is a regular expression to be matched against
the URL.  Lets also assume the schema for the object allows the object
to have a denied: attribute.

The following SIii object for a user would authorize access to the
default permissions which is access to any URL:

	state: enabled

The IDfusion API would 'fuse' the Sii and SIii objects and return the
following key/value pair to the application for a successful

	allowed :-> .*

Now lets consider an example where a restrictive set of permissions
are to be applied to a user's access rights.  The SIii object
representing the permissions could be constructed as follows:

	denied: /financials/.*
	state: enabled

The IDfusion authorization call would return the following:

	allowed :-> .*
	denied  :-> /financials/.*

The assumption in both cases is that the higher level application
would be able to execute an appropriate access decision based on those
regular expressions.

So IDfusion is quite agnostic to the actual data used to 'execute' an
authorization decision.  I was thinking about your e-mail when my
Golden Retriever Iggy and I were walking through the frozen stubble
fields last night.  There would certainly be nothing which would
preclude the result of an IDfusion authorization decision from being a
serialized Java object.

Just a final comment with respect to the EJB/Geronimo methods security
model.  I don't know how polymorphism is handled but I assume there is
a standardized method of describing allowed/denied methods to handle
this issue.

In an IDfusion implementation the allowed: and denied: attributes
could be multi-valued and contain the name/fingerprint of
allowed/denied methods.  If the user has been granted access to a
service the results of the IDfusion API call would represent the set
of methods which the user may execute to access the service.

I've now rambled on too long but just a final comment on permissions.

Experience with the services architecture which IDfusion is based on
has demonstrated there may be a significant opportunity to reformulate
how we think about permissions.  IDfusion/Hurderos make it very, very
easy to implement and manage access to services on a user by user

With respect to web url/path access it may actually be easier to
express access to various path elements of a URL as separate services.
In this model the application is simply taught to authorize access to
a URL component by verifying the user has been granted access to the
service associated with the path component.

> thanks
> david jencks

Hopefully all of the above information is helpful, I would be happy to
drill deeper or answer any other questions which people may have.

Best wishes for a pleasant weekend.

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

As always,

			 The Hurderos Project
         Open Identity, Service and Authorization Management

"Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
Geniuses remove it.
                                -- Perliss' Programming Proverb #58
                                   SIGPLAN National, Sept. 1982

View raw message