OASIS ebXML Messaging Services TC

Some comments on Pull,  MPC,  authorization   In ebMS 3.0 there are two situations where messages can be pulled:   1)   As defined in the ebMS 3.0 Core specification  from a sending MSH, for messages where the PMode specifies a Pull transport channel binding.    The sending MSH is configured using deployed processing modes.   2)   As defined in the ebMS 3.0 Part 2 advanced features,  for intermediaries acting in forwarding roles that can (and are configured to) store messages,  leaving the initiative for a next hop transmission to the next MSH.   Configuration of these intermediaries does not require a full PMode set.   In a general Web server context,  some Web servers use HTTP authentication to map an HTTP get request to a dynamically selected resource.   E.g. a GET request to http://example.com/users could map Alice to her home directory on that server and Bob to his.  Section 3.4.1 of the Core Spec defines the MPC concept as a way of partitioning message sets in specific sets with named identifiers. It does not mention the concept of associating messages within an MPC with a particular user.    In fact, it specifically suggests any filtering of messaging on criteria other than MPC identifier is out of scope for the Core Specification (we slightly enhanced this in Part 2).  An ebMS 3.0 Pull request is posted to a particular URI_1 and contains a reference to an MPC URI_2.    Here, URI_1 is like http://example.com/users  and the request specifies a particular MPC URI_2 to access.  If there were a dynamic resource selection based on requesting user,  then it would not be necessary to specify a particular MPC in the request. The server could assign messages to users and map pull requests to user-based partitions.   There is no mentioning of mapping any additional mapping to a subset of messages in MPC URI_2 in this section.   Chapter 7.10 of the Core Specification states: Since any resource a message may claim access to is identified by the P-Mode associated with the message, this is equivalent to authorizing the association of the message with the P-Mode   But if two PModes use the same MPC value and both have a Pull transport channel binding, then a Pull request can be ambiguous between two PModes. It also states:   This Pull signal can effect message delivery from MPC http://msh.example.com/mpc123 only if its credentials match the authorization parameters of at least one P-Mode associated with pulling messages on this MPC   One approach apparently taken in one implementation is to classify messages within an MPC with the authorization username/password (or other token) specified in the PMode they were submitted with, and map requests to subsets based on username.    This solution is problematic in the multi-hop situation,  intermediaries may not know which PMode a message was assigned to (the pmode message attribute is optional) by the original sender and there is no association of a message with any user specified in the original PMode.   If messages are forwarded from MSH1 to intermediary MSH2,  then the further partitioning in user subsets is lost. Only the MPC identifier is part of the message and as such carried along with the message in the I-Cloud.     It would much simpler for a product to have support two separate configurations:   PModes (which may specify pull and name a particular MPC)  and pull MPCs  for a particular URI (which specify MPC identifier and authorization information).  Since the Core Spec defines the authorization information as PMode parameters, the authorization parameters for distinct PModes with the same MPC and a pull channel binding should then be the same.   Pim    

