Re: [wsrp] Secure transport

[Michael Freedman <michael.freedman@oracle.com>]

Yes, that is the scenario I am talking about. I am trying to determine 
if we believe (2) abides by the conformance statement as this is clearly 
the eadsiest thing for the consumer to do an it avoids the complexities 
of managing a stack of secure requests [i.e. while a page is secure 
another portlet also asks that the page be secure -- now the consumer 
would have to remember there are two portlets requiring this and wait 
until both "release" before it stops using (1), (3), or (4).

What do the existing consumers do today?
-Mike-

Rich Thompson wrote:

>
> To make sure we are talking about the same scenario, I understand it 
> to be:
> 1. The user interacts with Portlet 1's URL which set wsrp-secureURL to 
> true.
> 2. The Consumer receives the interaction over https: (i.e. URL 
> rewriting respected the parameter)
> 3. The Consumer securely passes the interaction to Portlet 1
> 4. Portlet 1 generates its new page fragment
> 5. The Consumer builds the response page from this fragment and cached 
> fragments for the other portlets (just for arguments sake)
> 6. The user interacts with Portlet 2's URL which does not set 
> wsrp-secureURL
> 7. The Consumer receives the interaction over http:
> 8. The Consumer passes the interaction to Portlet 2
> 9. Portlet 2 generates its new page fragment
> 10. The Consumer builds the response page from this fragment and 
> cached fragments for the other portlets (just for arguments sake)
>
> The question is whether this scenario results in non-secure display of 
> content which Portlet 1 said required secure communications. The 
> conformance statement is trying to say the answer must be no!
>
> I think there are several solutions that all abide by the conformance 
> statement:
> 1. The Consumer could have rewritten all the URLs in step 5 such that 
> step 7 happens over https. One key question is how the Consumer knows 
> when it can stop doing this.
> 2. The fetch from the fragment cache in step 10 does not find the 
> fragment needing secure communications such that the Portlet 1 has 
> getMarkup invoked with MarkupParams.secureClientCommunication set to 
> false. Portlet 1 would need to determine what to show ... likely a 
> link to get back to secure client communications.
> 3. In step 5 the Consumer can have added to its state for the page 
> that Portlet 1 is currently requiring secure communications. In step 7 
> the Consumer could then detect that secure communications were 
> required and redirected the user agent such that a secure channel is 
> used despite the initial interaction not requiring it.
> 4. Choices 3 & 1 could be combined to avoid the redirect while also 
> remembering what portlets are currently requiring the secure channel.
>
> Rich
>
>
> *Michael Freedman <michael.freedman@oracle.com>*
>
> 05/09/05 02:11 PM
>
> 	
> To
> 	
> cc
> 	wsrp <wsrp@lists.oasis-open.org>
> Subject
> 	Re: [wsrp] Secure transport
>
>
>
> 	
>
>
>
>
>
> I presume you are refering to the following line in section 10.2.1.7:
> "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."
>
> Its not clear what this means. Is it merely a requirement that the 
> page response be over a secure channel if the portlet/page request was 
> secure? Or does it say that once in a portlet's secure link is invoked 
> the Consumer must keep the page in secure mode until the portlet that 
> went into secure mode, leaves it? I.e. must find a way that all 
> subsequent links on the page use https? The former seems obvious. The 
> later seems a major pain for Consumers as you potentially have to 
> manage a stack of states. Can you clarify?
> -Mike-
>
> Rich Thompson wrote:
>
> We did discuss having a return field from pbia that required the page 
> to use secure communications. We decided against it due to the small 
> set of use cases where it would be significant and the overall impact 
> of requiring the Consumer to redirect the user agent at that point in 
> the process of building a new page.
>
> There is a requirement in 10.2.1.7 (wsrp-secureURL definition) which 
> requires that the secure communications be used for delivering the 
> page to the user when any portlet has specified that secure URLs be 
> used. Basically this allows Consumers to support other Portlet's URLs 
> not being secure if a redirect to a secure version of the page happens 
> (likely improves fragment cachability) or Consumers can rewrite all 
> URLs to use secure references (would require that all Portlet's use 
> Consumer URL rewriting).
>
> Rich
>
> *Michael Freedman **_<michael.freedman@oracle.com>_* 
> <mailto:michael.freedman@oracle.com>
>
> 05/09/05 12:11 PM
>
> 	
> To
> 	wsrp _<wsrp@lists.oasis-open.org>_ <mailto:wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[wsrp] Secure transport
>
>
>
>
> 	
>
>
>
>
>
>
> To answer a question I was re-examining out secure transport
> mechanisms. It looks like the only runtime mechanism we provide allows
> a portlet to encode the secure transport requirement in its rendered
> URLs? Is this correct? Did we ever discuss trying to define a semantic
> [in BlockingInteraction] to allow a portlet to get equivalent behavior
> as defined by the flags in PortletDescription? Namely, the ability to
> ensure that all links on the page reflect the secure requirement vs just
> the one's in the portlet? If I understand things as we have them today,
> its possible for the portlet to switch to secure transport [via its URL]
> but then have the user interact with another portlet on the page that
> doesn't know/need secure transport. At this point the choices for the
> secure portlet are limited, for example it can revert to the non-secure
> page which caused it to enter, or render a screen that let's you
> re-eneter it in secure mode. Can anyone refresh my memory why we went
> this route vs trying to find hooks that allowed the portlet to switch
> the entire page into secure mode? Was it just too complicated on the
> consumer to keep track of this state as you interacted with different
> portlets with different requirements? Did we figure that most portlets
> in this situation would merely set the secureOnly flag and be done 
> with it?
> -Mike-
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in 
> OASIS
> at:_
> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>
>
>