[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] WSS questions
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----- 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]