Secure URL handling JSR & WSRP

[Richard Jacob <richard.jacob@de.ibm.com>]

It seems we have quite different semantics on JSR and WSRP concerning
PortletURL.setSecure() and wsrp-secureURL.

The JSR defines that setting the setSecure(true/false) seems to indicate a
switch either to HTTP od HTTPS and setting nothing, i.e. not calling
setSecure() does not switch the secure mode. The JSR spec wording seems
also to diverge from the API description where the API says that setting
setSecure(false) indicates that the portlet does not need a secure
connection (but does not indicate that the portal should actually switch to
HTTP).

In WSRP we don't seem to have a tri-state (secure, unsecure, don't
care/leave as is). What we currently say in the spec is:
"The value for the wsrp-secureURL is a boolean indicating whether the
resulting URL MUST involve secure communication between the client and
Consumer, as well as between the Consumer and Producer. The default value
of this boolean is “false”"

Does that mean that not setting wsrp-secure on a rewrite URL means "switch
back to non-secure" or " i don't care / leave as is"?
We don't say anything what should really happen if wsrp-secure=false is
really set.

Can we agree on a common semantics between both specs where we would have a
tri-state:
- true -> MUST be called over a secure channel
- false -> indicating preference to switch back to non-secure
- not-present -> don't care / keep communication as is

Another implication of the current JSR semantics seems to be that portlets
might change the security for other portlets. Assume the following
scenario:
- portlet A has a link with setSecure(true) -> portal switches to HTTPS and
displays page with HTTPS
- portlet B on the same page has a link explicitly setting setSecure(false)
-> portal switches to HTTP and views A & B -> A needs to discover that the
request is not secure (PortletRequest.isSecure()==false) and does not
display its intended content.
Thus portlet B has "disabled" the display of portlet A with an URL
invocation on B.
How does it work with reverse proxies where communication between client
and proxy is HTTPS whereas between the proxy and the (consumer) portal is
HTTP?
This is however a standard HTTP & SSL problem here.

Or is there an anticipation that the portal should keep some kind of state
and determine that some portlet on the page is in "secure mode" (because it
encoded a URL with setSecure(true) ) and thus prevent switching to HTTP on
invocation of B's URL?
This seems to be the case in WSRP where we say:
"Note that the Consumer’s aggregated page MUST be secure if any of the
Portlets whose content is being displayed on the page have indicated the
need for secure communication for their current markup."

So from an interop perspective and those who try to map JSR & WSRP
semantics I would have the question:
- what do you expect when you set wsrp-secureURL=false?
- what do you expect when you do not set  wsrp-secureURL

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294