Pim:   > But if two PModes use the same MPC value and both have a Pull transport channel binding, > then a Pull request can be ambiguous between two PModes   In multi-hop intermediaries, we described the use of “sub-channels” as a way to authorize differently the pulling from different Receivers against the same MPC. So when the MSH pulled from is an “intermediary”, this allows to disambiguate the Pull requests. This assumes the Intermediary is configured so that it can authorize Pull requests selectively (based on contained credentials) and associate each with the appropriate sub-channel.   In AS4, this capability is extended to the Sending MSH (no need to be an “intermediary” as in multi-hop) as an “additional feature”. Can you be more specific as to what is still amiss here for your use case? (of course, this so far is only described in Part 2 and AS4 profile, not in the core spec.)   Thanks, -jacques   From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk Sent: Tuesday, July 30, 2013 5:13 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Pull, MPC, authorization   Some comments on Pull,  MPC,  authorization   In ebMS 3.0 there are two situations where messages can be pulled:   1)   As defined in the ebMS 3.0 Core specification  from a sending MSH, for messages where the PMode specifies a "Pull" transport channel binding.    The sending MSH is configured using deployed processing modes.   2)   As defined in the ebMS 3.0 Part 2 advanced features,  for intermediaries acting in forwarding roles that can (and are configured to) store messages,  leaving the initiative for a next hop transmission to the next MSH.   Configuration of these intermediaries does not require a full PMode set.   In a general Web server context,  some Web servers use HTTP authentication to map an HTTP get request to a dynamically selected resource.   E.g. a GET request to http://example.com/users could map Alice to her home directory on that server and Bob to his.  Section 3.4.1 of the Core Spec defines the MPC concept as a way of partitioning message sets in specific sets with named identifiers. It does not mention the concept of associating messages within an MPC with a particular user.    In fact, it specifically suggests any filtering of messaging on criteria other than MPC identifier is out of scope for the Core Specification (we slightly enhanced this in Part 2).  An ebMS 3.0 Pull request is posted to a particular URI_1 and contains a reference to an MPC URI_2.    Here, URI_1 is like http://example.com/users  and the request specifies a particular MPC URI_2 to access.  If there were a dynamic resource selection based on requesting user,  then it would not be necessary to specify a particular MPC in the request. The server could assign messages to users and map pull requests to user-based partitions.   There is no mentioning of mapping any additional mapping to a subset of messages in MPC URI_2 in this section.   Chapter 7.10 of the Core Specification states: " Since any resource a message may claim access to is identified by the P-Mode associated with the message, this is equivalent to authorizing the association of the message with the P-Mode "   But if two PModes use the same MPC value and both have a Pull transport channel binding, then a Pull request can be ambiguous between two PModes. It also states:   " This Pull signal can effect message delivery from MPC " http://msh.example.com/mpc123 " only if its credentials match the authorization parameters of at least one P-Mode associated with pulling messages on this MPC "   One approach apparently taken in one implementation is to classify messages within an MPC with the authorization username/password (or other token) specified in the PMode they were submitted with, and map requests to subsets based on username.    This solution is problematic in the multi-hop situation,  intermediaries may not know which PMode a message was assigned to (the pmode message attribute is optional) by the original sender and there is no association of a message with any "user" specified in the original PMode.   If messages are forwarded from MSH1 to intermediary MSH2,  then the further partitioning in user subsets is lost. Only the MPC identifier is part of the message and as such carried along with the message in the I-Cloud.     It would much simpler for a product to have support two separate configurations:   PModes (which may specify "pull" and name a particular MPC)  and pull MPCs  for a particular URI (which specify MPC identifier and authorization information).  Since the Core Spec defines the authorization information as PMode parameters, the authorization parameters for distinct PModes with the same MPC and a "pull" channel binding should then be the same.   Pim    

