directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: TripleSec and jacc
Date Thu, 21 Dec 2006 16:37:30 GMT
Hey David,

I just wanted to say that I got you on my radar.  Just trying to catch
up after some down time.

BTW just a quick question.  Just recently I made some major pom changes
perhaps before your patch submission.  Just curious if you pulled down
these updates before producing the patch?

Thanks,
Alex

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