RE: [ebxml-msg] Groups - Message Authorization

["Ben Malek, Hamid" <HBenMalek@us.fujitsu.com>]

The following is just the first cut of the proposal:

 

----------------------------------------------------------------------------------------

Before Section 7.10: introduce new subsection:

 

7.10 Message Authorization

 

Message authorization is defined as authorizing the processing of a message in conformance with the parameters of the P-Mode associated with this message. This includes authorizing the access to some resources such as:

-        "Consumer resources" as identified by eb:Service and eb:Action

-        message partition flow (MPF) that a Pull signal is accessing for pulling messages.

 

This is different from simply authorizing a received message for further processing by the MSH, which can be achieved by processing the main security header described earlier in Section 7. This level of authorization is more fine-grained than the one based on credentials provided in the main security (wsse) header. In other words, a message could successfully "pass" the security processing phase (see Section 4.1) and yet not be authorized to pull from a particular MPF, or to be delivered to a particular Service. In general, the main security header cannot be used to provide this level of authorization, as the WSS module has no knowledge of these ebMS resources. Also, this header will normally be removed by the WSS module when reaching the ebMS message processor.

 

This specification provides a fine-grain message authorization mechanism. It relies on a second security (wsse) header that only contains a wsse:UsernameToken profile. It may however be secured (e.g. encrypted) by the main security header.

 

This header is not intended for the main security module, but is targeted to the "ebms" actor - typically the ebMS header processor, which has knowledge of the association between these tokens and the P-Modes that governs the message processing.

 

[NOTE: conditional to finalizing the PMode model]

In the proposed PMode model (see Appendix 12) such tokens are represented as the PMode.Initiator.Authorization parameters set

(for authorizing the initiator of an MEP) and the PMode.Responder.Authorization parameters set.

 

The following example shows a PullRequest message for which authorization is required. Both security headers (here for for SOAP1.1) are present, one of them - the authorization header - targeted to the "ebms" actor. [may need to develop on the use of roles/actors] This signal can only pull messages on the MPF http://msh.example.com/mpf123  once its credentials match the authorization parameters of at least one P-Mode associated with pulling messages on this MPF.

 

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"

    xmlns:xsd="http://www.w3c.org/2001/XMLSchema"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

 

<soap:Header xmlns:eb="http://www.oasis-open.org/committees/ebxmlmsg/schema/msg-header-3_0.xsd">

 

  <eb:Messaging eb:version="3.0" S11:mustUnderstand="1">

    <eb:SignalMessage>

      <eb:MessageInfo>

        <eb:Timestamp>2000-07-25T12:19:05</eb:Timestamp>

        <eb:MessageId>UUID-2@initiator.example.com</eb:MessageId>

      </eb:MessageInfo>

      <eb:PullRequest eb:mpf="http://msh.example.com/mpf123" />

    </eb:SignalMessage>

  </eb:Messaging>

 

  <wsse:Security S11:mustUnderstand="1">

     ... <!-- main security header -->

  </wsse:Security>

 

  <wsse:Security S11:mustUnderstand="1" actor="ebms"><!-- authorization security header (non encrypted) -->

    <wsse:UsernameToken wsu:Id="ebms-1234">

      <wsse:Username>acme</wsse:Username>

      <wsse:Password Type="...">xyz123</wsse:Password>

      <wsu:Created> ... </wsu:Created>

    </wsse:UsernameToken>

  </wsse:Security>

 

</soap:Header>

<soap:Body/>

</soap:Envelope>

 

 

Permission to use a P-Mode for processing a received message is granted or denied at the time the P-Mode authorization parameters are compared with the credentials in the message.

 

In 7.10.2 (now 7.11.2) "Authorization" subsection: reword as:

The processing of a PullRequest signal received by a Sending MSH is authorized based on either one or both:

(a) signature validation by the Security (WSS) module,

(b) a UsernameToken profile communicated via a separate WSS security header (see 7.10).

 

Feature (a) alone is not sufficient to prevent unauthorized usage of an MPF. With (b), a Sending MSH can verify that only Pull signals with the right UsernameToken profile can pull from an MPF.

 

Hamid/Jacques.