Re: Struts and Declarative Security in Portals

[Ate Douma]

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.

Regards,

Ate

ferna...@lozano.eti.br 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 from
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 and
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 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 option
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 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 container.

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 already
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 container
itself but not by a portlet container, and neither Struts nor the Apache 
Portals Portlet Bridge
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:

  <filter>
    <filter-name>DeclaritivePathSecurityFilter</filter-name>
    <filter-class>com.acme.security.DeclaritivePathSecurityFilter</filter-class>
    <lifecycle>ACTION_PHASE</lifecycle>
    <lifecycle>EVENT_PHASE</lifecycle>
    <lifecycle>RENDER_PHASE</lifecycle>
    <lifecycle>RESOURCE_PHASE</lifecycle>
    <init-param>
      <name>pathParameterName</name>
      <value>myPathParameterName</value>
    </init-param>
    <init-param>
      <name>error-page:403</name>
      <value>/my_403_error_page.jsp</value>
    </init-param>
    <init-param>
      <name>secured-path:/acme/wholesale/*</name>
      <value>CONTRACTOR</value>
    </init-param>
    <init-param>
      <name>secured-path:/acme/retail/*</name>
      <value>CONTRACTOR,HOMEOWNER</value>
    </init-param>
  </filter>

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" 
init-parameter.
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 http://issues.apache.org/jira/browse/PB-93 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() method.
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, or
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: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org