I realized that there were problems after I checked this code in but, I had to go rush to help my wife deliver our baby.
The concept of a login realm is quite simple and elegant. The current state of its implementation should not be taken as an argument against it; this is easy enough to fix. I should say that I do like some of the points that you've made. Give us some time to properly fix what we have and let's use that as a discussion point. Regards, Alan > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 28, 2004 1:43 PM > To: [EMAIL PROTECTED] > Subject: More on principal wrapping. Was: Re: svn commit: r123495 ... > > > 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'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 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 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> >
