OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


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
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]