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
