[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Authenticatio/Authorization on "pull" message over a MPF.
Dale, Ric, everybody, Here is in 9 lines my comments on this: First,
there are more than a dozen solutions out there to the problem we are trying to
tackle and I simply think that no solution can stand out among the crowd and
claim that it deserve to be standardized. If we have to pick one solution among
the possible ones, the only one that deserves to be standardized is a solution
that is based solely on SOAP headers such that these SOAP headers remain in the
message and are visible to the ebMS module even after the WSS module processed
them. Second, when the spec does not say anything about the authentication, the
default interpretation is that all the possible solutions out there are all possible
and are not prohibited by the spec. Third, HTTP basic auth does not have
anything special that makes it worth of being standardized. WSS Username token
is a lot better than HTTP auth as it has SOAP headers; however this is exactly
the solution that we first crafted in the spec and later it was removed because
it turned out to be a stupid solution. So now we are back to the beginning. If
we are going to standardize WSS Username Token as the way of doing things, this
still needs to be specified in details. Two alternatives are possible: (a) the
token resides inside the ebMS headers and is generated and processed only by
ebMS modules (in this case there is no <wss:Security> element wrapper,
only a reuse of WSS syntax and this is equivalent to the eb:AccessCode solution).
(b) the token resides in an external <wss:Security role=”ebms”>
element that contains only this token and nothing else and that the WSS module
is instructed to not touch that security element (because role attribute is “ebms”). Hamid. From: Ric Emery
[mailto:remery@us.axway.com] I think mandating HTTP basic auth
and WSS Username token profile is a reasonable compromise solution. For many
ebMS MSHs it should be very easy to support both solutions. For other
distributed ebMS solutions, I suspect as you do, that something could be
kludged up. For the username token profile, if the MSH Vendor does not have an
easy way to pass authentication data from their WSS module to the ebMS module,
I can imagine the WSS module being bypassed. The WSS username token profile
headers could be dealt with directly in the ebMS module. The username token
profile is simple enough that relying on a third party library should not be
required. The problem as I understand it is
that we want to make certain at the “server” side that a request
for a message on a MPF is only honored if the requesting agent is authorized to
access that particular MPF. That is, having the request be authenticated as
from some party (data origin authentication) is insufficient. An authorization
“rule” needs be be consulted to check whether a request from that
authenticated identity is authorized to pull a message on the MPF. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]