Re: More on principal wrapping. Was: Re: svn commit: r123495 ...

[David Jencks]

On Dec 28, 2004, at 7:30 PM, Alan D. Cabrera wrote:
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.
I hope you will not let anything I've said distract you from spending 
time with your family!
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 like the idea, and hope you're right about it being easy to fix:-)  
There are certainly problems with my last suggestions also in terms of 
figuring out how to map principals to roles.
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.
Excellent.  As it turns out I have to visit my parents for the next few 
days and will be online only sporadically.

Many thanks,
david jencks

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>