Hi Rich,
I think this brings out some of the
problems in this approach.
For example, your wording bellow can be interpreted
to say that the event data is secure, but the fact that the event fired is not.
Obviously this is not always the case.
Personally I think that for consumers that
manipulate the content of the event, there should not be a “must not”
or even “should not” statement, because somebody is developing an “application”
that understands the nature of the data that he is receiving and sending, and
it is up to that developer to integrate the security considerations.
(An example of such use case would be a
raised event that contains a user name and email, where the user name does not
need security but his email does.)
For basic event consumers I would say that
even the fact that the event was raised should not be exposed on an insecure
channel.
Another question is what happens when a
consumer distributes a requiresSecureDistribution event on a secure channel to
another producer, which then (not knowing that this data is actually considered
secured) raises a non requiresSecureDistribution event containing parts of the
data?
Ideally I would like use to drop this
field altogether and leave the security of any element in the SOAP message to
lower levels of the SOAP stack (WS-Policy?). I am not sure if this is currently
viable here. Any thoughts?
Yossi.
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Thursday, December 16, 2004
4:31 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Issue #28:
Replace EventDescription.requiresSecureDistribution?
One area that is not reflected in the current draft,
nor considered in Andre's alternate proposal, is that the resulting security
level needed for distributing an event applies not only to directly
distributing the event as the portlet has generated it, but also becomes the
minimum for the distribution of any information contained within the event
which the Consumer might distribute in some other event it composes. I'll add
language to this effect to draft 04 and would also plan to include it if the
mechanism is changed to Andre's proposal.
Rich
Rich Thompson/Watson/IBM@IBMUS
12/16/2004 08:29 AM
|
To
|
wsrp@lists.oasis-open.org
|
cc
|
|
Subject
|
RE: [wsrp] Issue #28: Replace
EventDescription.requiresSecureDistribution?
|
|
I have opened issue #28 for this topic. Basically we have two proposals in
front of us:
1. Have requiresSecureDistribution fields on both the EventDescription and
Event structures. This presumes that non-secure distribution is allowed unless
the portlet has said otherwise using these flags.
2. Have authorizedNonSecureDistribution field on just the Event structure. This
requires that the Consumer distribute events in as secure manner as it received
them unless this field has been set to true (default = false).
What do people think of these two choices?
Rich
Andre Kramer
<andre.kramer@eu.citrix.com>
12/16/2004 04:47 AM
|
To
|
wsrp@lists.oasis-open.org
|
cc
|
|
Subject
|
RE: [wsrp]
EventDescription.requiresSecureDistribution
|
|
The markup related fields you mention speak more about user agent to consumer communications
than WSRP protocol security to me. My concern still is that we are adding
security protocol (which we usually tend to avoid) and that this could lead to
problems for 2.0 implementation and continuing down the road (when we have
message based security and policy negotiation). If we really need the
functionality you describe below would the following not be simpler?
AuthorizeInsecureRedistribution : Boolean flag on Event objects (default
false). If a consumer receives an event with this flag set to true and the
consumer can verify that the flag is as the producer set it (i.e. was not
tampered with, for example because the event was signed by the producer and the
consumer verified the signature or was received over a secure end-to-end transport)
then the event MAY be re-distributed to other portlets over an insecure
communications channel. Such explicit downgrading of security by a
producer/portlet should be used with care. Note, consumers may redistribute an
event received on an insecure channel regardless of the value of this flag.
[The event description flag would go.]
Sorry keep laboring the point but security is extremely important to get right.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 15 December 2004 18:08
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] EventDescription.requiresSecureDistribution
It was commented at the F2F that much as we have these fields relative to
markup, we would need them for events. Without much discussion, everyone agreed
and my notes say to add the fields. I think the following may provide a base
use case for them:
A Consumer incorporates a pair of remote portlets (P1 & P2) on a page
where:
P1: The Producer only offers unsecure ports (e.g. http)
P2: The Producer only offers secure ports (e.g. https)
1. If P2 generates an event that does not require secure communication during
distribution, how to tell the Consumer?
2. If P1 generates an event that it determines does need secure communications
and determines it can securely send it to the Consumer (either by network
topology or message security), can it insist that it only be distributed in a
secure manner?
Obviously a Producer offering both types of ports just complicates the logic
(but not the fundamental questions) by throwing in the question of whether of
not the transport layer will make the current communications with the Consumer
secure. Message level security just adds another equivalent wrinkle to the
logic side of things.
I think both of the above situations will happen and that the protocol should
make it easy to signal to the Consumer the security concerns related to
distributing an event. I suppose we could remove the field from the event
description and require on the event, but this would move valuable information
from design time to runtime.
Rich
Andre Kramer
<andre.kramer@eu.citrix.com>
12/15/2004 11:52 AM
|
To
|
wsrp@lists.oasis-open.org
|
cc
|
|
Subject
|
RE: [wsrp]
EventDescription.requiresSecureDistribution
|
|
A producer that wishes to return an event securely can not publish a http
binding (i.e. only an https binding so that SOAP responses are secured) if
transport level security is to be used, or use message level security for
responses. Given we start from this position, is it not more a question of the
producer possibly granting the consumer the right to forward an event on a less
secure channel? How useful is such a feature as opposed to just mandating that
a securely returned event be always forwarded securely? I think the end goal
should be for end to end security to be used to secure the event payload so do
we really need these flags?
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 15 December 2004 15:07
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] EventDescription.requiresSecureDistribution
Rereading this on the OASIS distribution reminded why the event field did not
have a default specified in the schema ... its default is whatever was
specified in the EventDescription.
Rich
Rich Thompson/Watson/IBM@IBMUS
12/15/2004 09:20 AM
|
To
|
wsrp@lists.oasis-open.org
|
cc
|
|
Subject
|
Re: [wsrp]
EventDescription.requiresSecureDistribution
|
|
Good point on the possibility of tampering ... I'll add a sentence in section 9
of draft 04 to point this out.
The reason the field exists in both places is that some events will always require
secure distribution and some will only require it when sensitive information is
being carried in the payload (i.e. dynamic payload contents).
We deliberately named the equivalent fields in v1 as simply requiring security.
This allows evolving security standards to be used as they become supported.
Thanks for catching the .xsd overlook of the default value. Has been updated
relative to the next version.
Rich
Andre Kramer
<andre.kramer@eu.citrix.com>
12/10/2004 05:15 AM
|
To
|
wsrp@lists.oasis-open.org
|
cc
|
|
Subject
|
[wsrp]
EventDescription.requiresSecureDistribution
|
|
We should note that basing security decisions
on
EventDescription.requiresSecureDistribution
only makes sense if the EventDescription was itself
was
retrieved
securely. The threat here being
Tampering.
I
do not see why we would want to duplicate
the
flag in the Event type itself, even if we include it in the
event
metadata.
IMHO
A
consumer should either use (securely determined) metadata to
determine
the
security level for event transmission or use the same
security level at which an event was received to re-distribute the
event (Event.RequiresSecureRedistribution?).
Would
it be simpler to use the same rule as for getMarkup to distribute all events?
i.e. If a producer publishes a secure binding (i.e.
SSL)
then the consumer should make use of it? Or, better, provide
and
encourage means for the event data to be signed/encrypted by sending
portlets?
Regards,
Andre
PS.
In any
case, the Event.requiresSecure(Re)Distribution
declaration XML schema could do with a
default="false" to match the EventDescription convention.