You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by fe...@lozano.eti.br on 2009/11/09 16:32:54 UTC
Struts and Declarative Security in Portals
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.
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.
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.
[]s, Fernando Lozano
4Linux Software, Brazil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts and Declarative Security in Portals
Posted by Ate Douma <a....@onehippo.com>.
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
fernando@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts and Declarative Security in Portals
Posted by Ate Douma <at...@douma.nu>.
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
fernando@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-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: Struts and Declarative Security in Portals
Posted by Ate Douma <at...@douma.nu>.
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
fernando@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org