directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject TripleSec and jacc
Date Thu, 21 Dec 2006 01:05:52 GMT
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

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

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.

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.

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

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

3. Replace all use of the triplesec Permissions class with java.security.Permissions.  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.

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

At that point it should be really easy to use triplesec as a jacc provider in at least geronimo.

How plausible is this?  Comments?

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.

thanks
david jencks




Mime
View raw message