Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of fernando@lozano.eti.br
 designates 200.187.76.91 as permitted sender)
Sender: fernando@lozano.eti.br
From: fernando@lozano.eti.br
To: dev@struts.apache.org
Subject: Struts and Declarative Security in Portals
Date: Mon, 09 Nov 2009 12:32:54 -0300
Priority: normal
Message-id: <4af83626.130.333b.659629986@lozano.eti.br>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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