Two solutions to choose from for supporting
authorized pulling:
Summary of solution 1: only supports ebMS-level
authorization of pulling from pipes
(authorization data is in PullRequest signals only)
Summary of solution 2: The ebMS-level authorization
element in the protocol
is under eb:MessageInfo and is usable by all ebMS
messages: user messages as well.
May be used to authorize usage of pipes by user
messages, but also other header resources (Service & Action, COnversationId,
etc.) based on an agreement.
-Jacques & Hamid
---------------- Solution 1 ------------------
In 6.9.2:
replace :
"The processing of a PullRequest
signal received by a Sending MSH is authorized based on internal
information that the Sending MSH maintains, that
associates a list of endpoint information about preauthorized
Receiving MSHs, with the pipes on which these are allowed
to initiate message transfer."
with:
"Authorizing PullRequest signals for accessing pipes
to pull from, involves ebMS header semantics and is not supported
by most security module implementations. In particular, in
an MSH architecture based on cooperation between SOAP nodes, there is generally
no possibility for communicating authorization data to the ebMS header
processing component after the security header block has been removed from the
SOAP envelope. In order to allow the ebMS header processing component to
authorize the use of pipes for pulling, pipes definitions in the P-Mode
(P-Mode.messagePipes) may be associated with access codes, subject to agreement
between parties. In such cases, the optional attribute:
eb:PullRequest/@eb:accessCode MUST be used, and
PullRequest signals MUST NOT be authorized to pull from a pipe if they either
(a) do contain the eb:accesscode attribute or (b) contain the eb:accesscode
attribute with a wrong value for this pipe."
In 6.10.7 Persistent Authorization (extend as
follows)
Persistent authorization MAY be provided using Web
Services Security: SAML Token Profile.
Authorization functions for user messages that are
more dependent on ebMS header content,
such as: right for a sending party to use a
particular Service/Action, right to send over
a particular message pipe, can be enforced by the
implementation of P-Modes. Indeed, once the first level of security has been
passed by a user message (authentication, confidentiality, integrity), the
authorized patterns of ebMS header content may all be described in the P-Modes
set and enforced by the processing component for ebMS headers.
A ProcessingModeMismatch error must be raised in
case a received message does not match
any preconfigured P-Mode.
---------------- Solution 2 ------------------
In 6.9.2:
same as Solution 1 except :
replace:
"In such cases, the optional attribute: eb:PullRequest/@eb:accessCode
MUST be used, and PullRequest signals MUST NOT be authorized to pull from a
pipe if they either (a) do contain the @eb:accesscode attribute or (b)
contain the @eb:accesscode attribute with a wrong value for this pipe."
with:
"In such cases, the optional element: /eb:MessageInfo/eb:accessCode
MUST be used, and PullRequest signals MUST NOT be authorized to pull from a
pipe if they either (a) do contain the eb:accessCode element or (b)
contain this element but with a wrong value for this pipe."
In 6.10.7 Persistent Authorization (extend as
follows)
Replace:
"... can be enforced by the implementation of
P-Modes. Indeed, once the first level of security has been passed by a user
message (authentication, confidentiality, integrity), the authorized patterns of
ebMS header content may all be described in the P-Modes set and enforced by the
processing component for ebMS headers."
With:
"... can be enforced by the association of
P-Modes or subset of these, with access codes
used as password. In such cases, once the first
level of security has been
passed by a user message (authentication,
confidentiality, integrity), the message ebMS headers MUST NOT be processed
further and delivered if its /eb:MessageInfo/eb:accessCode
value does not match the access code associated with the
P-Mode or subset of it, that was intended to govern the processing of this
message. "