geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject RE: Including loginDomainName in realm principal might not be useful
Date Mon, 27 Dec 2004 21:37:09 GMT


> -----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.


Regards,
Alan



Mime
View raw message