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: bridges-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: bridges-dev-h...@portals.apache.org
