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:HBenMalek@us.fujitsu.com]
Sent: Tuesday, November 07, 2006
12:44 PM
To:
Ric Emery; Dale Moberg;
ebxml-msg@lists.oasis-open.org
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]
Sent: Friday, November 03, 2006 3:01 PM
To: Dale Moberg;
ebxml-msg@lists.oasis-open.org
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" <dmoberg@us.axway.com>
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.