Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 23536 invoked from network); 3 Aug 2005 07:43:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Aug 2005 07:43:39 -0000 Received: (qmail 61361 invoked by uid 500); 3 Aug 2005 07:43:32 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 61307 invoked by uid 500); 3 Aug 2005 07:43:32 -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 List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 61293 invoked by uid 99); 3 Aug 2005 07:43:32 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Aug 2005 00:43:31 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jgenender@savoirtech.com designates 209.181.65.237 as permitted sender) Received: from [209.181.65.237] (HELO sun.savoirtech.com) (209.181.65.237) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 Aug 2005 00:43:22 -0700 Received: from [206.197.197.5] ([206.197.197.5]) by sun.savoirtech.com (8.12.11/8.12.11) with ESMTP id j737hRdT006434 for ; Wed, 3 Aug 2005 01:43:27 -0600 Message-ID: <42F07597.201@savoirtech.com> Date: Wed, 03 Aug 2005 01:43:19 -0600 From: Jeff Genender User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Security Role Mapping & Authentication References: <42F02A31.1030903@savoirtech.com> <42F05F3E.2090407@savoirtech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on sun.savoirtech.com X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on sun.savoirtech.com X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-108.9 required=5.6 tests=ALL_TRUSTED,AWL,BAYES_00, MY_bw_Generic,USER_IN_WHITELIST autolearn=ham version=3.0.3 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N The one kludge solution here...to make your example geronimo-web.xml work... If in the j2ee-server-plan.xml, we change the EngineGBean to read as follows (concentrate on the initParams' name value): org.apache.geronimo.tomcat.TomcatEngine name=geronimo-properties-realm defaultHost=${PlanServerHostname}

geronimo.server:j2eeType=Host,*

TomcatJAASRealm FirstValve This would effectively work. Jeff Aaron Mulder wrote: > Jeff, > I don't understand what you're saying about a realm GBean, and I'm > a little sketchy on the appName. Can I explain what I'm looking for and > then you can tell me if you think this is reasonable and whether it's in > place now? > > - If you have a web app that uses a login (HTTP Basic, Form-based, etc.), > then the server needs to use some "security realm" to authenticate the > user name and password you provide. > > - I would like that to always be a Geronimo SecurityRealm, regardless of > whether you're using Tomcat or Jetty or what. > > - I would like that to always be the Geronimo security realm whose name > is listed in the elements of geronimo-web.xml (if > geronimo-web.xml was provided and if it has that element). > > - I don't want you to have to declare *any* GBeans that are Tomcat or > Jetty specific. You must have declared the GenericSecurityRealm GBean > with the proper name, of course. > > I assume Tomcat requires some sort of adapter to make a Geronimo > SecurityRealm look like a "Tomcat Security Realm". I'm speculating this > is the "RealmGBean" you mention, but I don't know. I would like to > automatically create that and set it on Tomcat during the deployment > process, so the user doesn't need to specifically declare it. So, for > example, this would be a totally sufficient geornimo-web.xml if you want > to refer to the default security realm configured in Geronimo (named > geronimo-properties-realm, of type GenericSecurityRealm, and configured in > j2ee-server-plan.xml): > > xmlns="http://geronimo.apache.org/xml/ns/web" > xmlns:naming="http://geronimo.apache.org/xml/ns/naming" > configId="MyConfigName" > parentId="ParentConfigName"> > geronimo-properties-realm > > > > > name="system" /> > > > > > > > So this says, "when any user logs in, resolve their username and > password against the properties file var/security/users.properties, and if > their username is 'system' then add them to the J2EE role 'AppUsers'". > > If we implement what I've described above, then I believe this > same deployment plan should work with the same results for both Tomcat and > Jetty (and it doesn't have any settings or GBeans in it specific to either > Tomcat or Jetty). > > Thanks, > Aaron > > On Wed, 3 Aug 2005, Jeff Genender wrote: > >>Ok..even though I still stand by what I said below (and want to get some >>feedback on this), I figured, it surely wouldn't hurt to allow the >> be an override for the appName of the Tomcat >>JAASRealm. If its not specified, it will default to the standard >>methodology of how Tomcat looks for a realm (by name of the path/context >>or Host or Engine depending upon where the Realm was declared). One >>caveat...if you want the Realm to use the context's >>, you must have a RealmGBean applied at the context >>level in the geronimo-web.xml. If you do not...you will get the >>following log: >> >>WARN: security-realm-name was specified but no RealmGBean was configured >>for this context. Ignoring security-realm-name. >> >>and it will thus default to the Tomcat standard realm naming conventions >>(i.e. the inherited Host or Engine name at which the Realm was supplied >>- Engine by default). >> >>So...its coded, unit tested, and checked in. >> >>Jeff >> >> >> >>Jeff Genender wrote: >> >>>Correct, Tomcat does not use the element from the >>>geronimo-web.xml. >>> >>>How it works is... >>> >>>The Tomcat realms take the name of the object it is associated with. >>>Tomcat objects inherit Realms from top down. If a Realm is associated >>>with an Engine, then the Host(s) and Context(s) inherit that realm. The >>>same goes for Hosts...if its associated with that host, then all >>>Contexts under that Host inherits the Realm. Here is the example... >>> >>>There is typically a geronimo realm GBean that is created...lets use the >>>example of the one in the tomcat-config.xml. Notice the realmName >>>attribute is "Geronimo". >>> >>>Then a TomcatRealm is attached either the Engine, Host, or Context >>>levels. In this instance we have the TomcatRealm attached to the server >>>(i.e. the Engine) Notice the Engine object in tomcat-config.xml has a >>>name parameter of "Geronimo". All Contexts under that Engine will >>>associate itself with the "Geronimo" realm name. So this is Server-wide. >>> >>>If I wish to change a Context to specifically use its own specific >>>realm, its name is the context root/path name. So say I have created an >>>application that has a context root of "testme", then I can attach a >>>Realm object to it, and this Realm object will expect to find a realm >>>called "testme". >>> >>>This is how standard tomcat realms work, and it is because normally, >>>J2EE/JAAS uses a login.config file, where we declare our realms with >>>login modules like this: >>> >>> { >>> ; >>> ; >>> }; >>>(See http://tinyurl.com/dz6bz for more info) >>> >>>In Geronimo, since we don't use a login.config, instead, we wire these >>>up via 2 GBeans...a realm and a loginmodule. The application name >>>really becomes the realm name in our world. So to keep in line with the >>>login.config configuration, we use the realmName of the >>>GenericSecurityRealm matched up with the application name (or path of >>>our Context). >>> >>>It would not be too difficult to use the as an >>>override at this point, but Tomcat has stated that setName() on the >>>Realms is deprecated and thus will disappear in the future. This does >>>not preclude us rewriting the Realms, but it would break compatibility >>>with the slew of Realm objects offered by Tomcat in the future. >>> >>>I would suggest we examine why we use and why not >>>follow the application name paradigm that appears to be a standard. >>> >>>Jeff >>> >>>Aaron Mulder wrote: >>> >>> >>>> So in web apps, the developer provides a list of roles in web.xml, >>>>and then we let you map any principals from any Geronimo security realms >>>>to the J2EE roles using the element in geronimo-web.xml >>>>(it's quite possible to allow principals from multiple realms). >>>> >>>> However, on top of that, there's a element >>>>in geronimo-web.xml, which appears to be used by Jetty and not >>>>Tomcat. This appears to be used to set the JettyJAASRealm on the >>>>JettyWebAppContext (see JettyWebAppContext.java:257). >>>> >>>> I'm assuming that when you log in to Jetty, it authenticates you >>>>against the security realm named in the element, >>>>and then authorizes you against the mappings performed in the >>>> element. So logically, it wouldn't help you to include >>>>principals from any other realm in the element, but we >>>>don't enforce that in the schemas. >>>> >>>> If that's true, then what realm does Tomcat authenticate against? >>>>And what realm do EJBs authenticate against? Both Tomcat and EJBs appear >>>>to only use the element (Tomcat ignores the >>>> element AFAICT and openejb-jar.xml doesn't have >>>>one). >>>> >>>>Thanks, >>>> Aaron >>