wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] Issue #28: Replace EventDescription.requiresSecureDistribution?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 21 Dec 2004 11:49:33 -0500
Mike has raised the question of whether
the requiresSecureDistribution flag is needed only when portlets raise
events, or also on events sent to portlets (as per draft 04).
My take is that this flag should be
propagated with the event such that it can continue to indicate the minimum
security needed to distribute the information the event contains (portlet
distribution of the information may not commonly happen, but it certainly
will).
Rich
Rex Brooks <rexb@starbourne.com>
12/21/2004 09:58 AM
|
To
| "Yossi Tamari"
<yossi@giloventures.com>, <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] Issue #28: Replace
EventDescription.requiresSecureDistribution? |
|
Hi Yossi, Mike, Everyone,
I;m not comfortable with only the security available lower
in the stacks. Also, I think our audience will largely be happier if they
know they can explicitly manage security for events in the protocol. I
prefer 1 over 2 because it is more clear and strict. I think this is one
area where we need to be rigorous even if we seem to be overspecifying.
I will actually try to attend tomorrow, but it may be
difficult. This December has been anything but slack.
Ciao,
Rex
At 1:26 AM -0800 12/21/04, Yossi Tamari wrote:
Hi Mike,
If the portlet is expected
to "secure" its actual data as you say, why do we need this flag
to indicate that the consumer must not map the data?
Especially if the data is encrypted,
presumably only viewable at the intended point of delivery, there is absolutely
no need to raise this flag. This is what I mean by using the lower levels
of the stack.
I also think that allowing
consumers to decide what producer is securely connected (not defining it
in the spec, as you suggest by "social" security) is really equivalent
to letting the consumer decide which elements of the data are secure.
A good topic for discussion
tomorrowŠ
Yossi.
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Tuesday, December 21, 2004 12:07 AM
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] Issue #28: Replace EventDescription.requiresSecureDistribution?
Finally getting caught up on the
discussions ... Nope, I think we will have to do this in the protocol.
I don't see anyway for it to occur in a lower layer. The general
problem I want to see solved is to allow a portlet to indicate/guarantee
that at least https security will be used to distribute this event and
or portions of its data [in mapped events] to other portlets. We
need the boolean in the description to help consumers to guide end-users
by restricting the list of portlets that can receive the event. Producers
requiring "true" transport level security including at the point
it raises an event is expected to encode those performBlockingInteraction
urls using https. However, we still want to support producers that
use "social" security -- such as having the consumer/producer
inside a firewall and hence need to separate the distribution requirement
from the method of invocation. To avoid the problems Yossi points
out we need the specification to require/mean that all events distributed
as result of raising this event must be distributed securely. I.e.
once you raise an event and ask it be distributed securely it and anything
mapped from it, or any events raised as a consequence of its distribution
would have to be distributed securely. To avoid consumer security
holes where the consumer maps the value from an event into application
data and later distributes this unsecurely, the portlet would be expected
to "secure" its actual data -- i.e. its types would be opaque
and it likely is encrypted.
Finally, as to why we need this value in both Event and EventDescription
I think we need it because we don't require Events have EventDescriptions.
I.e. I can raise an Event I haven't told the consumer about.
-Mike-
Yossi Tamari wrote:
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.
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]