On Dec 28, 2004, at 10:11 AM, Aaron Mulder wrote:
Well, I think an == would do the trick. We could also use some
kind of temporary Subject manipulations, but I don't think a major change
is necessary.
IMO == will not help because the 2nd login module, when adding a new principal that .equals an existing principal, makes no change in the set of principals in the Subject. This is why I suggest that any solution must involve presenting the 2nd login module with a Subject that does not include the principals added by the first login module, either by providing an unshared Subject to each login module or by removing non-wrapped principals as they are wrapped.
I agree that our extensions are a "nice to have" feature. However, I don't think we should write endless code to work around fundamental incompatibilities with JAAS unless there is a substantial benefit. I've also suggested a couple of ways that I think would solve the problem, but at the cost of significant complexity and possible non-compliance to JAAS.
I'll grant you we're kind of "enhancing" JAAS. I'm not 100% sure
how useful this will be in practice, but we agreed on the features we
want, and I'm not sure we should take them off the table just because JAAS
doesn't support them natively.
I suggest that trying to solve this problem in the geronimo security framework is the wrong place. As I've tried to point out before, the only circumstance where labelling principals with the login domain name helps to tell you where the principal came from is precisely the circumstance in which the labelling doesn't work: when two login modules are using the same principal classes and principal names, or more generally adding principals that are .equal to the single shared subject.
Lets consider an alternative: making users responsible for using configurations that add only distinguishable principals to the subject. We can help with this in a number of ways. We can make all the login modules supplied with geronimo use principals that include a login domain name set in the options. We can also supply a generic wrapping login module that, while accepting a shared subject, supplies a separate non-shared subject to its delegate, and wraps the principals from this subject with principals that include the login domain name. I think this will result in much simpler code and put the cost of complexity only on the rare users that need such sophistication.
If we were to adopt this change, I think we should revisit the concept of wrapping principals. If I understand correctly the only added information would be the realm name, which is currently not tracked in the RealmPrincipal. I think that tracking the realm name is useful, but if I'm wrong, I don't see any reason to wrap principals.
Many thanks, david jencks
Aaron
On Tue, 28 Dec 2004, David Jencks wrote:As Aaron points out this fix doesn't work, see the updated test.
IMNSHO fixing this problem will require major changes in the login module subject sharing that 1. may be inconsistent with the expected JAAS semantics 2. may be more trouble than it's worth.
With a single set of principals, you cannot detect multiple login modules adding the same principal to the set. The only solutions will involve:
1. giving each login module a separate subject or 2. removing the unwrapped principals from the single shared subject as we wrap them. or 3. stop trying to identify which login module added a principal.
To me it is starting to seem like we are saying, "JAAS isn't good enough for us, we need to extend it" but our extension isn't working and seems to me is working against the philosophy behind JAAS. What are we actually gaining from this login domain tracking?
thanks david jencks
On Dec 28, 2004, at 6:55 AM, Aaron Mulder wrote:
I'm not sure I agree with this fix. The comparison now checks if
the RealmPrincipal is in the list of processed principals before
processing it, but realm principals are never added to the processed
principal list (only original principals), so this will add everything
it
sees, yeah?
It might be better to maintain a list and manually check if the new principal == each one in the old list rather than relying on .equals, though I guess checking the realm principals should work too.
Aaron <snip>
