geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Jetty Security Realms
Date Mon, 01 Nov 2004 03:45:04 GMT
This is somewhat beyond my knowledge, but...

1. If its easier, we could deploy an additional gbean for the realm 
along with the JettyWebAppContext: the configuration would be generated 
by the JettyModuleBuilder.

2. We're going to need to do something so we are deploying gbeans for 
servlets, and do this fairly soon.  This is going to involve fairly 
extensive changes to how we deploy web apps.  What is your guess on the 
impact of this on your proposal?

thanks
david jencks

On Oct 31, 2004, at 7:22 PM, Aaron Mulder wrote:

> 	Near as I can tell, if you deploy a web app with a web.xml
> including a realm-name of "foo", then Jetty is going to try to use a
> UserRealm named "foo" to authenticate users to that application.  (I 
> guess
> if you omit the realm-name tag, which is legal for form-based auth, it
> falls back on the Jetty logic to select the only security realm if 
> there's
> 1 security realm configured and fail otherwise.)  Unfortunately, the
> UserRealms available to Jetty are in one big list in the Jetty server.
> 	I think this means that if two totally different applications both
> use a realm-name of "Application Realm", they will be forced to use the
> same actual security realm.  I don't like this much, because the 
> web.xml
> is provided by the developer, and the deployer has at best an awkward 
> way
> to override that to resolve naming collisions between third-party web 
> apps
> (copy the web.xml and use an alt-dd in the EAR).
> 	Further unfortunately, Jetty actually uses the name of the
> UserRealm when constructing its authentication challenge, such as for 
> HTTP
> Basic Auth.  So if we do something to let the deployer override the
> indentifier of the back-end security realm implementation as known to 
> the
> Jetty web app, it'll change the challenge strings.
> 	Still further unfortunately, in order to hook Jetty up to a
> Geronimo SecurityRealm, you need to manually deploy a GBean.  I don't 
> like
> that much because it means that even if you're got your security realms
> already up and running in your server, you can't just deploy a new web 
> app
> and have it work, you have to deploy one or more GBeans in addition.  
> On
> the up side, you can deploy GBeans as part of your geronimo-jetty.xml
> deployment plan, but still, this is way Too Much Information for the
> deployer to need.
>
> 	So anyway, I propose an enhancement to the Jetty DD and interface.
> I suggest we add a tag for security-realm to geronimo-jetty.xml.  Then 
> we
> add an analogous property to JettyWebAppContext.  In the doStart of the
> JettyWebAppContext, if you specified a security realm in
> geronimo-jetty.xml, we'd look up the correct realm in Geronimo and call
> setRealm with a new JAASJettyRealm that wraps the Geronimo realm.  That
> would solve all of these problems at once:
>
>  - the realm-name in web.xml is no longer necessarily connected to the
>    underlying security realm that will service requests.  Two apps with
>    the same realm-name can be serviced by different actual realms.
>
>  - the deployer (person) can wire an application up to any security 
> realm
>    available in the server.
>
>  - there's no GBean configuration required -- you give the name of the
>    realm you want, and the plumbing sets it up for you.
>
> Aaron
>
> P.S. Whether we do that or not, the geronimo-jetty.xml security 
> settings
> seem overcomplicated since they allow you to add principals from more 
> than
> one realm to your roles, but any given web app can only produce 
> principals
> from one realm.
>


Mime
View raw message