After a lot of trail-and-error and no trail-and-success (hence the long res=
ponse time) I've come to the following conclusion (I'm not saying that this=
is correct - I might be way of here since I'm pretty new to all this):
When building your portlet with JSF (MyFaces) and using commandLink and com=
mandButton for navigation, it is not possible to switch dynamically between=
http and https within the same portlet.
If this where to work, the best implementation would be if both commandLink=
and commandButton had a secure=3D"true" attribute that could be applied, f=
orcing the application or portal server to render the links and forms with =
https.
Since this is not the case, the other solution would be to move all the fac=
es that are supposed to be secure into a separate folder (i.e. /faces for t=
he regular faces and /faces/secure for the secure once) and then use a secu=
rity-constraint like the following in the web.xml (as you correctly suggest=
ed Julien):
<security-constraint>
| =09<web-resource-collection>
| =09=09<web-resource-name>Secure</web-resource-name>
| =09=09<url-pattern>/faces/secure/*</url-pattern>
| =09</web-resource-collection>
| =09<user-data-constraint>
| =09=09<transport-guarantee>CONFIDENTIAL</transport-guarantee>
| =09</user-data-constraint>
| </security-constraint>
It is not possible to put this into the general web.xml for the portal sinc=
e the url-pattern doesn't make sense to anybody else then the portlet it se=
lf. From outside the portlet a URL accessing a page in /faces/secure would =
look like this (line braked using =C2=BB):
http://localhost:8080/portal/portal/default/Hello%20World/My%20Portlet?mask=
=3D2 =C2=BB
&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=3D =C2=BB
%2Ffaces%2Fsecure%2FSecureHelloWorld.jsp
As you can see only the last argument part of the URL (in red) reveals that=
we are accessing something in the folder /faces/secure. For anybody else t=
hen the portlet this just looks like any other URL argument.
But how come that I can't get this to work then? I've tried to insert the a=
bove security-constraint argument into the portlet's web.xml but it seems l=
ike that the server just ignores it. The security-constraint arguments in j=
boss-portal.sar/portal-server.war/WEB-INF/web.xml work fine though. My gues=
s is that the filter-mapping also present in the web.xml file overrules the=
security-constraint so that it never gets to that:
<filter-mapping>
| =09<filter-name>extensionsFilter</filter-name>
| =09<url-pattern>/faces/*</url-pattern>
| </filter-mapping>
The conclusion? Since we use Apache as the entry point (and also terminates=
any SSL here as well) we might as well create a RewriteRule that uses regu=
lar expressions to look for %2Ffaces%2Fsecure%2F in the URL and then do a H=
TTP redirect to https. But what are the downsides or problems with this?
| * Since the logic about which faces should be accessed via https is now=
put into the Apache server, we can no longer be certain that other portal =
servers acting as WSRP consumers will protect the same faces with SSL as we=
want them to (in fact this could only be possible if the commandLink or co=
mmandButton had a secure=3D"true" attribute).
| * Can we always be certain that the URL will reveal which face (and in =
turn which folder) is about to be accessed? What if this is part of a POST =
request? In that case an Apache RewriteRule will not be able to detect it a=
nd then not be able correctly secure the site.
|=20
View the original post : http://www.jboss.com/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3954640#3954640
Reply to the post : http://www.jboss.com/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3954640
|
