Re: Including loginDomainName in realm principal might not be useful

27 Dec 2004 23:02:55 -0000 

On Dec 27, 2004, at 1:37 PM, Alan D. Cabrera wrote:



-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: Monday, December 27, 2004 1:49 AM
To: [EMAIL PROTECTED]
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

Reply via email to