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):
<!-- Engine -->
<gbean name="TomcatEngine"
class="org.apache.geronimo.tomcat.EngineGBean">
<attribute
name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute>
<attribute name="initParams">
name=geronimo-properties-realm
defaultHost=${PlanServerHostname}
</attribute>
<references name="hosts">
<pattern>
<gbean-name>geronimo.server:j2eeType=Host,*</gbean-name></pattern>
</references>
<reference name="realmGBean">
<name>TomcatJAASRealm</name>
</reference>
<reference name="TomcatValveChain">
<name>FirstValve</name>
</reference>
</gbean>
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 <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="http://geronimo.apache.org/xml/ns/web"
> xmlns:naming="http://geronimo.apache.org/xml/ns/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="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
> 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/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
>><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 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 <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
>>
|