RE: [ebxmlms-develop] Client authentication remote user

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

For 'normal' circumstances I agree, but in our case customers want
additional action to be taken in the process of receiving a message. Thing
like message (attachement) conversion from edi to xml and vice-versa, virus
scanning, audit-trails etc...We are therefor developing a 'communication
hub' and not (only) using the server as an endpoint (that is why we need
multi-hop functionality)
 
Using ejb's and many other j2ee specific things(like jms, mdb's,
connectionpools, transactions) makes the core of hermes even simpeler but I
agree, it is not for the faint-harted. But the same is true for buidling
your own connectionpools, transactionmanager, multi-threaded
message-processor etc. Maybe hermes one day will be able to support both. I
try to make sure the changes we need can live together with the current
core, so e.g. a configuration parameter could be to switch hermes into j2ee
mode.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: vrijdag 4 april 2003 2:55
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Client authentication remote user



I'm happy to leave Hermes as a black box, rather than try and put
site-specific checking into it. As long as Hermes passes the relevant
information to the listener, the listener (or another interface into the
backoffice) can do mapping table checks. That way there's a clean break
between the MSH black box and the custom processing.

However, Hermes causes information loss from the incoming message to the
listener, and we need to overcome that. 

My main objection to EJBs is that they add an extra level of unnecessary
complication for many uses, and Hermes runs quite nicely as it is.

PJDM 
-- 
Peter Mayne 
Technology Consultant 
Spherion Technology Solutions 
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 
T: 61 2 62689727  F: 61 2 62689777 

> -----Original Message----- 
> From: Ronald van Kuijk [ mailto:rv...@ab... <mailto:rv...@ab...> ] 
> Sent: Friday, 4 April 2003 10:37 AM 
> To: ebx...@li... 
> Subject: Re: [ebxmlms-develop] Client authentication remote user 
> 
> 
> 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 


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.