[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 96.1 - Proposal For Vote
I don't understand the relevance of the question. One can readily imagine many scenarios with BPEL where an income message is rejected due to authorization issues. So? Yaron Satish Thatte wrote: > Your proposal says: > > Add for use on receive/pick/onEvent the 'filterOnPartnerRole' attribute. > This specifies that any message accepted by the receive/pick/onEvent > activity must be sent from the partner identified by the EPR in the > partnerRole. > > The authorization angle here is different from an ordinary receive. The > filter is reasonably INTERPRETED AS an authorization check, thus adding > an authorization feature to BPEL. This is maybe not what you had in > mind but then you have to explain what the scenario is where anything > gets rejected but not as an authorization failure. > > Satish > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Thursday, March 31, 2005 1:54 PM > To: Satish Thatte > Cc: wsbpeltc > Subject: Re: [wsbpel] Issue 96.1 - Proposal For Vote > > The behavior in the proposal takes advantage of a feature provided by > WS-Addressing - a standard I think we can agree is 'in progress': the > ability to identify source endpoints. For example, two communicating > entities can agree that their messages will always contain source > endpoint information (e.g. the from header). This then provides the > basis for filtering incoming messages based on the partnerRole EPR. > > The obvious security/authorization issues this raises apply to all > RECEIVE/PICK/etc. activities in BPEL so 96.1 is not introducing any new > concerns. For example, any time a message is received we must assume > some sort of authorization process is in place that could cause a > message to be filtered out and treated as an intrusion. This proposal > doesn't exacerbate that problem. > > Can you provide concrete examples of problems this issue raises that > don't already exist in the BPEL specification's messaging behavior? > > Thanks, > > Yaron > > > Satish Thatte wrote: > > I am not saying that this isn't useful. But I don't even know if the > > right way to think about this is an authorization check or simple > > filter. The difference being that in the former case a message that > > gets filtered out needs to be investigated as an intrusion. In other > > words, I have two separate problems with this proposal > > > > 1. when you get to this level of sophistication in thinking about > > engine managed behavior, there is almost always a lot more complexity > > than meets the eye, and providing something in BPEL as a partial > > solution can be misleading at best and an albatross for the real > > solution at worst. > > > > 2. it seems very risky to me (in the Pandora's box sense) to add > > "engine managed" features that someone thinks are useful without a > > compelling reason such as supporting protocol-level sessions for which > > companion standards are in progress. This is why I am not objecting to > > engine manage opaque correlation in principle if we can get the > details > > sorted out and come up with something simple and compelling. I don't > > see this specific engine managed feature as falling into the same > > category. > > > > Hope that helps. > > > > Satish > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Wednesday, March 30, 2005 11:34 AM > > To: Satish Thatte > > Cc: wsbpeltc > > Subject: Re: [wsbpel] Issue 96.1 - Proposal For Vote > > > > I'm sorry but this seems a little strange to me. The ability in BPEL > to > > say "I would like to receive a message from X" is something people > > should be forced to use proprietary extensions for? > > > > On what basis do you think this feature is so rare and unusual that > BPEL > > > > should fail to provide a portable solution for it? > > > > Thanks, > > > > Yaron > > > > Satish Thatte wrote: > > > I believe this idea belongs in a private extension not in the core > > BPEL > > > spec. There are probably many such interesting and useful ideas > that > > > will come up over time but I just can't see something like this > being > > > core to the spec at this point. > > > > > > Satish > > > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > Sent: Tuesday, March 15, 2005 1:26 PM > > > To: wsbpeltc > > > Subject: [wsbpel] Issue 96.1 - Proposal For Vote > > > > > > Issue 96.1 - filterOnPartnerRole > > > > > > Proposal: Add for use on receive/pick/onEvent the > > 'filterOnPartnerRole' > > > attribute. This specifies that any message accepted by the > > > receive/pick/onEvent activity must be sent from the partner > identified > > > by the EPR in the partnerRole. This proposal assumes that issue 194 > is > > > accepted and resolved by introducing a new uninitializedPartner > fault. > > > This proposal also introduces a canNotFilterOnPartnerRole fault for > > EPRs > > > > > > that are only useful in sending but not receiving. > > > > > > Rationale: One of the most common BPEL scenarios out there is that > > > someone receives a message from a partner and then later on wants > to > > > receive another message but only from that specific partner. The > issue > > > 139 proposal defines that the default behavior for BPEL will be > that > > the > > > > > > partnerRole value is ignored by default on receive/pick/onEvent. > This > > > attribute would allow that default behavior to be overridden and > for > > the > > > > > > partnerRole EPR to be used as a filter on incoming messages. > > > > > > Section 11.4 > > > > > > From: Note that the value of the partnerRole on the partner link is > > not > > > used when processing a receive activity, that is, there is no > > filtering > > > of incoming messages based on the partnerRole's value. > > > > > > To: The value of the filterOnPartnerRole attribute determines what > > role, > > > > > > if any, the value of the partnerRole EPR plays in a receive. If > > > filterOnPartnerRole="no" then the partnerRole EPR value is ignored > in > > > determining what messages to receive. If filterOnPartnerRole="yes" > > then > > > messages accepted by the receive MUST originate from the a partner > > whose > > > > > > EPR matches the EPR in the partnerRole. BPEL engines MUST > statically > > > check if the EPR in a partnerRole cannot be used to filter incoming > > > messages and reject any BPELs that use filterOnPartnerRole="yes" > with > > > such unsuitable EPRs. However it is not always possible to > statically > > > check for this error as partnerRole values can be dynamically > > assigned. > > > In that case if a partnerRole EPR, at runtime, contains a value > that > > > cannot be used to filter incoming messages then the > > > canNotFilterOnPartnerRole fault MUST be thrown. > > > > > > Section 13.5.1. > > > > > > From: As with <receive> the partnerRole EPR is ignored for > purposes > > of > > > determining which messages to receive and may be > initialized/updated > > as > > > a consequence of receiving a message using a binding that is able > to > > > provide EPR information about the partner. > > > > > > To: As with <receive> the partnerRole EPR is only used for > filtering > > > incoming messages if the filterOnPartnerRole attribute is set to > yes. > > > Also, the partnerRole value may be initialized/updated as a > > consequence > > > of receiving a message using a binding that is able to provide EPR > > > information about the partner. > > > > > > Add to Appendix A: > > > > > > canNotFilterOnPartnerRole - Thrown when a receive/pick/onEvent > > > specifies filterOnPartnerRole but the EPR in the partnerRole value > > > cannot be used to filter incoming messages. > > > > > > Change BNFS in 11.4 and 6.2 to: > > > From: > > > <receive partnerLink="ncname" portType="qname"? operation="ncname" > > > variable="ncname"? createInstance="yes|no"? > > > messageExchange="ncname"? filterOnPartnerRole="yes|no"? > > > standard-attributes> > > > standard-elements > > > <correlations>? > > > <correlation set="ncname" initiate="yes|no"?/>+ > > > </correlations> > > > </receive> > > > > > > Section 12.4 and 6.2: > > > <pick createInstance="yes|no"? standard-attributes> > > > standard-elements > > > <onMessage partnerLink="ncname" portType="qname"? > > > operation="ncname" variable="ncname"? > > > messageExchange="ncname"? filterOnPartnerRole="yes|no">+ > > > <correlations>? > > > <correlation set="ncname" initiate="yes|no"?/>+ > > > </correlations> > > > activity > > > </onMessage> > > > <onAlarm>* > > > ( <for expressionLanguage="anyURI"?>duration-expr</for> | > > > <until > expressionLanguage="anyURI"?>deadline-expr</until> > > )? > > > <repeatEvery > > > expressionLanguage="anyURI"?>duration-expr</repeatEvery>? > > > activity > > > </onAlarm> > > > </pick> > > > > > > Section 13.5 and 6.2: > > > <eventHandlers>? > > > <!-- there must be at least one onEvent or onAlarm handler > --> > > > <onEvent partnerLink="ncname" portType="qname"? > > > operation="ncname" messageType="qname" > > > variable="ncname" > > > (messageType="qname" | element="qname")? > > > messageExchange="ncname"? > filterOnPartnerRole="yes|no">* > > > <correlations>? > > > <correlation set="ncname" initiate="yes|no"/>+ > > > </correlations> > > > activity > > > </onEvent> > > > <onAlarm>* > > > ( <for expressionLanguage="anyURI"?>duration-expr</for> | > > > <until > expressionLanguage="anyURI"?>deadline-expr</until> > > )? > > > <repeatEvery > > > expressionLanguage="anyURI"?>duration-expr</repeatEvery>? > > > activity > > > </onAlarm> > > > </eventHandlers> > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]