[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Secure URL handling JSR & WSRP
but I think we need to agree that this needs to be better alligned with the
JSR.
Currently a WSRP-JSR bridge has no way to cleanly bridge between those two
since the isSecure() flag semantics differ.
This leads to various awkward situations.
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
Rich Thompson
<richt2@us.ibm.co
m> To
wsrp@lists.oasis-open.org,
04/23/07 04:38 PM wsrp-interop@lists.oasis-open.org
cc
Subject
Re: [wsrp] Secure URL handling JSR
& WSRP
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
<sthepper@hursley.ibm.com>
To
04/20/2007 04:37 AM wsrp@lists.oasis-open.org
cc
wsrp-interop@lists.oasis-o
pen.org
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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]