Title: Re: [ebxml-msg] Authenticatio/Authorization on "pull" message
over a MPF.
So in spite of the lack of enthusiasm from
Hamid on the topic, note that he leaves us with (a) and (b) to discuss below at
tomorrows’ meeting…
Regardless of the authorization means, the
ebms semantics of a username/password will need be added. Something like:
- A P-Mode has two “UserPass” optional
parameters: PMode.Initiator.UserPass, PMode.Responder.UserPass, each one holding
a concatenation of userId+”:”+password.
- When a received message matches a PMode with
one of the 2 “UserPass” parameters that qualifies its origin and
that has a value, the message can only be processed according to this PMode if
the username and password provided by the message match this UserPass PMode parameter.
In case HTTP basic auth is still an option:
needs a minimum of profiling in an appendix:
- preemptive sending of authorization
header probably required.
- realm of resource to authorize: the
entire MSH ( the actual authorization will be performed by the ebms module, as
described above)
-Jacques
From: Ben Malek, Hamid [mailto:]
Sent: Tuesday, November 07, 2006
12:44 PM
To: Ric
Emery; Dale Moberg;
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:]
Sent: Friday, November 03, 2006
3:01 PM
To: Dale Moberg;
Subject: Re: [ebxml-msg]
Authenticatio/Authorization on "pull" message over a MPF.
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.
-ric
On 11/1/06 6:36 PM, "Dale Moberg" <> wrote:
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.
That said, an additional constraint on solutions to the problem is that the
requesting party is possibly “PKI-challenged” so that strong
authentication approaches (involving signing of something) cannot be required.
Another constraint is that the desired solution must be implemented across all
(!) conformance profiles. An additional desired feature is that the solution be
independent of transfer protocol. Final design features want the solution to be
cleanly deployable across architectures involving many SOAP intermediaries in
the path.
My proposal is that both HTTP basic authentication and WSS Username token
profile authentication be mandated. HTTP basic auth because it is pervasive
(though transfer protocol dependent) and WSS Username because it is transfer
protocol. Both authentication approaches may have some risk when used without
TLS. What we say about MPF processing is, however, that it must check that the identity
available through some supported means of authentication be eligible to pull
messages from the MPF. Other mechanisms of authentication can be agreed upon
(via a PMode? or via a CPA) but in any case, the MPF supporting service
must do the check that identity is authorized to use resource MPF.
We should also run this proposal (or its refinement reached by this group) by
the end user audiences we have already consulted, and verify with them that the
approach meets their requirements.
Dale Moberg
As to the deployability across any arbitrary SOAP path, with any arbitrary
targeting of headers, and with unknown header augmentations and removals, I
suspect something can be kludged up to work. (Check the HTTP basic auth, add an
ad hoc authentication header, email it to the next hop, etc, etc, until
something that needs to check the MPF and identity map pulls off the identity
header, and does its check). However, I am not interested in trying to spec out
all the possible permutations personally.
