geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Including loginDomainName in realm principal might not be useful
Date Mon, 27 Dec 2004 23:02:27 GMT
On Dec 27, 2004, at 1:37 PM, Alan D. Cabrera wrote:

>
>
>> -----Original Message-----
>> From: David Jencks [mailto:djencks@gluecode.com]
>> Sent: Monday, December 27, 2004 2:57 PM
>>
>> On Dec 27, 2004, at 5:46 AM, Alan D. Cabrera wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Jencks [mailto:djencks@gluecode.com]
>>>> Sent: Monday, December 27, 2004 1:49 AM
>>>> To: dev@geronimo.apache.org
>>>> Subject: Including loginDomainName in realm principal might not be
>>> useful
>>>>
>>>> I've been trying to understand the creation of RealmPrincipals to
> wrap
>>>> principals added to a Subject by LoginModules and I wonder if
>>> including
>>>> the loginDomainName (i.e., a name for a LoginModule) actually is of
>>> any
>>>> use or if it serves to provide a false sense of security.  Here's
> the
>>>> problem I see:
>>>>
>>>> suppose we have a realm with two login domains D1 and D2 that each
> use
>>>> the same principal classes, but are attached to different backend
>>>> systems.  This seems to me to be the situation that including the
>>>> loginDomainName is intended to help with, by distinguishing whether
> a
>>>> principal was added by D1 or D2.  So, we imagine that D1 and D2
> both
>>>> have a group Foo, but with very different meaning and hence role
>>>> mappings.
>>>>
>>>> If only D1 adds a group principal named Foo, that's fine, we get a
>>>> RealmPrincipal labeled with D1 wrapping a Foo group principal.
>>>>
>>>> Similarly, if only D2 adds a group principal named Foo, that is
> also
>>>> fine, we get a RealmPrincipal labeled with D2 wrapping a Foo group
>>>> principal.
>>>>
>>>> However, if both D1 and D2 add a group principal named Foo, that is
>>> not
>>>> fine, since we will only get a single RealmPrincipal, labeled with
> D1,
>>>> wrapping a Foo group principal.  We should get two RealmPrincipals,
>>>> each wrapping a (separate, but that is unimportant) Foo group
>>>> principal, one labeled with D1 and the other labeled with D2.
>>>>
>>>> The reason this happens is that all the login modules are adding
>>>> principals to a set in a single Subject, so after D1 adds its Foo
>>> group
>>>> principal, D2's effort to add another copy of the same principal
> has
>>> no
>>>> effect.
>>>
>>> Here is the outcome from logging in under vanilla JAAS:
>>>
>>> Principal(Foo)
>>>
>>> Here is the outcome from logging in under Geronimo:
>>>
>>> Principal(Foo)
>>> RealmPrincipal(D1, Principal(Foo))
>>> RealmPrincipal(D2, Principal(Foo))
>>>
>>> You should get two realm principals.
>>
>> I agree this is what we would like the result to be.  Do you have a
>> test that verifies that this occurs? I didn't find one.  From looking
>> at the code, I think that we will get
>>
>> Principal(Foo)
>> RealmPrincipal(D1, Principal(Foo))
>>
>> If there's an existing test, please point it out to me.  If not, and
>> if, after looking at this method from JaasSecurityContext:
>>
>>      public void processPrincipals(String loginDomainName) {
>>          List list = new LinkedList();
>>          for (Iterator it = subject.getPrincipals().iterator();
>> it.hasNext();) {
>>              Principal p = (Principal) it.next();
>>              if(!(p instanceof RealmPrincipal) &&
>> !processedPrincipals.contains(p)) {
>>                  list.add(ContextManager.registerPrincipal(new
>> RealmPrincipal(realmName, loginDomainName, p)));
>>                  processedPrincipals.add(p);
>>              }
>>          }
>>          subject.getPrincipals().addAll(list);
>>      }
>>
>>   you think the results are as you suggest, I will write a test to
> find
>> out what happens.
>
> The code in RealmPrincipal ignores realmName so, you will get two
> RealmPrincipals.  I'm reworking the JAAS tests.  Then kinda devolved
> after the some of the reorg.
>

I wrote a test to verify that what I thought was happening is in fact 
happening.  Only two principals are in the subject after both login 
modules have committed.  See MultipleLoginDomainTest and uncomment the 
assertEquals line.

I think this test shows that, as it stands now, naming login modules 
provides no use in disambiguating principals.  Either the different 
login modules use different principal classes, in which case you don't 
need the login domain name to tell them apart, or they use the same 
principal classes, in which case you cannot tell which modules they 
came from on the basis of the RealmPrincipals, so, again, the login 
domain name didn't help.

As I mentioned earlier, the only solution I have thought of is to 
provide each named or specially marked login module with a separate 
principal and aggregate them ourselves in the JaasSecurityContext.  I 
don't know what other effects this might have.

thanks,
david jencks

>
> Regards,
> Alan
>
>


Mime
View raw message