Re: [wsrp] Secure transport

[Rich Thompson <richt2@us.ibm.com>]

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>

05/09/05 12:11 PM

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