geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: More on principal wrapping. Was: Re: svn commit: r123495 ...
Date Wed, 29 Dec 2004 03:30:14 GMT
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.


> -----Original Message-----
> From: David Jencks []
> Sent: Tuesday, December 28, 2004 1:43 PM
> To:
> 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%
> > how useful this will be in practice, but we agreed on the features
> > want, and I'm not sure we should take them off the table just
> > 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
> 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
>   We can help with this in a number of ways.  We can make all the
> 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
> >> involve:
> >>
> >> 1. giving each login module a separate subject
> >> or
> >> 2. removing the unwrapped principals from the single shared subject
> >> 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
> >> and seems to me is working against the philosophy behind JAAS.
> >> 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
> >>> the RealmPrincipal is in the list of processed principals before
> >>> processing it, but realm principals are never added to the
> >>> 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>

View raw message