Hello Jacques,   Sub-channels and the Part 2 selective pulling are useful features.   But the question is about correct interpretation of behaviour of an MSH implementing the Core Spec pulling.   Also see https://tools.oasis-open.org/issues/browse/EBXMLMSG-20 .   It seems at least one product is implementing a kind of sub-channels by sub-partitioning messages within an MPC based on the user in the user token.   Chapters 3 and 7 of the Core Spec do not seem to be fully aligned on this, with chapter 3 not mentioning it at all.   If we want basic Pull functionality to be simple and implementable using simple mechanisms like FIFO queues,  any pull client authorized to pull from an MPC should be authorized to pull all messages in that MPC.     It would be great if we can discuss this at an upcoming TC call.   Pim From: Jacques Durand [mailto:JDurand@us.fujitsu.com] Sent: 03 August 2013 00:03 To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Pull, MPC, authorization Pim:   > But if two PModes use the same MPC value and both have a Pull transport channel binding, > then a Pull request can be ambiguous between two PModes   In multi-hop intermediaries, we described the use of “sub-channels” as a way to authorize differently the pulling from different Receivers against the same MPC. So when the MSH pulled from is an “intermediary”, this allows to disambiguate the Pull requests. This assumes the Intermediary is configured so that it can authorize Pull requests selectively (based on contained credentials) and associate each with the appropriate sub-channel.   In AS4, this capability is extended to the Sending MSH (no need to be an “intermediary” as in multi-hop) as an “additional feature”. Can you be more specific as to what is still amiss here for your use case? (of course, this so far is only described in Part 2 and AS4 profile, not in the core spec.)   Thanks, -jacques   From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk Sent: Tuesday, July 30, 2013 5:13 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Pull, MPC, authorization   Some comments on Pull,  MPC,  authorization   In ebMS 3.0 there are two situations where messages can be pulled:   1)   As defined in the ebMS 3.0 Core specification  from a sending MSH, for messages where the PMode specifies a Pull transport channel binding.    The sending MSH is configured using deployed processing modes.   2)   As defined in the ebMS 3.0 Part 2 advanced features,  for intermediaries acting in forwarding roles that can (and are configured to) store messages,  leaving the initiative for a next hop transmission to the next MSH.   Configuration of these intermediaries does not require a full PMode set.   In a general Web server context,  some Web servers use HTTP authentication to map an HTTP get request to a dynamically selected resource.   E.g. a GET request to http://example.com/users could map Alice to her home directory on that server and Bob to his.  Section 3.4.1 of the Core Spec defines the MPC concept as a way of partitioning message sets in specific sets with named identifiers. It does not mention the concept of associating messages within an MPC with a particular user.    In fact, it specifically suggests any filtering of messaging on criteria other than MPC identifier is out of scope for the Core Specification (we slightly enhanced this in Part 2).  An ebMS 3.0 Pull request is posted to a particular URI_1 and contains a reference to an MPC URI_2.    Here, URI_1 is like http://example.com/users  and the request specifies a particular MPC URI_2 to access.  If there were a dynamic resource selection based on requesting user,  then it would not be necessary to specify a particular MPC in the request. The server could assign messages to users and map pull requests to user-based partitions.   There is no mentioning of mapping any additional mapping to a subset of messages in MPC URI_2 in this section.   Chapter 7.10 of the Core Specification states: Since any resource a message may claim access to is identified by the P-Mode associated with the message, this is equivalent to authorizing the association of the message with the P-Mode   But if two PModes use the same MPC value and both have a Pull transport channel binding, then a Pull request can be ambiguous between two PModes. It also states:   This Pull signal can effect message delivery from MPC http://msh.example.com/mpc123 only if its credentials match the authorization parameters of at least one P-Mode associated with pulling messages on this MPC   One approach apparently taken in one implementation is to classify messages within an MPC with the authorization username/password (or other token) specified in the PMode they were submitted with, and map requests to subsets based on username.    This solution is problematic in the multi-hop situation,  intermediaries may not know which PMode a message was assigned to (the pmode message attribute is optional) by the original sender and there is no association of a message with any user specified in the original PMode.   If messages are forwarded from MSH1 to intermediary MSH2,  then the further partitioning in user subsets is lost. Only the MPC identifier is part of the message and as such carried along with the message in the I-Cloud.     It would much simpler for a product to have support two separate configurations:   PModes (which may specify pull and name a particular MPC)  and pull MPCs  for a particular URI (which specify MPC identifier and authorization information).  Since the Core Spec defines the authorization information as PMode parameters, the authorization parameters for distinct PModes with the same MPC and a pull channel binding should then be the same.   Pim    

Hi Pim I've been following this thread with some interest and was wondering if this was triggered by the conversation on the list between Rong and myself on this ? Some of my thoughts and views on pull authorisation from a practical point of view and within the scope of the question (ie. interpretation of behavior of an MSH implementing Core Spec pulling' for the AS4 profile are as follows. Sub-channels are an optional feature for the AS4 profile particularly for use in multi-hop cases and my view being that these need only be considered in cases where multi-hop is a requirement. There are use cases for 'broadcasting' the same message to multiple pulling partners eg. RFQs. Authorisation, either by UT or by Signature, on pulling from MPCs is a practical requirement in that pulling partners should not be able to pull messages (and in the process delete these from an MPC) if the message is not intended for them. Configuring multiple separate P-Modes, each with a separate MPC, for cases where a large number of pulling partners exists is not practical. Chapter 3 of the core spec does not mention the ability of partitioning messages on a single MPC based on the "user" in the user token as per your email below. Chapter 3 does state 'organizing the inflow of messages on receiving side, so that each flow can be consumed in a distinct way, yet without having to filter messages based on various header elements or payload content', but does inflow, and organisation of received messages, not indicate the context of the receiving (pulling) msh once pulled messages have been received ? Chapter 3 also states the following ... 'It does not prescribe a particular way to implement MPCs or [how] to use them.' and 'There is no specific quality of service associated with an MPC. Security and reliability remain associated with parties or with MSHs, in a way that is orthogonal to MPCs; although an implementation is free to associate QoS with MPCs as long as this conforms to an agreement between parties." … so in reading Chapter 3, and the AS4 profile, I see nothing that prohibits or recommends against partitioning messages within an MPC by user … Also pull requests without credentials (UTs and/or unsigned pull requests) or with shared UTs should be able to pull messages for basic pull functionality as you mention below. For the question asked in EBXMLMSG-20 I see the following possibilities a - return P1. b - return empty MPC (EBMS:0006) if only P2 messages are available. I don't think that (a) goes against the notion of 'simple dequeue' surely… ? On 04 Aug 2013, at 11:58 , Pim van der Eijk <pvde@sonnenglanz.net> wrote: > Hello Jacques, > > Sub-channels and the Part 2 selective pulling are useful features. But the question is about correct interpretation of behaviour of an MSH implementing the Core Spec pulling. Also see https://tools.oasis-open.org/issues/browse/EBXMLMSG-20 . It seems at least one product is implementing a kind of sub-channels by sub-partitioning messages within an MPC based on the "user" in the user token. Chapters 3 and 7 of the Core Spec do not seem to be fully aligned on this, with chapter 3 not mentioning it at all. > > If we want basic Pull functionality to be simple and implementable using simple mechanisms like FIFO queues, any pull client authorized to pull from an MPC should be authorized to pull all messages in that MPC. > > It would be great if we can discuss this at an upcoming TC call. > > Pim -- Regards Theo

