It must also be possible for the consumer (admin)
to dictate the security of the end user page. In this model, the admin
populates pages with portlets with a page being either secure (https) or
non-secure (http). One consideration here is that portlets that require their initial
markup to be secure are only allowed on secure pages. Portlets on secure pages
must only have https links, so (any) wsrp url templates only carry secure
entries (I hope portlets can deal with this) or any rewrites are forced to be
https:// by the consumer rewriting. The only other rule is that portlets on
secure pages with secure wsrp protocol bindings (SOAP over https) will always
be called using the secure wsrp binding.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 09 May 2005 20:08
To: wsrp
Subject: Re: [wsrp] Secure transport
I do think #2 abides by the conformance statement as it
does not show the sensitive fragment over a non-secure channel, but I also
think this is the least desirable from an End-User experience point of view. I
too am curious what Consumers do today.
Rich
Michael Freedman
<michael.freedman@oracle.com>
05/09/05 03:00 PM
|
To
|
wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
|
Re: [wsrp] Secure transport
|
|
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_
>
>
>
---------------------------------------------------------------------
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