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