Hi Theo, Yes partly triggered by your emails and also because we touched on it in a previous call (but postponed discussion). My goal was to provide some context for discussion at an upcoming call. By "simple dequeue", I mean: the MPC pull service provider should only have to check whether the puller is authorized to pull the MPC. Not to also have to sub-partition messages on the MPC based on "user" and to return different messages depending on who pulls rather than e.g. the first or an arbitrary one. But perhaps this can be viewed as an implementation choice (for the pull provider), as it only constrains configurations and does not affect interoperability. Pim
Original Message----- From: Theo Kramer [ mailto:theo@flame.co.za ] Sent: 05 August 2013 16:46 To: Pim van der Eijk Cc: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Pull, MPC, authorization Hi Pim I've been following this thread with some interest and was wondering if this was triggered by the conversation on the list between Rong and myself on this ? Some of my thoughts and views on pull authorisation from a practical point of view and within the scope of the question (ie. interpretation of behavior of an MSH implementing Core Spec pulling' for the AS4 profile are as follows. Sub-channels are an optional feature for the AS4 profile particularly for use in multi-hop cases and my view being that these need only be considered in cases where multi-hop is a requirement. There are use cases for 'broadcasting' the same message to multiple pulling partners eg. RFQs. Authorisation, either by UT or by Signature, on pulling from MPCs is a practical requirement in that pulling partners should not be able to pull messages (and in the process delete these from an MPC) if the message is not intended for them. Configuring multiple separate P-Modes, each with a separate MPC, for cases where a large number of pulling partners exists is not practical. Chapter 3 of the core spec does not mention the ability of partitioning messages on a single MPC based on the "user" in the user token as per your email below. Chapter 3 does state 'organizing the inflow of messages on receiving side, so that each flow can be consumed in a distinct way, yet without having to filter messages based on various header elements or payload content', but does inflow, and organisation of received messages, not indicate the context of the receiving (pulling) msh once pulled messages have been received ? Chapter 3 also states the following ... 'It does not prescribe a particular way to implement MPCs or [how] to use them.' and 'There is no specific quality of service associated with an MPC. Security and reliability remain associated with parties or with MSHs, in a way that is orthogonal to MPCs; although an implementation is free to associate QoS with MPCs as long as this conforms to an agreement between parties." . so in reading Chapter 3, and the AS4 profile, I see nothing that prohibits or recommends against partitioning messages within an MPC by user . Also pull requests without credentials (UTs and/or unsigned pull requests) or with shared UTs should be able to pull messages for basic pull functionality as you mention below. For the question asked in EBXMLMSG-20 I see the following possibilities a - return P1. b - return empty MPC (EBMS:0006) if only P2 messages are available. I don't think that (a) goes against the notion of 'simple dequeue' surely. ? On 04 Aug 2013, at 11:58 , Pim van der Eijk <pvde@sonnenglanz.net> wrote: > Hello Jacques, > > Sub-channels and the Part 2 selective pulling are useful features. But the question is about correct interpretation of behaviour of an MSH implementing the Core Spec pulling. Also see https://tools.oasis-open.org/issues/browse/EBXMLMSG-20 . It seems at least one product is implementing a kind of sub-channels by sub-partitioning messages within an MPC based on the "user" in the user token. Chapters 3 and 7 of the Core Spec do not seem to be fully aligned on this, with chapter 3 not mentioning it at all. > > If we want basic Pull functionality to be simple and implementable using simple mechanisms like FIFO queues, any pull client authorized to pull from an MPC should be authorized to pull all messages in that MPC. > > It would be great if we can discuss this at an upcoming TC call. > > Pim -- Regards Theo