geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Security Role Mapping & Authentication
Date Wed, 03 Aug 2005 07:43:19 GMT
The one kludge solution 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):

<!-- Engine -->
<gbean name="TomcatEngine"
     <attribute name="initParams">
     <references name="hosts">
     <reference name="realmGBean">
     <reference name="TomcatValveChain">

This would effectively work.


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 <security-realm-name> 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):
> <web-app
>     xmlns=""
>     xmlns:naming=""
>     configId="MyConfigName"
>     parentId="ParentConfigName">
>   <security-realm-name>geronimo-properties-realm</security-realm-name>
>   <security>
>     <role-mappings>
>       <role name="AppUsers">
>         <realm name="geronimo-properties-realm">
>           <principal class=""
>            name="system" />
>         </realm>
>       </role>
>     </role-mappings>
>   </security>
> </web-app>
> 	So this says, "when any user logs in, resolve their username and
> password against the properties file var/security/, 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 
>><security-realm-name> 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 
>><security-realm-name>, you must have a RealmGBean applied at the context 
>>level in the geronimo-web.xml.  If you do 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 Genender wrote:
>>>Correct, Tomcat does not use the <security-realm-name> element from the

>>>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:
>>><name used by application to refer to this entry> {
>>>    <LoginModule> <flag> <LoginModule options>;
>>>    <optional additional LoginModules, flags and options>;
>>>    };
>>>(See 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 <security-realm-name> 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 <security-realm-name> and why not

>>>follow the application name paradigm that appears to be a standard.
>>>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 <security> element in geronimo-web.xml 
>>>>(it's quite possible to allow principals from multiple realms).
>>>>    However, on top of that, there's a <security-realm-name> 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
>>>>    I'm assuming that when you log in to Jetty, it authenticates you 
>>>>against the security realm named in the <security-realm-name> element,

>>>>and then authorizes you against the mappings performed in the 
>>>><security> element.  So logically, it wouldn't help you to include 
>>>>principals from any other realm in the <security> 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 <security> element (Tomcat ignores the
>>>><security-realm-name> element AFAICT and openejb-jar.xml doesn't have
>>>>    Aaron

View raw message