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 06:07:58 GMT
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 
> 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:
> <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.
> 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 <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
>> one).
>> Thanks,
>>     Aaron

View raw message