struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Struts and Declarative Security in Portals
Date Mon, 09 Nov 2009 15:32:54 GMT
Hi there,

I started this on the Apache Portals Bridges mailing list but had no replies so far. I have
submitted a patch and an opened a ticket on Apache JIRA (PB-93) and hope someone here can
feedback on my approach to the problem, maybe even expedite it's inclusion on a new release
Apache Portals.

It's related to Struts 1.x (is it still in active development, or at least supported?) but
maybe the
issues are present also in Struts 2 -- I had a similar issue with JSF and found the problem
was not
considered either by the MyFaces developers, MyFaces Portlet Bridge developers, or the JSR-301
JSR-286 expert groups.

I'd also appreciate If someone can comment on the same issues regarding declarative security
Struts 2.

Here's the original, yet unanswered message from the apache portals bridges mailing list:

I some issues with Java EE declarative security and Struts 1.x Portlets, and a patch that
some of them. I just wish feedback from users and developers on those issues and my ideas
about them
before opening a JIRA ticket abd submiting my patch.

Althouth some developers perfer to ignore Java EE security completely, and use either Acegi
or some
in-house (in-)security solution, if you do use Struts or JSF you can leverage standard declarative
security with ease.

But, when you move from from servlets to portlets, you give up all declarative security features,
that is, web.xml <security-constraints> become noops. It's not so bad with Struts, where
you can
still use roles in action mappings, but with JSF and plain servlet development you nave no
but hand coded programatic security. :-(

I understand portlets don't have URI so at first you would not have away to implement declarative
security for portlets. Actually, most frameworks use a navigation parameter (navigational
state) to
emulate request URLs -- This is the case with both the standard JSF portelt bridge and the
Portals struts portlet bridige from apache portals. So it would be feasible for a portlet
bridge to
read <security-constraints> from web.xml and emulate their working as if in a servlet

In the general case, there could be a <security-contraint> inside portlet.xml with subelements
<parameter-name> and <parameter-value> to replace <uri-pattern> from web.xml,
and the portlet
container could enforce declarative security access control using the navigational context.

I don't believe I was the first to think about this but I think this is a big omission from
all JSRs
related to portlet development under Java EE. :-( 

Another, but related, issue: back to JSF (and also struts) in a servlet container we would
use a
web.xml <error-page> element for <error-code> 403 to display a user-friendly "access
denied" page.

We also loose this capability inside a portlet container, but that's another thing a portlet
could emulate with ease. And that's another thing we could have properly implemented in portlet.xml,
maybe as an exception handler so portlets don't get configured for http error codes.

So there are actually two issues:

1. Enforcing declarative security access controls inside a portlet container -- Struts already
solves that using <action-mapping> roles attribute, which is compatible with both servlet
portlet containers;

2. Dsiplaying an user-friendly error page, which in a servelt container is done by the container
itself but not by a portlet container, and neither Struts nor the Apache Portals Portlet Bridge
provide an alternative.

My first idea at (2) was to simply subclass the StrutsPortlet and override the renderError()
But this is quite restrictive as the original method can't use a RequestDispatcher to include
error page or call an Struts action.

Throwing an exception is also not an option, because exception thrown by StrutsPortlet don't
the error handler configured by struts-action.xml

My solution is to patch StrutsPortlet so it pass the proxied ServletContext and HttpServeltRequest
to renderError, and use either a portlet init-param or context-param to configure an error
page by
http error code, replacing thus the web.xml <error-page> element, and leaving generic
exceptions to
the struts error handler.

It's a trivial patch and solves my issues until the portlet API provides a better solution,
someone (maybe me) thinks about emulating web.xml declarative security features inside the

[]s, Fernando Lozano
4Linux Software, Brazil

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

View raw message