We had this discussion in the v1 timeframe.
We ended up with a simple bi-state (as represented by the wsrp-secureURL
flag):
true: The portlet requires secure
communication.
false (or missing): The portlet
does not require secure communication though the portal/Consumer may still
use it if other portlets or the page require secure communications.
I'm not seeing the use case for a portlet
saying it prefers non-secure communication ...
Rich
Stefan Hepper <>
04/20/2007 04:37 AM
To
cc
Subject
Re: [wsrp] Secure URL handling JSR &
WSRP
Hi Richard,
I would prefer the semantic that you've defined below with the tri-state
and will also bring this up in the JSR 286 EG to clearify this.
Stefan
Richard Jacob wrote:
> 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
>
>
>
