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:]
Sent: 03 August 2013
00:03
To: Pim van der Eijk;
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:
[mailto:] On
Behalf Of Pim van der Eijk
Sent: Tuesday, July 30, 2013 5:13
AM
To:
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
