geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@savoirtech.com>
Subject Re: Security Role Mapping & Authentication
Date Wed, 03 Aug 2005 02:21:37 GMT
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 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 <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 JettyWebAppContext.java:257).
> 
> 	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

Mime
View raw message