You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/08/03 03:01:10 UTC
Security Role Mapping & Authentication
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
Re: Security Role Mapping & Authentication
Posted by Jeff Genender <jg...@savoirtech.com>.
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.
Sorry about that...I was speaking Tomcat speak...and it can get very
hairy at times. I was describing the Tomcat JAAS implementation and how
it works...its very confusing.
> 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?
Its basically in place now...but there is one small issue...see below.
>
> - 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.
This will be a small problem. The adapter is the RealmGBean. If I
declare the RealmGBean and attach it to the Engine (i.e. already
configured in the j2ee-server-plan.xml), then the Engine Gbean's "name"
initParam *must* match the Geronimo Realm you created - this is a Tomcat
requirement. Thus all contexts (and hosts) underneath the engine will
use that realm by that name. In otherwords...the RealmGBean adapter is
inherited by all Hosts and Contexts that are children to the Engine (the
Tomcat Server).
Now, if I declare a RealmGBean in the geronimo-web.xml, it will
automagically be attached to that web context...and will override the
Engine version for that particular context. I am allowing the
<security-realm-name> to be used.
So...the following would be added to your geronimo-web.xml example below:
<container-config container="Tomcat">
<config-param name="TomcatRealm">TomcatJAASRealm</config-param>
</container-config>
<gbean name="TomcatJAASRealm"
class="org.apache.geronimo.tomcat.RealmGBean">
<attribute
name="className">org.apache.geronimo.tomcat.realm.TomcatJAASRealm</attribute>
<attribute name="initParams">
userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal
roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
</attribute>
</gbean>
The real addition here is the container-config and the Gbean.
If this is a problem and we truly want this to be seemless for Jetty and
Tomcat, then I really recommend we go back to the Sun paradigm of the
login.config file and name the realms like the web application context
roots or default names.
>
> 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
>>
Re: Security Role Mapping & Authentication
Posted by Jeff Genender <jg...@savoirtech.com>.
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
>>
Re: Security Role Mapping & Authentication
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
>
Re: Security Role Mapping & Authentication
Posted by Jeff Genender <jg...@savoirtech.com>.
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
Re: Security Role Mapping & Authentication
Posted by Jeff Genender <jg...@savoirtech.com>.
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