OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue


I would like to clarify point A and disagree with point B. 

Disagreement - security policy should not define fault generation associated with mustUnderstand.
Security policy is between both sender and receiver, may involve other security layers (e.g. SSL/TLS) 
and may involve other policy mechanisms defined elsewhere. (A fault might be generated regardless of mustUnderstand)

Alternative interpretation of mustUnderstand:

mustUnderstand true for a SOAP Message Security header block means 

1) the receiver must return a SOAP fault if it has not implemented the SOAP Message Security 
specification corresponding to the namespace. Implementation means ability to interpret the schema as well as follow the required processing rules specified in SOAP Message Security.

2) the receiver must return a fault if unable to interpret or process security tokens contained in the SOAP Message Security header block according to the corresponding SOAP Message Security token profiles.

I do not understand why headers targeted at a role should be ignored when mustUnderstand is true. Why are they used if not meaningful for that role? (If the sender intends flexibility, why not set mustUnderstand to false?)

Can someone reiterate why #2 is a problem?

thanks

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Don Flinn [mailto:flinn@alum.mit.edu]
> Sent: Wednesday, December 03, 2003 9:04 PM
> To: WSS
> Subject: FW: [wss] ISSUE 190: text for SOAP MustUnderstand issue
> 
> 
> Irving
> 
> My understanding is the same as yours; that the TC put limits on the
> sender's control and I concur that this is the right course for 1.0.
> However, we should keep in mind for a later version of 
> WS-Security that
> there are situations where the sender requires control.  One 
> situation is
> delegation where the sender determines which entities can be 
> delegatees and
> control what the limit of the delegatees' delegation 
> capabilities should be,
> e.g. they can deposit into the sender's bank account but not 
> withdraw from
> it.  A few specifications have attacked the delegation 
> problem beyond simple
> impersonation and have found it to be difficult.
> 
> Don
> 
> -----Original Message-----
> From: Reid, Irving [mailto:irving.reid@hp.com]
> Sent: Wednesday, December 03, 2003 2:10 PM
> To: David Orchard; wss@lists.oasis-open.org
> Subject: RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue
> 
> 
> This was an earlier attempt. The new text (which I intend to 
> get out by the
> end of the week) will say something like:
> 
> A) The receiver must implement the WS-Security specification
> B) If any element within the wsse:Security header is not understood or
> implemented by the receiver, whether that element is part of the WSS
> specification or is an extension, the decision about whether 
> to generate a
> fault is based on the receiver's security policy
> 
> So, the short answer to your questions are "no" and "no". By my
> understanding of the discussion around this issue, the TC has 
> decided not to
> give the sender control over how its message is interpreted 
> through any sort
> of internal criticality flags.
> 
>  - irving -
> 
> 
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Wednesday, December 03, 2003 1:09 PM
> > To: Reid, Irving; wss@lists.oasis-open.org
> > Subject: RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue
> >
> >
> > Is this going to be the basis for the resolution of 190?  It
> > is listed in the issue list.  I'm quite confused because the
> > minutes say "if you can parse the schema everything is up to
> > your security model?" which seems quite different than the
> > text proposed herein.
> >
> > In particular, I don't know if it is possible by "parsing the
> > schema" to:
> > - specify a mandatory extension in an optional security header
> > - specify an optional extension in a mandatory security header
> >
> > I don't think "parse the schema" is the definition of
> > "understanding", or am I misunderstanding (:-) where this is going?
> >
> > Cheers,
> > Dvae
> >
> > > -----Original Message-----
> > > From: Reid, Irving [mailto:irving.reid@hp.com]
> > > Sent: Wednesday, October 29, 2003 3:45 PM
> > > To: wss@lists.oasis-open.org
> > > Subject: [wss] ISSUE 190: text for SOAP MustUnderstand issue
> > >
> > >
> > > This message relates to Issue 190, raised by the W3C XMLP
> > > working group.
> > >
> > > In WSS-SOAPMessageSecurity-17-082703-merged.pdf, lines
> > > 455-457, the draft reads:
> > >
> > > 455 The optional mustUnderstand SOAP attribute on Security
> > > header (sic) simply means you are aware of
> > > 456 the Web Services Security: SOAP Message Security
> > > specification, and there are no implied
> > > 457 semantics.
> > >
> > >
> > >
> > > The background is that SOAP allows header elements to contain
> > > a "MustUnderstand" attribute, and if MustUnderstand="1" (or
> > > "true") then the recipient of the message MUST return a fault
> > > if it does not understand said header element. Unfortunately,
> > > it's not clear what "understand" means in this context.
> > >
> > > We need to strike a balance between the extremes of:
> > >
> > >  o MustUnderstand just means "ignore at your own peril"; a
> > > recipient can completely ignore the content, but if that
> > > leads to problems they have no one to blame but themselves.
> > > In the real world, this is what it really comes down to. We
> > > don't have a protocol for sending Big Foam Cluebats across
> > > the network to people who ignore MustUnderstand elements.
> > >
> > >  o MustUnderstand means that a recipient must be able to
> > > fully process every optional sub-element and possible
> > > extension of the MustUnderstand header element. This is
> > > clearly too strict a constraint.
> > >
> > >
> > > The problem is further complicated by the fact that elements
> > > within wsse:Security may be extensions defined in other
> > > specifications, so we can't clearly specify where people need
> > > to look to determine how to "understand" them.
> > >
> > >
> > > I think the balance looks very much like the text we already
> > > have in the spec
> > > (WSS-SOAPMessageSecurity-17-082703-merged.pdf) in the
> > > "Message Security Model" section:
> > >
> > > 237 Where the specification requires that an element be
> > > "processed" it means that the element type
> > > 238 MUST be recognized to the extent that an appropriate
> > > error is returned if the element is not
> > > 239 supported..
> > >
> > > and also immediately above the text in question:
> > >
> > > 450 All compliant implementations MUST declare which profiles
> > > they support and MUST be able to
> > > 451 process a <wsse:Security> element including any
> > > sub-elements which may be defined by that
> > > 452 profile.
> > >
> > >
> > > Now, there is also an open issue (189) complaining about this
> > > text, since we don't provide a way for implementations to
> > > "declare" which profiles they support and therefore this MUST
> > > is unimplementable/unenforceable.
> > >
> > > Perhaps we could replace lines 450-452 and 455-457 with the
> > > following, and move lines 453-454 to the end of the section:
> > >
> > >
> > > Conforming implementations MUST be able to process the
> > > <wsse:Security> element and all sub-elements, including any
> > > elements defined by profiles or extensions supported by that
> > > implementation. If the <wsse:Security> header has a SOAP
> > > mustUnderstand="true" attribute and the implementation cannot
> > > process all sub-element and extensions, the implementation
> > > MUST return an appropriate SOAP fault. If the <wsse:Security>
> > > header does not have a mustUnderstand="true" attribute, the
> > > implementation SHOULD return a fault if it cannot process all
> > > sub-elements and extensions.
> > >
> > >
> > > (I struggled a bit with the semantics of this - one option
> > > would be to try and effectively override mustUnderstand by
> > > saying that conforming implementations MUST process or fault,
> > > independent of mustUnderstand; I changed my mind on that
> > > because SOAP listeners without Soap Message Security
> > > implementations can legally ignore <wsse:Security
> > > mustUnderstand="false"> headers, so why can't conforming
> > > implementations?)
> > >
> > >
> > > I think this says what we mean, modulo the above and the fact
> > > that the current specification isn't always clear about what
> > > it means to "process" the contents of a <wsse:Security>
> > > header. Speak up if you think I'm off track with the
> > > semantics, or if you have better wording.
> > >
> > >  - irving -
> > >
> >
> 
> 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/wss/members/leave
> _workgroup.php
> .
> 
> 
> 
> 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/wss/members/leave
> _workgroup.php.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]