[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Message Authorization
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]