Re: [ebxml-msg] Authenticatio/Authorization on "pull" messageover a MPF.

[Ric Emery <remery@us.axway.com>]

Title: 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.