geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject More on principal wrapping. Was: Re: svn commit: r123495 ...
Date Tue, 28 Dec 2004 18:43:15 GMT

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 
> 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 

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>

View raw message