Re: [ebxmlms-develop] Client authentication remote user

[Ronald v. K. <rv...@ab...>]

Why I do not know, but i'm not in favor or against either solution.

Currently we've implemented lots of logic in ejb's (e.g. billing). They 
have access to the userprincipal as well. I can imagine that that goes a 
little to far or is overkill (although JBoss is not that expensive ;-) ).

In several articles about security you come across the issues about 
combining transport authentication (BA/Cert), with message based 
authentication (or persistent authentication like it is called in 
ebxml). In our branche e.g. there are companies that collect messages 
from other parties and send them to us. The party that signed the 
message is not the same as the one that sents the message. We have 
mapping tables that check the combination. This is done on the MSH level 
to prevent illegal messages getting into our backoffice.  So we need to 
be able to crosscheck both types of authentication.

We will be looking into using ejb's for certain parts of hermes, so we 
can eventually get around this and use the principal from the ejb's. For 
the moment however, access to the principal in another way is a good 
alternative. Again, if others have arguments in favor of one of the 
solutions, i won't argue against it (unless it is a really stupid 
argument ;-))

Ronald



Mayne, Peter probeerde het volgende duidelijk te maken op 04-04-03 01:59:

> My thought is that we have to know who sent the message so we know if 
> the message is valid. (The more data, the better for the audit trail.)
>
> Suppose we deal with partners A and B. Each partner uses client 
> authentication to connect to our Hermes, and each message is signed.
>
> Partner B is naughty, and sends a purchase order that looks like an 
> order from partner A. The web server will accept the client 
> authentication, but Hermes ignores it, so we don't know who the 
> message came from.
>
> Some partners (especially smaller shops) might not want to go to the 
> trouble and expense of signing their messages, and just rely on client 
> authentication. Or, we might need the remote user for other purposes 
> (such as Ronald's billing). However, we can't do this at the moment, 
> because we have no way of finding out who sent the message.
>
> Suppose the message is signed. Hermes will then check the digital 
> signature, which is valid, because the message was correctly signed by 
> partner B. The message is then passed to the listener, which pulls it 
> apart and deals with it. However, if we can't look at the certificates 
> that signed the message (I can't see how to do this in Hermes at the 
> moment), then we won't know that this message really came from partner 
> B, and we'll go ahead and process an order that looks like it came 
> from partner A.
>
> Hermes stores the remote address and remote host in its database, but 
> not the remote user. It would be greatly preferable for metadata such 
> as remote address/host/user to be passed with the message to the 
> listener, so then the backend doesn't have to query the Hermes database.
>
> Would it be possible to provide for an onMessage(EbxmlMessage, 
> Metadata) callback, where the Metadata class contains all of the data 
> (remote host/address/user, MIME headers, etc) relevant to the delivery 
> of the message? This might mean changing the MessageListener interface 
> (no big deal in a pre-version 1 product :-). There could be an 
> alternative MetaMessageListener interface, but that feels ugly. 
> Besides, if we don't want the extra data, we'll just ignore it.
>
> Comments?
>
> PJDM
> -- 
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>
>  
>