[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] WSS questions
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.
-----Original Message-----
From: Ric Emery [mailto:remery@cyclonecommerce.com]
Sent: Thursday, March 02, 2006 3:56 PM
To: Kiwasa
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] WSS questions
I am not sure. The Pull security examples came from Jacques if I remember correctly. Looking at the BinaryToken Option of the
PullRequest, the SecurityTokenReference is child element of the SignalMessage is not necessary. The identity of the sender can be
achieved looking only at the Security element and the Signature contained within. This might lead me to wonder if you are correct in stating that the SecurityTokenReference shown below is also unnecessary.
Ric
iwasa wrote:
> Here are some questions I got from
> users implementing ebMS3.0 CD.
> I appreciate if someone can answer
> the followings:
>
> 1) 6.2.1.1 Username / Password Option
> The example is including both <wsse:UsernameToken>
> and <SecurityTokenReference>.
> --
> <wsse:Security xmlns:wsse="…" xmlns:wsu="…">
> <wsse:UsernameToken wsu:Id="#TokenID">
> <wsse:Username>hamid</wsse:Username>
> <wsse:Password>SomePassword</wsse:Password>
> </wsse:UsernameToken>
> </wsse:Security>
> <eb:Messaging eb:version="3.0" SOAP:mustUnderstand="1" >
> <eb:SignalMessage>
> <wsse:SecurityTokenReference>
> <wsse:Reference URI="#TokenID" />
> </wsse:SecurityTokenReference>
> <eb:MessageInfo> …. </eb:MessageInfo>
> <eb:PullRequest eb:forMbox="…" />
> </eb: SignalMessage>
> </eb:Messaging>
> --
>
> Can we omit <SecurityTokenReference> with
> this example, even if we use ID and Password?
> Or is it mandatory to include the element?
> It seems redundancy.
> *If both of them should be included, the spec
> should mention it. If not, it should be mentioned
> also.
>
> 2) The above example is for SignalMessage.
> How about for UserMessage? I assume the
> answer is the same with the above.
>
> Thanks,
>
> Iwasa
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]