Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <FF7CE36846E01B439945B55FFB1DF5BE07B8C9@mail.toolazydogs.com>
References: <FF7CE36846E01B439945B55FFB1DF5BE07B8C9@mail.toolazydogs.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <68D00968-5841-11D9-8400-000D93361CAA@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: Including loginDomainName in realm principal might not be useful
Date: Mon, 27 Dec 2004 11:56:33 -0800
To: dev@geronimo.apache.org


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.

many thanks,
david jencks

>
>
> Regards,
> Alan
>
>
>