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