struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: Struts and Declarative Security in Portals
Date Mon, 09 Nov 2009 21:26:40 GMT
Hi Fernando,

Sorry for the somewhat late response but last week I was at the ApacheCon and had more pressing
tasks at the time.
I'm also cross-posting this to the Struts dev@ list for the Struts 2 Portlet developers who
might be interested.

Further comments below.


Ate wrote:
> Hi there,
> I started this on the Apache Portals Bridges mailing list but had no replies so far.
I have already
> submitted a patch and an opened a ticket on Apache JIRA (PB-93) and hope someone here
can provide
> 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 and
> JSR-286 expert groups.

This issue was brought forward on (at least) the JSR-301 EG but AFAIK not yet on the JSR-286
EG (I'm an expert member on both).
I already responded on this on the JSR-301 EG, but I'll leave it up to the specification lead
if/when/what to reply.
My comments below however are similar to those I provided there.

> 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 solves
> 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
> security with ease.
> But, when you move from from servlets to portlets, you give up all declarative security
> 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 option
> but hand coded programatic security. :-(
> I understand portlets don't have URI so at first you would not have away to implement
> 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 Apache
> 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 as
> <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 bridge
> 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
> solves that using <action-mapping> roles attribute, which is compatible with both
servlet and
> portlet containers;
> 2. Dsiplaying an user-friendly error page, which in a servelt container is done by the
> itself but not by a portlet container, and neither Struts nor the Apache Portals Portlet
> provide an alternative.

First of all, a <security-contraint> or something like an exception handler in portlet.xml
as mentioned above is not possible with the 
portlet 2.0 (or 1.0) specification which strictly defines the portlet.xml structure.
This doesn't mean such features cannot be supported in a future portlet spec, but currently
this is impossible without using portlet 
container specific descriptors (e.g. vendor extensions).

However, in response to your question as it reached the JSR-301 EG, I proposed a generic (so
not Struts or other framework specific) 
solution using a JSR-286 (Portlet 2.0) PortletFilter which might provide the same or similar
behavior as the servlet container.

Such a PortletFilter can do portlet request pre-processing during which it can enforce security-constraints
as well as error-pages 
definitions configured either for the PortletFilter specific or possibly dynamically read
(during startup) from the accompanying web.xml

As you mentioned, portlet bridges for Struts, JSF and likewise frameworks almost all use a
predefined (render)request parameter defining the 
current or target application "URL". A properly configured PortletFilter therefore could do
portlet request security pre-processing by 
inspecting the current value of such parameter and enforce security constraints and if need
be error-page handling as well.

A quick (untested) portlet.xml configuration example I gave on the JSR-301 EG could be:


For the above example, the DeclaritivePathSecurityFilter would look for a request parameter
"myPathParameterName" and match its value 
against init-parameters which name start with "secured-path:", taking the remainder of these
init-parameter names as url-pattern.
If a match is found, it will then evaluate the init-parameter value as list of role names
to enforce against the request.
If it fails, it "overrides" the request parameter "myPathParameterName" with the value for
a (required) configured "error-page:403" 
The filter doesn't actually *do* anything but just hand over the overridden path value to
the underlying portlet bridge/framework, making 
this a completely generic solution.

And, as I indicated above, to make this more facy and less verbose, such a filter could instead
read the web.xml security configuration 
(possibly using an init-param configuration which web-resource-name(s) to read) and dynamically
construct its own security configuration 
based upon that.
Then, you would have an almost transparent and zero-configuration solution.

The alternative solution as you describe below and provided a patch for in
probably works fine 
too (I haven't had time to look at it), but is StrutsPortlet specific and also requires action-mapping
security configuration (which is just 
fine imo, but still Struts specific).

> 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 a JSP
> error page or call an Struts action.
> Throwing an exception is also not an option, because exception thrown by StrutsPortlet
don't reach
> 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 portlet
> bridge.
As I said above, I haven't reviewed your patch yet and might be willing to apply it for the
Struts Bridge if feasible, but if my proposal 
for such a DeclaritivePathSecurityFilter actually makes sense (and is doable in practice),
I'd prefer such a more generic solution as it is 
usable for many frameworks. In that case, I think we'd be more than happy to "host" such a
solution at Apache Portals Bridges, it just needs 
to be written :)

However, my "solution" is something I drafted up in 5 min. without actually trying it out,
so possibly I overlooked something obvious which 
might render it useless for your case.

Please let me know what you think and we can discuss it further if you like.

In addition, I'm curious to know if the Struts 2 Portlet developers might already have come
up with a solution for this problem themselves?
Any feedback on both these proposals from Fernando and myself would be very welcome.

> []s, Fernando Lozano
> 4Linux Software, Brazil

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

View raw message