MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] WSS questions
Title: Re: [ebxml-msg] WSS questions
This is an old email that some SMTP Gateway decided to resurrect. It is a dead issue. Just ignore it.
Thanks,
Ric
On 3/6/06 3:12 PM, "Ric Emery" <remery@cyclonecommerce.com> wrote:
Wow. Unless I am missing something, the spec is not clear on the use of the SecurityTokenReference within the eb:SignalMessage.
Have you attempted to implement any code using the model described? To build an actual Signal request I would think that the WSS Module and the MSH must be tightly coupled. Somehow the SecurityTokenReference is going to need to be added to the eb:SignalMessage with the correct wsse:Reference URI. How does the wsse:Reference URI get set correctly within the eb:SignalMessage?
Hamid Ben Malek wrote:
Iwasa,
The child element eb:SignalMessage/wsse:SecurityTokenReference is optional (meaning that SecurityTokenReference is not mandatory to be within the eb:SignalMessage even if you have a username/passord token declared in a wss:Security element). As Ric said, the identity of the sender can be achieved by looking at the contents of wss:Security element. However, the problem that was behind the design of SecurityTokenReference as a sub-element of eb:SignalMessage is the following:
· We wanted to provide an MSH with the possiblity of authentication/authorization when it receives a PullRequest signal. This means exaclty “who has the right to pull user messages from this mbxo (or pipeId, or bucket, or call it whatever you want)?”. We don’t want any MSH receiver to be able to pull user messages by just sending PullRequest signals. We need a way to protect the queue (or bucket) of user messages from which other MSHs can pull.
· This authentication/authorization is independent from the WSS module. It is an authentication/authorization that has a business semantic that is either at the level of the ebMS module or higher (so it is really different from the one happening at a lower level at the WSS module). This also has an impact in terms of deployment. The recommended module stack for a receiver MSH is that the WSS module is the first one to receive a message (be it a signal or a user message), then after processing it, the message goes to the next level which is the WS-Reliability module, and then afterwords comes the next level which is the ebMS module. In theory, when a message reaches the ebMS module, all security headers are removed from the message (this is just the normal SOAP processing model). So, the ebMS module is going to process a message that has no security headers anymore, and therefore, it becomes harder for the ebMS module to make his own authentication/authorization in order to determine whether a PullRequest signal for example is allowed to pull user messages. Successfully passing the WSS module does not mean that a given PullRequest signal has the right to pull user messages. That is why the optional element SecurityTokenReference is a child of eb:SignalMessage. Now, you are going to tell me that you may end up with SecurityTokenReference inside the eb:SignalMessage but at the same time there are no WSS security headers in the SOAP message, and therefore the ebMS module won’t be able anyway to do his authentication/authorization. Right J. This is a tricky point because in the Core spec we are not dealing with actors (roles) yet. One solution to this problem is to use SOAP actors (SOAP roles) and put the referenced security token element (which is the username/password token) in a separate wss:Security element with a special actor or role attribute so that the first WSS module won’t remove it from the headers.
· Another factor that was behind the design is that this authentication/authorization for the PullRequest was intended for MSHs that do not implement WSS (in this case there is no WSS module in the stack that would remove WSS headers). In other words, we wanted to provide those MSHs that do not implement WSS but still would like to be able to protect the bucket from which user messages are pulled, with a simple mechanism that is close enough to WSS without requiring all the apparatus of WSS. This was a requirement that came from Japan: some SMEs, they said, do not have the luxuary of implementing WSS and they want to use ebMS-3 and be able to do authentication/authorization on PullRequest signals in order to protect the bucket of user messages that the pulling is using.
In conclusion, if your MSH implements WSS (so you have a WSS module in your stack, usually placed as the first one to receive messages), then you don’t need and don’t use the child element eb:SignalMessage/wsse:SecurityTokenReference. The only drawback that you would get is the fact that your business semantics attached to the authorization/authentication for PullRequest signals woud be hardwired in the first module (the WSS module). If your MSH does not implement WSS and you need to protect your mboxes (buckets) from non-authorized PullRequests, than you give the username/password to your partner (out of band) and let your partner include this username/password in a wss:Security-like fashion and a SecurityTokenReference child elment within eb:SignalMessage element.
Hamid.