directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: TripleSec and jacc
Date Thu, 21 Dec 2006 18:59:50 GMT
Hi David,

My comments are in line ...

David Jencks wrote:
> Now that triplesec is imported I started looking at the code with an eye to making it
more jacc-friendly.  I started with updating a bit of the build, mostly creating a dependencyManagement
section and a pluginManagement section in the root pom to track all the external dependency
and plugin versions.  I also updated to current apacheDS and updated a few other dependencies.
 See DIR-198

Unfortunately the day before you filed this JIRA I had done similar
things to make triplesec at least compile.  I created the
dependencyManagement section as well.  So when I went to apply your
patch I got massive rejections.

Is it possible to resubmit the patch after updating your working
directory.  I apologize for this inconvenience.

> It would be great if a committer with IDEA could spend a few minutes and666 change the
package names to live at apache :-)  although warning me first would be even better.

I could do this soon.  Perhaps we should first get your patch applied
then I can fix the package names immediately.

> At this point I have a question and a plan :-)


> I don't understand how application id is supposed to relate to a Subject or a profile
or a user.  Currently it looks to me as if when a user logs in they are restricted to working
in one application.  IMO this is sort of ridiculous :-), so probably I'm missing something
important here: explanations welcome.

Let me give some background on Triplesec's AuthZ policy store and it's

The ideas in tsec were really simple.  You have the following entities:


An application can be anything and need not be a web application.  It's
any situation where you have to *apply* a set of permissions to control
access to resources or operations within some domain.

All permissions are specific to a particular application (a.k.a.
domain).  Permissions are merely labels inside triplesec without

Permissions (their names) are added to Roles as grant attributes.  By
doing this any user's profile associated with a role inherits the grants
associated with the role.  This is how Tsec does RBAC.  Roles also are
application specific since they hold application specific permissions
and only make sense in that application.

Users are users as we think of them generally.  They are not defined
specific to any application.  However in order for a user to be allowed
to access an application that user must have a AuthZ profile defined
within the application.   This brings us to profiles.

Profiles represent AuthZ profiles for users.  A profile is associated
with a user with a special *'user'* attribute.  Profiles contain a set
of roles which allow profiles to inherit permission grants from those
roles.  In addition to this fine tweaking is allowed using a permission
set for denying certain permissions and one for adding additional grants
not included via role assignments.

So to get to your question: a user can access any number of applications
however that user has a different profile for each application they access.

> I'm biased from working with jacc, but I would tend to rename applicationId to policyContextId
since the scope of whatever is associated with such an id may not always be an application.
 In particular jacc deals in policyContextIds, one per j2ee application module.

We could rename application to context to be explicit about the fact
that permission and role definitions are specific to some domain and not
to a web or swing application for example.

Ersin also had ideas about this at some point.  Perhaps he can elaborate
on that here.

> On to the plan....
> 1. Depending on the explanations for the above question, either keep a Profile per applicationId
and have SafeHausPrincipal include a map of applicationId >> Profile or have the Profile
contain the map of applicationid >> ApplicationProfile (or PolicyContextProfile).

Sounds to me like since the user logs into the J2EE app server and *NOT*
into a particular application you need access to all profiles (for all
apps the user participates in).   Is this correct?

If so then we can make it so you can access all the user's profiles
through some API ... essentially exposing this appId to profile map per
user that you speak of above.

> 2. The current Permission class is not a  I propose to rename
it StringPermission (since it works on string equality), extend,
and introduce a StringPermissionCollection.  BTW I don't understand why triplesec Permission
includes the applicationName.  

First off a tsec permission includes the app name because permissions
are specific to an appication.  Perm xyz only makes sense wrt the app
that it was defined for.  Does this make sense?

Regarding calling it a StringPermission we can do this yeah.

> 3. Replace all use of the triplesec Permissions class with
 This  uses the StringPermissionCollection class for quick implies calculations and allows
use of all other permission classes such as those used in jacc.  This is going to replace
a bunch of proprietary triplesec methods with "implies"
> This much should be pretty straightforward and keep functionality pretty much the same.

Cool I think I'm down with this approach that bridges J2SE security with
tsec permissions.

> 4. try to understand how the current StringPermissions are being stored in ldap and figure
out how to store the permissions needed for JACC. IIRC Alex mentioned StateFactory as an elegant

Yeah we can figure something out.  We don't necessarily need to just
implement a StateFactory but it is a solution that might work well with
the JNDI access model.  However keep in mind this is just merely a DAO
design matter and not that big of a deal of us I think.

> At that point it should be really easy to use triplesec as a jacc provider in at least
> How plausible is this?  Comments?

Very.  I don't think it will be hard to do.  Perhaps we can define a
special permission object class that serializes Java permission objects.
 In the end though it's perhaps best to not serialize but devise some
text based representation of the different kinds of JACC permissions.
This way the entries stored in the directory are human readable when
accessed and managed via LDAP.  We may define new sub objectClasses
(LDAP) for these new kinds of permissions which include special
attributes for them like the URL pattern for a JACC web permission
(sorry forget the exact name for this permission).

> I opened DIR-199 and am attaching the start I made on (2) so others can look at what
I'm up to. This is not finished yet by any means.

I'm here to work with you and help out.  First off I recommend we fix
this small issue with your latest patch due to my commits the day before.

Then we can rename the packages and sort out other minor issues.

BTW we need to cleanup the schema and switch to using Apache enterprise
numbers for the OIDs in the LDAP schema but you need not worry about this.

Looking forward to working with you on this David.


View raw message