Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 49323 invoked from network); 24 Nov 2004 20:00:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 24 Nov 2004 20:00:02 -0000 Received: (qmail 79704 invoked by uid 500); 24 Nov 2004 19:59:31 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 79636 invoked by uid 500); 24 Nov 2004 19:59:30 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 79583 invoked by uid 99); 24 Nov 2004 19:59:29 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from saturn.opentools.org (HELO saturn.opentools.org) (66.250.40.202) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 24 Nov 2004 11:59:27 -0800 Received: by saturn.opentools.org (Postfix, from userid 500) id A62C33EDA; Wed, 24 Nov 2004 15:08:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by saturn.opentools.org (Postfix) with ESMTP id 9DA1EF60C for ; Wed, 24 Nov 2004 15:08:37 -0500 (EST) Date: Wed, 24 Nov 2004 15:08:37 -0500 (EST) From: Aaron Mulder X-X-Sender: ammulder@saturn.opentools.org To: dev@geronimo.apache.org Subject: Re: LoginDomains and automapping In-Reply-To: <41A37B15.9010106@savoirtech.com> Message-ID: References: <41A2C9FC.1000907@savoirtech.com> <41A37B15.9010106@savoirtech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Jeff, According to a conversating I just had with Alan, the other container modules use a method of authorization with JACC that doesn't require the containers to access all the principals. Basically, they just give JACC the Subject containing an IdentificationPrincipal (which you have), and our JACC implementation looks up the proper Subject and does the calculations all on its side. Alan thought that maybe Tomcat does authorization differently (using Subject.doAs), in which case Tomcat would specifically need all the RealmPrincipals to be present. However, as that appears to be fairly slow, it's not ideal anyway. So in the short term, you should probably try to insert a call to ContextManager.getServerSideSubject which will get you all the RealmPrincipals too. If you really have trouble inserting the call in there, worst case, you could create a wrapper LoginModule that calls our JaasLoginCoordinator LoginModule and then calls ContextManager.getServerSideSubject and writes all the RealmPrincipals into the Subject that will be returned to the caller. In the long term, we'd like to adjust the interface between Tomcat and Geronimo to use a different authorization method, which will mean the RealmPrincipals are no longer necessary. Aaron On Tue, 23 Nov 2004, Jeff Genender wrote: > Ok, then this is my mistake. I assumed you were filling in the Subject > with the principals, but as I re-read, I saw what you were saying, > regarding the necessity to continue to call > ContextManager.getServerSideSubject. > > I have some code that Alan and I worked on in the JaasLoginCoordinator > that populates the subject with the principals that I *think* does the > "automagically" you referred to in the previous email. I had the > JaasLoginService.serverLoginModuleCommit() return a Collection of > Principals, and then I set these principals in the Subject in the > JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the > ClientLoginModule. So I believe that in the same JVM, this may do as > what you stated below. I have included the patch which we have come up > with thus far. This is only for you guys to look at as I have not run > the unit tests for this yet. > > If I am off base here, please set me straight. I am new to this code > and am just getting my feet wet in seeing what its doing, so I may end > up in a few dead ends. > > Let me know if you would like me to continue down this path, and I can > write the unit tests for it and submit the changes. > > Jeff > > Here is the patch: > > Index: src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java > =================================================================== > --- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java > (revision 106054) > +++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java > (working copy) > @@ -210,7 +210,13 @@ > } > > public boolean commit() throws LoginException { > - return service.serverLoginModuleCommit(client, index); > + Collection c = service.serverLoginModuleCommit(client, index); > + if (c == null) > + return false; > + > + subject.getPrincipals().addAll(c); > + > + return true; > } > > public boolean abort() throws LoginException { > Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java > =================================================================== > --- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java > (revision 106054) > +++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java > (working copy) > @@ -260,7 +260,7 @@ > * once for each server-side login module that was processed > before the > * overall authentication succeeded. > */ > - public boolean serverLoginModuleCommit(JaasClientId userIdentifier, > int loginModuleIndex) throws LoginException { > + public Collection serverLoginModuleCommit(JaasClientId > userIdentifier, int loginModuleIndex) throws LoginException { > JaasSecurityContext context = (JaasSecurityContext) > activeLogins.get(userIdentifier); > if(context == null) { > throw new ExpiredLoginModuleException(); > @@ -270,8 +270,16 @@ > } > JaasLoginModuleConfiguration module = > context.getModules()[loginModuleIndex]; > boolean result = module.getLoginModule(classLoader).commit(); > + > + if (!result) > + return null; > + > context.processPrincipals(); > - return result; > + Subject s = context.getSubject(); > + if (s == null) > + return null; > + > + return s.getPrincipals(); > } > > /** > Index: src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java > =================================================================== > --- > src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java > (revision 106054) > +++ > src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java > (working copy) > @@ -110,7 +110,7 @@ > * once for each server-side login module that was processed > before the > * overall authentication succeeded. > */ > - public boolean serverLoginModuleCommit(JaasClientId userIdentifier, > int loginModuleIndex) throws LoginException; > + public Collection serverLoginModuleCommit(JaasClientId > userIdentifier, int loginModuleIndex) throws LoginException; > > /** > * Indicates that the overall login succeeded. All login modules > that were > > Aaron Mulder wrote: > > On Mon, 22 Nov 2004, Jeff Genender wrote: > > > >>This is good...this should get the raw Tomcat JAASRealm to work for > >>authorization. I just coded up a special JAASTomcatRealm that called > >>the ContextManager.getServerSideSubject and now I can ditch it since it > >>looks like the JaasLoginCoordinator is populating the subject. > > > > > > I'm not sure you're right -- the JAASTomcatRealm should be using > > RealmPrincipals, which are not currently returned. I need to talk this > > over with Alan: > > > > Alan D. Cabrera wrote: > > > >>I think that we should return the realm principals as well for all the > >>same reasons that we have realm principals in the first place. > > > > > > Last time we talked you wanted to return everything except the > > RealmPrincipals... why the change of heart? > > > > What if we change the JaasLoginCoordinator to load the > > RealmPrincipals if it is used within the same JVM as the server, but not > > if it connects over the network? That may be the best balance of "give > > other server components what they neeed" and "don't expose Geronimo > > security internals to clients". > > > > Aaron >