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 Tue, 28 Dec 2004 11:33:59 GMT
Fixed

> -----Original Message-----
> From: David Jencks [mailto:djencks@gluecode.com]
> Sent: Monday, December 27, 2004 6:02 PM
> 
> 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