Re: [ebxml-msg] Authenticatio/Authorization on "pull" message overa MPF.

[Sacha Schlegel <sacha@schlegel.li>]

Hi everyone

You probably know all this already ...

For sending an email from my email client (running on a different
network than my email server which is accessible in the public Internet
network) I use SMTP (over TLS) with SASL for authentication. SASL is RFC
2554 [1].

For receiving email I am using IMAP4rev1 (over SSL) where I also have
authentication enabled (currently username password). With the username
I only get to the email message store for that user. In the postfix
email server I use this translates to a directory which holds all the
emails in a "MailDir" structure.

These may be related working standards which could be used for ebMS (for
the pull part). But maybe you have to stay in the WS* domain ... maybe. 

Sorry I have not followed your discussions so excuse me if this is
off-topic.
 
Regards 

Sacha

[1] http://www.faqs.org/rfcs/rfc2554.html


Am Freitag, den 03.11.2006, 16:01 -0700 schrieb Ric Emery:
> 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. 
>         
>