RE: [ebxml-msg] Authorized pulling: 2 solutions

Title: RE: [ebxml-msg] Authorized pulling: 2 solutions

Pete:

<JD>

-----Original Message-----

From: Pete Wenzel [mailto:] 

Sent: Wednesday, March 15, 2006 10:52 AM

To: Jacques Durand

Cc: 

Subject: Re: [ebxml-msg] Authorized pulling: 2 solutions

(Comments inline.)

Thus spoke Jacques Durand () on Thu, Mar 09, 2006 at 06:04:16PM -0800:

> ...

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

But we have agreed that SOAP intermediary node scenarios are

explicitly out of scope for this release.  Can we avoid adding more

"gunk" in order to enable it, unless it is integrated with the rest of

the security infrastructure?  If you're going to allow a non-MSH SOAP

node to remove a Security element that is required by the MSH, for

example, then it should also be responsible for ensuring that the

authenticated identity context is propagated to (or remains accessible

to) the ebMS processor in some form, not add yet another completely

different method of user authentication.

<JD> No MSH intermediary here: we only consider the case where the MSH itself is built based on a collaboration of (local) SOAP nodes that function according to the SOAP processing model. A security node (WSS headers) will not be able to authorize the use of certain values in the ebMS header.

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

The @fromPipe is already a value that must be agreed to (out-of-band)

between parties.  Requiring agreement to one more string doesn't seem

to add anything useful.  If there really is a requirement for this

type of weak shared-secret authentication, one could simply agree that

the @fromPipe will contain enough secret bits to serve the purpose.

<JD> indeed in this approach, the authorization relies on confidentiality of the pipe name (or more generally of the P-mode, as agreement between parties. Although that scenario is possible, we were trying to cover cases that do not rely on P-mode confidentiality.

For those who require a stronger solution, we have already allowed a

WSS SecurityTokenReference in the SignalMessage (Section 5.2.2).  Note

that such a reference need not point to a SecurityToken that exists in

a transient Security header (expected to be removed by an

intermediary, in your scenario); it could contain an <Embedded> token,

or refer to a location elsewhere that is accessible to the MSH at the

time of Messaging header processing.

<JD> SecurityTokenReference can in fact play the role of "accesscode" element, when used in the way above. So we could use it instead of accessCode.

A separate but related issue:

Why must the PipeId element appear in pulled messages?  When the

Pulling MSH requests messages, the pipe being accessed is known.  I'd

prefer to keep message content independent of the transfer mode, if

possible.

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

> ...

-- 

Pete Wenzel <>

Sun Microsystems SOA & Business Integration

Standards & Product Strategy

+1 (626)471-6311, Sun x61311, US-Pacific TZ