Re: [wsrp] Issue #28: Replace EventDescription.requiresSecureDistribution?

[Subbu Allamaraju <subbu@bea.com>]

There are a few of reasons why adding such pseudo security policies 
would be difficult to build and manage.

a. Ideally we should let intermediaries and stacks provide security 
declaratively. Hopefully, stacks/intermediaries will provide message 
transformation/enrichment for security based on policies declared at the 
web services level.

b. We need to let WSRP Producer/Consumer implementations take advantage 
of security plumbing provided by stacks without significant rework.

c. In a complex production environment, there may be several web 
services, some of which talking WSRP. It would be easy for folks/tools 
monitoring/auditing the traffic if we don't add pseudo-policies that 
folks outside WSRP cannot understand/enforce.

Regards,

Subbu


Andre Kramer wrote:
> A complementary viewpoint on this is that such decisions should be left 
> open to a higher level. One can easily imagine an Admin or Page Designer 
> still wiring up event exchanges over different (security) protocols, 
> following a meta-policy.
> 
> Regards,
> Andre
> 
> PS. My alternative proposal is an attempt at a minimal policy expression 
> and dropping the security statements altogether might well be the best / 
> consistent thing to do.
> 
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 03 January 2005 14:50
> To: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp] Issue #28: Replace 
> EventDescription.requiresSecureDistribution?
> 
> Can someone justify why such metadata should not be handled at a lower
> level?
> 
> This field seems like a security policy statement. Last time when we
> discussed this topic, we decided against adding policy-like metadata to
> the protocol, hoping that some future ws-* standard would provide that.
> 
> Subbu
> 
> Rich Thompson wrote:
>  >
>  > 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.
>  >
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
>