Authorized pulling: 2 solutions

[Jacques Durand <JDurand@us.fujitsu.com>]

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. "