FYI as suggested by Christine I created a new Triplesec JIRA project and moved your two issues over there.
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 > > > >
begin:vcard fn:Alex Karasulu n:Karasulu;Alex org:Apache Software Foundation;Apache Directory adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA email;internet:[EMAIL PROTECTED] title:Member, V.P. tel;work:(904) 791-2766 tel;fax:(904) 808-4789 tel;home:(904) 808-4789 tel;cell:(904) 315-4901 note;quoted-printable:AIM: alexokarasulu=0D=0A= MSN: [EMAIL PROTECTED] Yahoo!: alexkarasulu=0D=0A= IRC: aok=0D=0A= PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A= x-mozilla-html:FALSE url:http://people.apache.org/~akarasulu version:2.1 end:vcard
