struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Security Solution
Date Tue, 02 Apr 2002 21:59:55 GMT
See intermixed comments below.

On Tue, 2 Apr 2002, Phase Web and Multimedia wrote:

> Date: Tue, 2 Apr 2002 13:23:35 -0700
> From: Phase Web and Multimedia <>
> Reply-To: Struts Developers List <>
> To: Struts Dev <>,
>      Struts User <>,
> Subject: RE: Security Solution
> Greetings Michael,
> I don't believe it has to be struts specific. But, I have never used it
> anywhere but struts. There many other features I would like to add to it.
> Specifically an ldap realm for authorization and perhaps add some hooks that
> will provide EJB conectivity. Do to my EJB ignorance I don't even know if it
> is possible.

Such an approach to application-managed security (but with a pluggable
implementation of the user database) would probably be pretty popular.  In
fact, what you are describing is pretty similar to how Tomcat itself
implements container managed security (you might want to snoop the Tomcat
4 sources for ideas).  However, there are some restrictions -- most of
which you've already identified -- in the scope of this effort.

> One thing to note. Because a webapp has limited access to the server scope
> this security solution is context specific for now. This is why I want to
> add some of the afformentioned hooks. I also imagine it would be possible to
> store the security xml file so that it can be cross context and provide a
> single security config for multiple contexts under a host.

It seems unlikely to me that a server-wide (or virtual-host-wide)
implementation of application managed security can be created that is
portable across servlet containers.  You pretty much have to hook in to
container-specific facilities to pull it off.  That being said, solving
the problem for a particular webapp is still a very useful scenario.

> Another thing to note is that many of the apis that are out there (ie tiles,
> jsp, servlet) take advantage of the container managed security by checking
> roles. These are all container specific. I've chosen to abandon all of those
> niceties to gain greater flexibility in other areas. I have sacrificed the
> standard convention that these mechanisms provide. I feel it is a good
> decision for my niche.
> I will be providing mechanisms equal to the isUserInRole(), getRemoteUser(),
> and getUserPrincipal(). But these objects will be context-session specific.

Faking the values returned by these methods is pretty easy in a Servlet
2.3 environment, where you can create a request wrapper.  That would be
sufficient for dealing with what Struts-ish things like tiles needs.

> My solution should be able to work as an app level link to a larger security
> system that bypasses tomcat security all-together.
> I have heard some speak about ejb as thought they need the container-managed
> security. This might be so. I don't know. I am hoping that someone might be
> able to provide that functionality.

The EJB layer *absolutely* requires container managed security.  In the
absence of using container managed security at the web layer, you'd need
to figure out some other mechanism for converting your own notion of user
identity into a user and role set that is recognized by the EJB tier.  A
couple of options include:

* The web container runs completely separate from the EJB container, and
  appears to be a standard J2EE application client.  (This probably means
  you lose pretty badly on performance, however).

* In Servlet 2.3 there is the notion of the "run-as" identity assigned to
  all web tier code that has not been authenticated via container-managed
  security.  If your application design will let you share a single
  EJB-user identity, you can probably get away with this approach.

> If you would like to look at my code I am more than happy to pass it on.
> But, it is narrow in scope to my application. This has become apparent to me
> as I read some email regarding what I have developed. I believe the code and
> concept to be a good starting point to provide a better security framework.
> The strongest part of the code it the SecurityFilter and MulitpleLogin
> configuration options.
> Let me know,
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354

Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message