geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: More on principal wrapping. Was: Re: svn commit: r123495 ...
Date Wed, 29 Dec 2004 06:40:51 GMT

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 []
>> 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%
> 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>

View raw message