ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] Client certificate authentication

[Patrick Y. <kc...@ce...>]

I am ok for both style of follow-up. :-)

I agree to start simple. And I think the design should allow easy
modification to use selectible certificates.

Using MDB will give a clearer separation of working threads and the control
thread. In this model, I can now understand that something like connection
pool should be used for sharing of the certificate information. As you know,
Hermes uses tightly-coupled architecture, so I think it is relatively easier
to share the certificate information. I have not much idea about the
performance issue. Indeed using MDB will "upgrade" the system requirement...
JMS, J2EE, etc.

For the configuration on EndPoints. This raises up an issue. Now, all
endpoints information are configured dynamically (via Request object). If
some configuration on EndPoints are given on property file, and some
configuration on EndPoints are given using Request object, there may be
chances for inconsistencies, which we should handle carefully. Also, should
Hermes be restarted for configuring a new EndPoint of trade partner, so that
the EndPoint information can be read from the property file. Or, should we
look up of the property file every minutes to get the dynamic values?

Regards, -Patrick

----- Original Message -----
From: "Ronald van Kuijk" <rv...@ab...>
To: <ebx...@li...>
Sent: Saturday, March 29, 2003 07:13 AM
Subject: Re: [ebxmlms-develop] Client certificate authentication


> to prevent this message to become to nested, I'll write it separately
> above the message (or if you guys prefere a response below that is
> possible to (and the mozilla default))
>
> I'll try to write a small example of the SOAPConnection, initiallly
> without the selectable certificates. Maybe i'll try to uses AXIS at the
> same time. Their jaxm/saaj implementation is less complex compared to
> the Sun one.
>
> I can understand why your are confused, the text was not that clear. I
> mean that if we write our own HTTPSOAPConnection, we indeed should make
> sure multiple certificates can be used. What I don't know is how much
> this will impact performance, there should probably be a kind of
> connectionpool or something like this.  In our current Messaging Server,
> we use JMS queues internally with MDB's for outgoing connections. Each
> MDB has its own (https) endpoint with little impact on performance.
>
> I agree that the issue of the dual use of a certificate should be up to
> the end-user. What I ment was that we cannot asume the same certificate
> can be used.
>
> The proposed configuration for endpoints could include BA username and
> password as well. Although they could be included in the url as well,
> i'm not in favor of that
>
> Ronald
>
> Patrick Yee on 28-03-03:20:34 tried to convince me of:
>
> >>>I'm using the writing of this email as an incentive to do some
> >>>investigation into client authentication, so please excuse my rambling
> >>>as I write this and read code and docs at the same time.
> >>>
> >>>
> >
> >Peter & Ronald, thanks for your input.
> >
> >
> >
> >>>Note that I haven't yet tested any of the conclusions I've come up
> >>>with. I'll do that real soon, honest. :-)
> >>>
> >>>There are two kinds of client authentication that concern us: basic
> >>>(BA) and client certificate (CCA). (There's also digest
> >>>authentication; should we worry about that as well? It's probably safe
> >>>to not worry about other kinds such as forms authentication.)
> >>>
> >>>
> >>>
> >>Formbased  can indeed be ignored and we have not used digest
> >>authentication either.
> >>
> >>
> >
> >+1. IMHO, we can just focus on BA and CCA. They cover most of the use
cases.
> >
> >
> >
> >>>The type of authentication to use depends on the URL we are connecting
> >>>to. One URL may use BA, another may use CCA. Furthermore, two
> >>>different URLs that use BA will require two different
> >>>username/passwords, and likewise two different CCA URLs will require
> >>>two different certificates.
> >>>
> >>>
> >>>
> >>not necessarily, It could be one and the same certificate, depending on
> >>what you want to achieve. If different urls are seprate MSH's (e.g. for
> >>a different community) then two certifcates could be needed. One
> >>customer could be in different communities as well and you do not want
> >>them to have to configure/use/buy different certificates. Using roles
> >>(authorization) is a method we currently use in our home-build MSH)
> >>
> >>
> >>
> >
> >Well, one certificate for multiple URLs in CCA case may be acceptable.
But
> >it is necessary to have different user names/passwords for different URLs
in
> >BA case. It can't be helped but we have to let the user specify different
> >parameters for different URLs. So why don't we relax this limitation as
the
> >effort should be paid anyway?
> >
> >
> >
> >
> >>>Therefore, we require a mapping from a URL to (authentication type,
> >>>authentication data), where authentication type is one of BA or CCA,
> >>>and authentication data is either a username/password, or (since we're
> >>>using Java) a keystore/keystore password. (Is it possible to have
> >>>multiple client certificates in a keystore, and be able to select one
> >>>to use for a particular connection?)`
> >>>
> >>>
> >>>
> >>It is possible to use multiple certs in a jks keystore and select the
> >>correct one by alias, or automagically based on Issuer CA/trusted CA
> >>matching on client and server) (see configfile remark at the end)
> >>
> >>
> >>
> >>>Where does this mapping get used? HttpServlet.send() seems like the
> >>>right place. I'd hazard a guess that this is where we look up the
> >>>(authentication type, authentication data) using the URL as a key, and
> >>>then decide to use BA or not:
> >>>
> >>>        message.getMimeHeaders().setHeader("Authorization", "Basic " +
> >>>base64EncodedUsernamePassword);
> >>>
> >>>or CCA:
> >>>
> >>>        ...
> >>>        HttpsUrlConnection.setSSLSocketFactory(keystoreForThisUrl);
> >>>
> >>>Either way, if SSL is used, the correct truststore needs to be set up
> >>>as well. However, we only need one truststore, since all of the CA
> >>>certs can be put in it with no problems.
> >>>
> >>>Unfortunately, the HttpURLConnection is buried inside
> >>>HttpSOAPConnection.post() where we can't specify separate keystores,
> >>>which means we have to fall back to specifiying javax.net.ssl.keystore
> >>>either when Tomcat is started, or somewhere else. Which brings me back
> >>>to my earlier question: if we do CCA against different servers, how is
> >>>the correct certificate for that server chosen from our keystore? Or
> >>>am I missing something and it doesn't matter (which I suspect is the
> >>>case).
> >>>
> >>>
> >>>
> >>It could matter alot if you have e.g. two certificates issued by the
> >>same CA, but for different communities you have to connect to (if these
> >>run on different MHS's). Writing your/our own HTTPSOAPConnection  is
> >>possible and configurable via a factory. We already did this to get
> >>access to http errors (401,404  etc)
> >>
> >>
> >
> >Ronald, can you give us more information on how to do that?
> >
> >
> >
> >>>Here's a bonus: HttpSOAPConnection.post() uses
> >>>com.sun.xml.messaging.saaj.util.JaxmURI internally, which seems to
> >>>extract the BA header out of the URL for us, which is nice. This means
> >>>that for any URL where BA is required, we can specify the URL as
> >>>http://username:password@host/theRest. That handles the BA mapping
> >>>nicely with no extra work. (Does the Apache Axis stuff do this? Jason?)
> >>>
> >>>
> >>>
> >>It does, and AXIS does more (better proxy support, both spec wise and
> >>functionality wise like NTLM authentication in M$ environments, HTTP
> >>keep-alive in the next version) I do not know if it is more flexible in
> >>selecting certificates from a keyststore, but since their SOAPConnection
> >>is in cvs, it can be easilly adapted (instead of using JAD with the Sun
> >>implementation ;-))
> >>
> >>
> >>
> >>>So, that leaves us with the Hermes question:
> >>>
> >>>- where do we specify the truststore + keystore + keystorePassword
> >>>properties to be used for the connection?
> >>>
> >>>
> >>>
> >>Start simpel i think. Assume hermes will be used in a community where
> >>you can enforce the use of a certain certificate. No need for selecting
> >>a specific certificate then.  Eventually a generic  mechanism in the
> >>config fiile (see at the end) would be handy
> >>
> >>
> >>
> >>>Do we specify the javax.net.ssl.* properties to the JVM when we start
> >>>Tomcat? Would this interfere with other Tomcat applications? Does it
> >>>matter?
> >>>
> >>>
> >>>
> >>It does matter (afaik) if you use the  system-properties, you use an
> >>already initialized sslcontext. Creating a new sslcontext and 'feeding'
> >>that to the outgoing http connection is a way to separate these. JAXM
> >>does not support this by default, you can create your own
> >>SOAPConnectionFactory implementation (extending SOAPConnection) to
> >>achieve this
> >>
> >>
> >>
> >>>The other question (not so much Hermes related):
> >>>
> >>>- how is the right certificate for a particular connection chosen from
> >>>the client's keystore?
> >>>
> >>>
> >>>
> >>- by alias if the SOAPConnectionFactory implementation supports that, or
> >>create your own (HermesHttpSoapConnectionImpl would be a nice
classname?)
> >>- automagically (which i'm not that keen on)
> >>
> >>
> >>
> >>>My guess here is that only one client certificate is required for
> >>>authenticating to all of the different servers, and a small amount of
> >>>cooperation between the server people and the client people will
> >>>ensure that the certificate is accepted, and therefore the keystore
> >>>need only contain a single certificate. But I'm only guessing that
> >>>this is an acceptable policy.
> >>>
> >>>
> >>>
> >>This is what I mean by starting simple for a closed community, no
> >>certificate selection needed, just make sure the right certificates are
> >>in the appserver keystore. A remaining issue is whether the server cert
> >>(for incomming connections) may be used as a client cert as well. Not
> >>all CA's issued server certs that allow this.
> >>
> >>
> >
> >I am confused. In the above, I can feel that we should write our own
> >HTTPSOAPConnection. If we need to write that class, why we need to make
such
> >assumption (one certificate serves all URLs)? I mean, we have to read
from
> >config file for the certificate information anyway. Is there a big
> >difference between having one keystore and having a mapping of URLs to
> >keystores?
> >
> >Also, I am not too clear about the "remaining issue". Is that the user's
> >responsibility to make sure the cert (no matter it is server cert or
client
> >cert or both) is usable?
> >
> >
> >
> >>>So, it may turn out that Hermes can do client authentication (both BA
> >>>and CCA) already. I suppose I'd better go and experiment. :-)
> >>>
> >>>
> >>>
> >>Probably, I wouldn't be surprised
> >>
> >>
> >>
> >>>Comments? Mistakes?
> >>>
> >>>
> >>>
> >>Eventually a different way of configuring the use of certificates
> >>(signing, authentication, trust) would be better (imho). More like
> >>configure a general keystore
> >>
> >><KeyStore>
> >>  <Path>/home/jboss/hermes</Path>
> >>  <File>mykeystore</File>
> >>  <Password>mypassword</Password>
> >></KeyStore>
> >>
> >>and refering to certain keys in combination with an endpoint in the
> >>following way:
> >><Endpoint>
> >>  <url>https://www.mymhs.org</url>
> >>  <ClientCert>myAuthCertAlias</ClientCert>
> >>  <DigitalSignature>myDigSigAlias</DigitalSignature>
> >>  <SMIME>myEncryptAlias</SMIME>
> >></Endpoint>
> >>
> >>
> >>
> >
> >This is a good idea. Thanks for your suggestion.
> >
> >
> >
> >>Ronald
> >>
> >>
> >>
> >
> >Regards, -Patrick
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by:
> >The Definitive IT and Networking Event. Be There!
> >NetWorld+Interop Las Vegas 2003 -- Register today!
> >http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> >_______________________________________________
> >ebxmlms-develop mailing list
> >ebx...@li...
> >https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

Re: [ebxmlms-develop] logging remark

[Patrick Y. <kc...@ce...>]

Thank you for you suggestion. We are doing logging restrucuring recently. So
it is the right time to take care this.

I am not too sure at one point: why xml -> string conversion is needed when
using logger? Is this specific to your messaging system only?

Cheers, -Patrick

----- Original Message -----
From: "Ronald van Kuijk" <rv...@ab...>
To: "freebxml" <ebx...@li...>
Sent: Saturday, March 29, 2003 08:29 AM
Subject: [ebxmlms-develop] logging remark


> Hi,
>
> I've seen that all logging is done without checking whether the
> specified loglevel is even configured. We've seen in our Messaging
> System that first checking if a certain loglevel is configured gave us
> 3-7% performance gain. This was due to the fact that on man ocasions xml
> -> string conversions were needed as well as string
creation/concatenation.
>
> So instead of
>
> logger.debug("A message");
>
> we now do
>
> if (logger.isDebugEnabled()) {
>     logger.debug("A message");
> }
>
> I do not know what the gain will be in hermes since i've not looked
> through all the code. It's probably not that much since debug info is
> not that detailed, but I thought I'd just mention it.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

Re: [ebxmlms-develop] Design questions

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

It was late when I wrote this (and even later now) but ofcourse file 
based persistence is not part of j2ee. That should have been jms..(for 
internal queing, retries etc...with mdb's as the message processors)

Ronald van Kuijk probeerde het volgende duidelijk te maken op 29-03-03 
02:16:

> Hi,
>
> Hermes is now more or less an atomic application. I you build or use a 
> servletcontainer (e.g. embedded tomcat or so) nothing else is needed. 
> This is good in many cases, but we like to make as much use of 
> features of a full j2ee application server as possible. The parts that 
> come to mind are:
>
> - Authentication
> - DBConnectionpooling, based on JNDI
> - Transactions
> - File based persistence
>
> I can imagine that doing this, means that it can run in simple servlet 
> engines and that the performance is probably higher. In our case 
> however it has to run in a Weblogic server at an ASP. They do not 
> allow us to configure database connections outside the appserver 
> connectionpools.  The same goes for the ba accounts and certificates. 
> They have to be checked against an ldap server, so the 
> username/password file is not an option for us.
>
> For High Availability reasons file based persistence is not an option. 
> I've seen that all the meta information is stored in a database, but 
> the messages themselves are not. Correct me if i'm wrong.
>
> Again, I do not mean this as an attack on your choices, but making 
> this configurable in one way or another, would benefit all (well at 
> least us ;-)). There are several developers in our company that could 
> spend time on this once we get permission/funding to redesign our 
> messaging server a little (it's now partly ebms 1.092 compliant, with 
> extensions to backwards compatible with our previous x.400 system)
>
> We also like to extend the system with several other options, many of 
> which need tapping into the message flow in our central MHS (is 
> muli-hop supported?)
> - EDI2XML and XML2EDI, depending of customer profiles
> - Virusscanning (yes, even with application to application 
> communication and pure xml/edi documents customers want this)
> - Generating Management Information based on the envelope and/or 
> content of the attachments
>
> We are thinking of implementing this in a kind of a 'bus' way, where 
> the bus is a jms queue and a kind of a businessrule/processflow 
> component to decide in which queue to place the message. We do not 
> like to have this tightly coupled with ejb's but loosly with queue's 
> and mdb's.
>
> Does anyone of you have any ideas on these subjects?
>
> Regards,
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

[ebxmlms-develop] Design questions

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

Hi,

Hermes is now more or less an atomic application. I you build or use a 
servletcontainer (e.g. embedded tomcat or so) nothing else is needed. 
This is good in many cases, but we like to make as much use of features 
of a full j2ee application server as possible. The parts that come to 
mind are:

- Authentication
- DBConnectionpooling, based on JNDI
- Transactions
- File based persistence

I can imagine that doing this, means that it can run in simple servlet 
engines and that the performance is probably higher. In our case however 
it has to run in a Weblogic server at an ASP. They do not allow us to 
configure database connections outside the appserver connectionpools.  
The same goes for the ba accounts and certificates. They have to be 
checked against an ldap server, so the username/password file is not an 
option for us.

For High Availability reasons file based persistence is not an option. 
I've seen that all the meta information is stored in a database, but the 
messages themselves are not. Correct me if i'm wrong.

Again, I do not mean this as an attack on your choices, but making this 
configurable in one way or another, would benefit all (well at least us 
;-)). There are several developers in our company that could spend time 
on this once we get permission/funding to redesign our messaging server 
a little (it's now partly ebms 1.092 compliant, with extensions to 
backwards compatible with our previous x.400 system)

We also like to extend the system with several other options, many of 
which need tapping into the message flow in our central MHS (is muli-hop 
supported?)
- EDI2XML and XML2EDI, depending of customer profiles
- Virusscanning (yes, even with application to application communication 
and pure xml/edi documents customers want this)
- Generating Management Information based on the envelope and/or content 
of the attachments

We are thinking of implementing this in a kind of a 'bus' way, where the 
bus is a jms queue and a kind of a businessrule/processflow component to 
decide in which queue to place the message. We do not like to have this 
tightly coupled with ejb's but loosly with queue's and mdb's.

Does anyone of you have any ideas on these subjects?

Regards,

Ronald

[ebxmlms-develop] logging remark

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

Hi,

I've seen that all logging is done without checking whether the 
specified loglevel is even configured. We've seen in our Messaging 
System that first checking if a certain loglevel is configured gave us 
3-7% performance gain. This was due to the fact that on man ocasions xml 
-> string conversions were needed as well as string creation/concatenation.

So instead of

logger.debug("A message");

we now do

if (logger.isDebugEnabled()) {
    logger.debug("A message");
}

I do not know what the gain will be in hermes since i've not looked 
through all the code. It's probably not that much since debug info is 
not that detailed, but I thought I'd just mention it.

Ronald

Re: [ebxmlms-develop] Client certificate authentication

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

to prevent this message to become to nested, I'll write it separately 
above the message (or if you guys prefere a response below that is 
possible to (and the mozilla default))

I'll try to write a small example of the SOAPConnection, initiallly 
without the selectable certificates. Maybe i'll try to uses AXIS at the 
same time. Their jaxm/saaj implementation is less complex compared to 
the Sun one.

I can understand why your are confused, the text was not that clear. I 
mean that if we write our own HTTPSOAPConnection, we indeed should make 
sure multiple certificates can be used. What I don't know is how much 
this will impact performance, there should probably be a kind of 
connectionpool or something like this.  In our current Messaging Server, 
we use JMS queues internally with MDB's for outgoing connections. Each 
MDB has its own (https) endpoint with little impact on performance.

I agree that the issue of the dual use of a certificate should be up to 
the end-user. What I ment was that we cannot asume the same certificate 
can be used.

The proposed configuration for endpoints could include BA username and 
password as well. Although they could be included in the url as well, 
i'm not in favor of that

Ronald

Patrick Yee on 28-03-03:20:34 tried to convince me of:

>>>I'm using the writing of this email as an incentive to do some
>>>investigation into client authentication, so please excuse my rambling
>>>as I write this and read code and docs at the same time.
>>>      
>>>
>
>Peter & Ronald, thanks for your input.
>
>  
>
>>>Note that I haven't yet tested any of the conclusions I've come up
>>>with. I'll do that real soon, honest. :-)
>>>
>>>There are two kinds of client authentication that concern us: basic
>>>(BA) and client certificate (CCA). (There's also digest
>>>authentication; should we worry about that as well? It's probably safe
>>>to not worry about other kinds such as forms authentication.)
>>>
>>>      
>>>
>>Formbased  can indeed be ignored and we have not used digest
>>authentication either.
>>    
>>
>
>+1. IMHO, we can just focus on BA and CCA. They cover most of the use cases.
>
>  
>
>>>The type of authentication to use depends on the URL we are connecting
>>>to. One URL may use BA, another may use CCA. Furthermore, two
>>>different URLs that use BA will require two different
>>>username/passwords, and likewise two different CCA URLs will require
>>>two different certificates.
>>>
>>>      
>>>
>>not necessarily, It could be one and the same certificate, depending on
>>what you want to achieve. If different urls are seprate MSH's (e.g. for
>>a different community) then two certifcates could be needed. One
>>customer could be in different communities as well and you do not want
>>them to have to configure/use/buy different certificates. Using roles
>>(authorization) is a method we currently use in our home-build MSH)
>>
>>    
>>
>
>Well, one certificate for multiple URLs in CCA case may be acceptable. But
>it is necessary to have different user names/passwords for different URLs in
>BA case. It can't be helped but we have to let the user specify different
>parameters for different URLs. So why don't we relax this limitation as the
>effort should be paid anyway?
>
>
>  
>
>>>Therefore, we require a mapping from a URL to (authentication type,
>>>authentication data), where authentication type is one of BA or CCA,
>>>and authentication data is either a username/password, or (since we're
>>>using Java) a keystore/keystore password. (Is it possible to have
>>>multiple client certificates in a keystore, and be able to select one
>>>to use for a particular connection?)`
>>>
>>>      
>>>
>>It is possible to use multiple certs in a jks keystore and select the
>>correct one by alias, or automagically based on Issuer CA/trusted CA
>>matching on client and server) (see configfile remark at the end)
>>
>>    
>>
>>>Where does this mapping get used? HttpServlet.send() seems like the
>>>right place. I'd hazard a guess that this is where we look up the
>>>(authentication type, authentication data) using the URL as a key, and
>>>then decide to use BA or not:
>>>
>>>        message.getMimeHeaders().setHeader("Authorization", "Basic " +
>>>base64EncodedUsernamePassword);
>>>
>>>or CCA:
>>>
>>>        ...
>>>        HttpsUrlConnection.setSSLSocketFactory(keystoreForThisUrl);
>>>
>>>Either way, if SSL is used, the correct truststore needs to be set up
>>>as well. However, we only need one truststore, since all of the CA
>>>certs can be put in it with no problems.
>>>
>>>Unfortunately, the HttpURLConnection is buried inside
>>>HttpSOAPConnection.post() where we can't specify separate keystores,
>>>which means we have to fall back to specifiying javax.net.ssl.keystore
>>>either when Tomcat is started, or somewhere else. Which brings me back
>>>to my earlier question: if we do CCA against different servers, how is
>>>the correct certificate for that server chosen from our keystore? Or
>>>am I missing something and it doesn't matter (which I suspect is the
>>>case).
>>>
>>>      
>>>
>>It could matter alot if you have e.g. two certificates issued by the
>>same CA, but for different communities you have to connect to (if these
>>run on different MHS's). Writing your/our own HTTPSOAPConnection  is
>>possible and configurable via a factory. We already did this to get
>>access to http errors (401,404  etc)
>>    
>>
>
>Ronald, can you give us more information on how to do that?
>
>  
>
>>>Here's a bonus: HttpSOAPConnection.post() uses
>>>com.sun.xml.messaging.saaj.util.JaxmURI internally, which seems to
>>>extract the BA header out of the URL for us, which is nice. This means
>>>that for any URL where BA is required, we can specify the URL as
>>>http://username:password@host/theRest. That handles the BA mapping
>>>nicely with no extra work. (Does the Apache Axis stuff do this? Jason?)
>>>
>>>      
>>>
>>It does, and AXIS does more (better proxy support, both spec wise and
>>functionality wise like NTLM authentication in M$ environments, HTTP
>>keep-alive in the next version) I do not know if it is more flexible in
>>selecting certificates from a keyststore, but since their SOAPConnection
>>is in cvs, it can be easilly adapted (instead of using JAD with the Sun
>>implementation ;-))
>>
>>    
>>
>>>So, that leaves us with the Hermes question:
>>>
>>>- where do we specify the truststore + keystore + keystorePassword
>>>properties to be used for the connection?
>>>
>>>      
>>>
>>Start simpel i think. Assume hermes will be used in a community where
>>you can enforce the use of a certain certificate. No need for selecting
>>a specific certificate then.  Eventually a generic  mechanism in the
>>config fiile (see at the end) would be handy
>>
>>    
>>
>>>Do we specify the javax.net.ssl.* properties to the JVM when we start
>>>Tomcat? Would this interfere with other Tomcat applications? Does it
>>>matter?
>>>
>>>      
>>>
>>It does matter (afaik) if you use the  system-properties, you use an
>>already initialized sslcontext. Creating a new sslcontext and 'feeding'
>>that to the outgoing http connection is a way to separate these. JAXM
>>does not support this by default, you can create your own
>>SOAPConnectionFactory implementation (extending SOAPConnection) to
>>achieve this
>>
>>    
>>
>>>The other question (not so much Hermes related):
>>>
>>>- how is the right certificate for a particular connection chosen from
>>>the client's keystore?
>>>
>>>      
>>>
>>- by alias if the SOAPConnectionFactory implementation supports that, or
>>create your own (HermesHttpSoapConnectionImpl would be a nice classname?)
>>- automagically (which i'm not that keen on)
>>
>>    
>>
>>>My guess here is that only one client certificate is required for
>>>authenticating to all of the different servers, and a small amount of
>>>cooperation between the server people and the client people will
>>>ensure that the certificate is accepted, and therefore the keystore
>>>need only contain a single certificate. But I'm only guessing that
>>>this is an acceptable policy.
>>>
>>>      
>>>
>>This is what I mean by starting simple for a closed community, no
>>certificate selection needed, just make sure the right certificates are
>>in the appserver keystore. A remaining issue is whether the server cert
>>(for incomming connections) may be used as a client cert as well. Not
>>all CA's issued server certs that allow this.
>>    
>>
>
>I am confused. In the above, I can feel that we should write our own
>HTTPSOAPConnection. If we need to write that class, why we need to make such
>assumption (one certificate serves all URLs)? I mean, we have to read from
>config file for the certificate information anyway. Is there a big
>difference between having one keystore and having a mapping of URLs to
>keystores?
>
>Also, I am not too clear about the "remaining issue". Is that the user's
>responsibility to make sure the cert (no matter it is server cert or client
>cert or both) is usable?
>
>  
>
>>>So, it may turn out that Hermes can do client authentication (both BA
>>>and CCA) already. I suppose I'd better go and experiment. :-)
>>>
>>>      
>>>
>>Probably, I wouldn't be surprised
>>
>>    
>>
>>>Comments? Mistakes?
>>>
>>>      
>>>
>>Eventually a different way of configuring the use of certificates
>>(signing, authentication, trust) would be better (imho). More like
>>configure a general keystore
>>
>><KeyStore>
>>  <Path>/home/jboss/hermes</Path>
>>  <File>mykeystore</File>
>>  <Password>mypassword</Password>
>></KeyStore>
>>
>>and refering to certain keys in combination with an endpoint in the
>>following way:
>><Endpoint>
>>  <url>https://www.mymhs.org</url>
>>  <ClientCert>myAuthCertAlias</ClientCert>
>>  <DigitalSignature>myDigSigAlias</DigitalSignature>
>>  <SMIME>myEncryptAlias</SMIME>
>></Endpoint>
>>
>>    
>>
>
>This is a good idea. Thanks for your suggestion.
>
>  
>
>>Ronald
>>
>>    
>>
>
>Regards, -Patrick
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:
>The Definitive IT and Networking Event. Be There!
>NetWorld+Interop Las Vegas 2003 -- Register today!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsNull message listener =
sounds like desirable, but we have to think carefully about the =
consequence. One of the issues is when Hermes receives an error message =
referring to the sent message, how can Hermes deliver the error message =
to the correct client application. In the current case, Hermes relies on =
the AppContext of the sending Request object to deliver the error =
messages. We will discuss about it next week.

Regards, -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 28, 2003 11:30 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  >> However, consider the situation where Hermes is running on a server =
in a DMZ, and the listener is=20
  >> running on a different server in the internal network. There's =
definitely no way to control the load=20
  >> sequence then.=20
  >=20
  > In that case, manual procedure in system maintenance should be =
enforced. An analogy is that you have=20
  > to start up DB server before app server. There should be a startup =
procedure which the sequence is=20
  > significant.=20

  I'm not greatly worried by this: once the registration has happened, =
it sticks forever, and it isn't that hard to run the listener at least =
once while Hermes is running. :-)

  > Under the current architecture, you have to use an AppContext which =
is never be used in a real message=20
  > for sending.=20

  Ugh. Can this please be changed? Or can I create an =
ApplicationContext(null, null, null, null) that doesn't match any other =
ApplicationContext? Hmm, no, the constructor throws a =
NullPointerException at the cpaId.toCharArray(), and equals() wouldn't =
work either, and the MSHConfig table doesn't allow nulls in c_cpaid.

  What effect does specifying a null MessageListener to the Request =
constructor have?=20

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

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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.

Re: [ebxmlms-develop] Client certificate authentication

[Patrick Y. <kc...@ce...>]

> > I'm using the writing of this email as an incentive to do some
> > investigation into client authentication, so please excuse my rambling
> > as I write this and read code and docs at the same time.

Peter & Ronald, thanks for your input.

> >
> > Note that I haven't yet tested any of the conclusions I've come up
> > with. I'll do that real soon, honest. :-)
> >
> > There are two kinds of client authentication that concern us: basic
> > (BA) and client certificate (CCA). (There's also digest
> > authentication; should we worry about that as well? It's probably safe
> > to not worry about other kinds such as forms authentication.)
> >
> Formbased  can indeed be ignored and we have not used digest
> authentication either.

+1. IMHO, we can just focus on BA and CCA. They cover most of the use cases.

>
> > The type of authentication to use depends on the URL we are connecting
> > to. One URL may use BA, another may use CCA. Furthermore, two
> > different URLs that use BA will require two different
> > username/passwords, and likewise two different CCA URLs will require
> > two different certificates.
> >
> not necessarily, It could be one and the same certificate, depending on
> what you want to achieve. If different urls are seprate MSH's (e.g. for
> a different community) then two certifcates could be needed. One
> customer could be in different communities as well and you do not want
> them to have to configure/use/buy different certificates. Using roles
> (authorization) is a method we currently use in our home-build MSH)
>

Well, one certificate for multiple URLs in CCA case may be acceptable. But
it is necessary to have different user names/passwords for different URLs in
BA case. It can't be helped but we have to let the user specify different
parameters for different URLs. So why don't we relax this limitation as the
effort should be paid anyway?


> > Therefore, we require a mapping from a URL to (authentication type,
> > authentication data), where authentication type is one of BA or CCA,
> > and authentication data is either a username/password, or (since we're
> > using Java) a keystore/keystore password. (Is it possible to have
> > multiple client certificates in a keystore, and be able to select one
> > to use for a particular connection?)`
> >
> It is possible to use multiple certs in a jks keystore and select the
> correct one by alias, or automagically based on Issuer CA/trusted CA
> matching on client and server) (see configfile remark at the end)
>
> > Where does this mapping get used? HttpServlet.send() seems like the
> > right place. I'd hazard a guess that this is where we look up the
> > (authentication type, authentication data) using the URL as a key, and
> > then decide to use BA or not:
> >
> >         message.getMimeHeaders().setHeader("Authorization", "Basic " +
> > base64EncodedUsernamePassword);
> >
> > or CCA:
> >
> >         ...
> >         HttpsUrlConnection.setSSLSocketFactory(keystoreForThisUrl);
> >
> > Either way, if SSL is used, the correct truststore needs to be set up
> > as well. However, we only need one truststore, since all of the CA
> > certs can be put in it with no problems.
> >
> > Unfortunately, the HttpURLConnection is buried inside
> > HttpSOAPConnection.post() where we can't specify separate keystores,
> > which means we have to fall back to specifiying javax.net.ssl.keystore
> > either when Tomcat is started, or somewhere else. Which brings me back
> > to my earlier question: if we do CCA against different servers, how is
> > the correct certificate for that server chosen from our keystore? Or
> > am I missing something and it doesn't matter (which I suspect is the
> > case).
> >
> It could matter alot if you have e.g. two certificates issued by the
> same CA, but for different communities you have to connect to (if these
> run on different MHS's). Writing your/our own HTTPSOAPConnection  is
> possible and configurable via a factory. We already did this to get
> access to http errors (401,404  etc)

Ronald, can you give us more information on how to do that?

>
> > Here's a bonus: HttpSOAPConnection.post() uses
> > com.sun.xml.messaging.saaj.util.JaxmURI internally, which seems to
> > extract the BA header out of the URL for us, which is nice. This means
> > that for any URL where BA is required, we can specify the URL as
> > http://username:password@host/theRest. That handles the BA mapping
> > nicely with no extra work. (Does the Apache Axis stuff do this? Jason?)
> >
> It does, and AXIS does more (better proxy support, both spec wise and
> functionality wise like NTLM authentication in M$ environments, HTTP
> keep-alive in the next version) I do not know if it is more flexible in
> selecting certificates from a keyststore, but since their SOAPConnection
> is in cvs, it can be easilly adapted (instead of using JAD with the Sun
> implementation ;-))
>
> > So, that leaves us with the Hermes question:
> >
> > - where do we specify the truststore + keystore + keystorePassword
> > properties to be used for the connection?
> >
> Start simpel i think. Assume hermes will be used in a community where
> you can enforce the use of a certain certificate. No need for selecting
> a specific certificate then.  Eventually a generic  mechanism in the
> config fiile (see at the end) would be handy
>
> > Do we specify the javax.net.ssl.* properties to the JVM when we start
> > Tomcat? Would this interfere with other Tomcat applications? Does it
> > matter?
> >
> It does matter (afaik) if you use the  system-properties, you use an
> already initialized sslcontext. Creating a new sslcontext and 'feeding'
> that to the outgoing http connection is a way to separate these. JAXM
> does not support this by default, you can create your own
> SOAPConnectionFactory implementation (extending SOAPConnection) to
> achieve this
>
> > The other question (not so much Hermes related):
> >
> > - how is the right certificate for a particular connection chosen from
> > the client's keystore?
> >
> - by alias if the SOAPConnectionFactory implementation supports that, or
> create your own (HermesHttpSoapConnectionImpl would be a nice classname?)
> - automagically (which i'm not that keen on)
>
> > My guess here is that only one client certificate is required for
> > authenticating to all of the different servers, and a small amount of
> > cooperation between the server people and the client people will
> > ensure that the certificate is accepted, and therefore the keystore
> > need only contain a single certificate. But I'm only guessing that
> > this is an acceptable policy.
> >
> This is what I mean by starting simple for a closed community, no
> certificate selection needed, just make sure the right certificates are
> in the appserver keystore. A remaining issue is whether the server cert
> (for incomming connections) may be used as a client cert as well. Not
> all CA's issued server certs that allow this.

I am confused. In the above, I can feel that we should write our own
HTTPSOAPConnection. If we need to write that class, why we need to make such
assumption (one certificate serves all URLs)? I mean, we have to read from
config file for the certificate information anyway. Is there a big
difference between having one keystore and having a mapping of URLs to
keystores?

Also, I am not too clear about the "remaining issue". Is that the user's
responsibility to make sure the cert (no matter it is server cert or client
cert or both) is usable?

>
> > So, it may turn out that Hermes can do client authentication (both BA
> > and CCA) already. I suppose I'd better go and experiment. :-)
> >
> Probably, I wouldn't be surprised
>
> > Comments? Mistakes?
> >
>
> Eventually a different way of configuring the use of certificates
> (signing, authentication, trust) would be better (imho). More like
> configure a general keystore
>
> <KeyStore>
>   <Path>/home/jboss/hermes</Path>
>   <File>mykeystore</File>
>   <Password>mypassword</Password>
> </KeyStore>
>
> and refering to certain keys in combination with an endpoint in the
> following way:
> <Endpoint>
>   <url>https://www.mymhs.org</url>
>   <ClientCert>myAuthCertAlias</ClientCert>
>   <DigitalSignature>myDigSigAlias</DigitalSignature>
>   <SMIME>myEncryptAlias</SMIME>
> </Endpoint>
>

This is a good idea. Thanks for your suggestion.

> Ronald
>

Regards, -Patrick

Re: [ebxmlms-develop] Client certificate authentication

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

Mayne, Peter probeerde het volgende duidelijk te maken op 28-3-2003 4:05:

> I'm using the writing of this email as an incentive to do some 
> investigation into client authentication, so please excuse my rambling 
> as I write this and read code and docs at the same time.
>
> Note that I haven't yet tested any of the conclusions I've come up 
> with. I'll do that real soon, honest. :-)
>
> There are two kinds of client authentication that concern us: basic 
> (BA) and client certificate (CCA). (There's also digest 
> authentication; should we worry about that as well? It's probably safe 
> to not worry about other kinds such as forms authentication.)
>
Formbased  can indeed be ignored and we have not used digest 
authentication either.

> The type of authentication to use depends on the URL we are connecting 
> to. One URL may use BA, another may use CCA. Furthermore, two 
> different URLs that use BA will require two different 
> username/passwords, and likewise two different CCA URLs will require 
> two different certificates.
>
not necessarily, It could be one and the same certificate, depending on 
what you want to achieve. If different urls are seprate MSH's (e.g. for 
a different community) then two certifcates could be needed. One 
customer could be in different communities as well and you do not want 
them to have to configure/use/buy different certificates. Using roles 
(authorization) is a method we currently use in our home-build MSH)

> Therefore, we require a mapping from a URL to (authentication type, 
> authentication data), where authentication type is one of BA or CCA, 
> and authentication data is either a username/password, or (since we're 
> using Java) a keystore/keystore password. (Is it possible to have 
> multiple client certificates in a keystore, and be able to select one 
> to use for a particular connection?)`
>
It is possible to use multiple certs in a jks keystore and select the 
correct one by alias, or automagically based on Issuer CA/trusted CA 
matching on client and server) (see configfile remark at the end)

> Where does this mapping get used? HttpServlet.send() seems like the 
> right place. I'd hazard a guess that this is where we look up the 
> (authentication type, authentication data) using the URL as a key, and 
> then decide to use BA or not:
>
>         message.getMimeHeaders().setHeader("Authorization", "Basic " + 
> base64EncodedUsernamePassword);
>
> or CCA:
>
>         ...
>         HttpsUrlConnection.setSSLSocketFactory(keystoreForThisUrl);
>
> Either way, if SSL is used, the correct truststore needs to be set up 
> as well. However, we only need one truststore, since all of the CA 
> certs can be put in it with no problems.
>
> Unfortunately, the HttpURLConnection is buried inside 
> HttpSOAPConnection.post() where we can't specify separate keystores, 
> which means we have to fall back to specifiying javax.net.ssl.keystore 
> either when Tomcat is started, or somewhere else. Which brings me back 
> to my earlier question: if we do CCA against different servers, how is 
> the correct certificate for that server chosen from our keystore? Or 
> am I missing something and it doesn't matter (which I suspect is the 
> case).
>
It could matter alot if you have e.g. two certificates issued by the 
same CA, but for different communities you have to connect to (if these 
run on different MHS's). Writing your/our own HTTPSOAPConnection  is 
possible and configurable via a factory. We already did this to get 
access to http errors (401,404  etc)

> Here's a bonus: HttpSOAPConnection.post() uses 
> com.sun.xml.messaging.saaj.util.JaxmURI internally, which seems to 
> extract the BA header out of the URL for us, which is nice. This means 
> that for any URL where BA is required, we can specify the URL as 
> http://username:password@host/theRest. That handles the BA mapping 
> nicely with no extra work. (Does the Apache Axis stuff do this? Jason?)
>
It does, and AXIS does more (better proxy support, both spec wise and 
functionality wise like NTLM authentication in M$ environments, HTTP 
keep-alive in the next version) I do not know if it is more flexible in 
selecting certificates from a keyststore, but since their SOAPConnection 
is in cvs, it can be easilly adapted (instead of using JAD with the Sun  
implementation ;-))

> So, that leaves us with the Hermes question:
>
> - where do we specify the truststore + keystore + keystorePassword 
> properties to be used for the connection?
>
Start simpel i think. Assume hermes will be used in a community where 
you can enforce the use of a certain certificate. No need for selecting 
a specific certificate then.  Eventually a generic  mechanism in the 
config fiile (see at the end) would be handy

> Do we specify the javax.net.ssl.* properties to the JVM when we start 
> Tomcat? Would this interfere with other Tomcat applications? Does it 
> matter?
>
It does matter (afaik) if you use the  system-properties, you use an 
already initialized sslcontext. Creating a new sslcontext and 'feeding' 
that to the outgoing http connection is a way to separate these. JAXM 
does not support this by default, you can create your own 
SOAPConnectionFactory implementation (extending SOAPConnection) to 
achieve this

> The other question (not so much Hermes related):
>
> - how is the right certificate for a particular connection chosen from 
> the client's keystore?
>
- by alias if the SOAPConnectionFactory implementation supports that, or 
create your own (HermesHttpSoapConnectionImpl would be a nice classname?)
- automagically (which i'm not that keen on)

> My guess here is that only one client certificate is required for 
> authenticating to all of the different servers, and a small amount of 
> cooperation between the server people and the client people will 
> ensure that the certificate is accepted, and therefore the keystore 
> need only contain a single certificate. But I'm only guessing that 
> this is an acceptable policy.
>
This is what I mean by starting simple for a closed community, no 
certificate selection needed, just make sure the right certificates are 
in the appserver keystore. A remaining issue is whether the server cert 
(for incomming connections) may be used as a client cert as well. Not 
all CA's issued server certs that allow this.

> So, it may turn out that Hermes can do client authentication (both BA 
> and CCA) already. I suppose I'd better go and experiment. :-)
>
Probably, I wouldn't be surprised

> Comments? Mistakes?
>

Eventually a different way of configuring the use of certificates 
(signing, authentication, trust) would be better (imho). More like 
configure a general keystore

<KeyStore>
  <Path>/home/jboss/hermes</Path>
  <File>mykeystore</File>
  <Password>mypassword</Password>
</KeyStore>

and refering to certain keys in combination with an endpoint in the 
following way:
<Endpoint>
  <url>https://www.mymhs.org</url>
  <ClientCert>myAuthCertAlias</ClientCert>
  <DigitalSignature>myDigSigAlias</DigitalSignature>
  <SMIME>myEncryptAlias</SMIME>
</Endpoint>

Ronald

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsComment inline. =
-Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 28, 2003 10:56 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  >> There's a small problem here. My listener servlet registers itself =
with Hermes in its init() method. If my=20
  >> listener starts for the first time while Hermes isn't up, the =
registration won't work, and Hermes will never=20
  >> know about the listener. Therefore, I've added a doGet() to my =
listener servlet which also does the=20
  >> registration, so I can manually register whenever I like, just in =
case.=20
  >=20
  > Is there anyway to control the load sequence in app server?=20

  There may be in Tomcat, but I don't know it. (If anyone does, please =
tell me.) However, consider the situation where Hermes is running on a =
server in a DMZ, and the listener is running on a different server in =
the internal network. There's definitely no way to control the load =
sequence then.

  In that case, manual procedure in system maintenance should be =
enforced. An analogy is that you have to start up DB server before app =
server. There should be a startup procedure which the sequence is =
significant.

  > The AppContext registered (through Request object) specifies which =
kind of messages you want to=20
  > receive. You can use that Request object to send out any messages. =
The AppContexts of those sent=20
  > messages are not necessariliy the same as the one you registered.=20

  But what if I don't want to receive any messages? I have a permanent =
listener running, registered for everything with ApplicationContext("*", =
"*", "*", "*"). Messages are sent by a separate application which starts =
up, sends the message, and finishes. I obviously don't want the sending =
application to register as a listener, because I already have a =
listener, and the sending application only runs when a message is sent.

  Can I pass a null ApplicationContext or MessageListener to Request to =
not register as a MessageListener, or should I use an ApplicationContext =
with a CPAId and/or conversationId and/or service and/or action that =
will (hopefully) never be used in a real message?

  Under the current architecture, you have to use an AppContext which is =
never be used in a real message for sending. We do have an alternative: =
unregistration of app context. But, I think, if you do unregistration =
everytime you sent a message. The loading to Hermes will be =
unnecessarily high.

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

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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsMy comment inline.
Regards, -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 28, 2003 6:10 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  In my listener I create a new Request with ApplicationContext("*", =
"*", "*", "*"), which presumably listens to everything. Since this =
registration is permanent, it only needs to be done once, but I presume =
it doesn't hurt to do it multiple times.

  Yes the registration is permanent, even when the client or Hermes =
quits. If the registered client goes offline, Hermes will store the =
messages for it. If Hermes goes offline, the registration information =
will be reloaded after it goes online again. It doesn't hurt to do =
registration multiple times.

  I haven't yet tested what happens if my listener registers with =
Hermes, but the listener is not up (or returns a failure response) when =
a message arrives.

  As said above, Hermes will store those messages and deliver them to =
the listener when it goes online again.

  There's a small problem here. My listener servlet registers itself =
with Hermes in its init() method. If my listener starts for the first =
time while Hermes isn't up, the registration won't work, and Hermes will =
never know about the listener. Therefore, I've added a doGet() to my =
listener servlet which also does the registration, so I can manually =
register whenever I like, just in case.

  Is there anyway to control the load sequence in app server?

  I also presume that it doesn't hurt to create an ApplicationContext =
with a null MessageListener. When I'm sending messages, I want to use =
the same MessageListener all the time, not a different one for every =
message. (I can't believe I haven't tested this yet. :-)

  The AppContext registered (through Request object) specifies which =
kind of messages you want to receive. You can use that Request object to =
send out any messages. The AppContexts of those sent messages are not =
necessariliy the same as the one you registered.

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

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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsYes, this is the =
correct way.

To make Hermes start to listen for incoming messages, we have 2 ways:
1. creating a Request object with a non-null AppContext.. just create it =
is sufficient, as registration will be done in the constructor.
2. creating a Request object with a null AppContext, and then sending =
out a message. Implicit registration will be done before sending out the =
message. The AppContext to be registered will be same as the one in the =
message.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 28, 2003 9:06 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  I believe that just creating a new Request is sufficient, but I'm open =
to reeducation.=20

      /**=20
       * Register our servlet as a Hermes listener for all incoming =
messages.=20
       *=20
       * If this is not successful, it doesn't necessarily mean things =
are bad. It could be that=20
       * Hermes is not running yet. Therefore, if the registration =
doesn't happen, don't panic=20
       * unless the specific error indicates otherwise.=20
       *=20
       * @return boolean true if the registration was successful, false =
otherwise.=20
       **/=20
      private boolean registerListener(URL mshServerUrl, URL =
mshListenerUrl)=20
      {=20
          MessageListener listener =3D new =
MessageListenerImpl(mshListenerUrl);=20
          Request mshReq =3D null;=20
          ApplicationContext appContext =3D new ApplicationContext("*", =
"*", "*", "*");=20
          try=20
          {=20
              logger.info("new Request to " + mshServerUrl + " to listen =
at " + mshListenerUrl);=20
              mshReq =3D new Request(appContext, mshServerUrl, listener, =
"HTTP");=20
              logger.info("listener registered");=20
          }=20
          catch(RequestException re)=20
          {=20
              logger.error("registerListener: Couldn't create new =
Request: " + re);=20
              return false;=20
          }=20
         =20
          return true;=20
      }=20

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

  > -----Original Message-----=20
  > From: Jason van Zyl [mailto:ja...@ze...]=20
  > Sent: Friday, 28 March 2003 11:56 AM=20
  > To: ebx...@li...=20
  > Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts=20
  >=20
  >=20
  > On Thu, 2003-03-27 at 17:10, Mayne, Peter wrote:=20
  > > In my listener I create a new Request with ApplicationContext("*", =

  > > "*", "*", "*"), which presumably listens to everything. Since this =

  > > registration is permanent, it only needs to be done once, but I=20
  > > presume it doesn't hurt to do it multiple times.=20
  >=20
  > How are you doing this without sending a message?=20
  >=20
  > I would like to initialize the pathway between the client =
application=20
  > and the server without sending anything and then reuse that pathway. =

  >=20
  > --=20
  > jvz.=20
  >=20
  > Jason van Zyl=20
  > ja...@ze...=20
  > http://tambora.zenplex.org=20
  >=20
  > In short, man creates for himself a new religion of a rational=20
  > and technical order to justify his work and to be justified in it.=20
  >  =20
  >   -- Jacques Ellul, The Technological Society=20
  >=20
  >=20
  >=20
  > -------------------------------------------------------=20
  > This SF.net email is sponsored by:=20
  > The Definitive IT and Networking Event. Be There!=20
  > NetWorld+Interop Las Vegas 2003 -- Register today!=20
  > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en=20
  > _______________________________________________=20
  > ebxmlms-develop mailing list=20
  > ebx...@li...=20
  > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop=20
  >=20

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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.

RE: [ebxmlms-develop] Setup of ApplicationContexts

[Jason v. Z. <ja...@ze...>]

On Thu, 2003-03-27 at 17:10, Mayne, Peter wrote:
> In my listener I create a new Request with ApplicationContext("*",
> "*", "*", "*"), which presumably listens to everything. Since this
> registration is permanent, it only needs to be done once, but I
> presume it doesn't hurt to do it multiple times.

How are you doing this without sending a message?

I would like to initialize the pathway between the client application
and the server without sending anything and then reuse that pathway.

-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Jason v. Z. <ja...@ze...>]

On Thu, 2003-03-27 at 11:01, Patrick Yee wrote:
> In the current architecture, the client A should register with server A
> first before server A accepts messages from server B which are target at
> client A.

I see in your diagnostic setup you setup application context, is there
anyway I could take advantage of that?

Also is there a recommended way of decoupling the registering of
application contexts with the server from sending messages?

For example the loopback does everything together, and that's is what
I've used for my little client running inside my container but I would
like to register in one phase and then send when needed.

> Regards, -Patrick
> 
> ----- Original Message -----
> From: "Jason van Zyl" <ja...@ze...>
> To: <ebx...@li...>
> Sent: Thursday, March 27, 2003 11:43 PM
> Subject: Re: [ebxmlms-develop] Setup of ApplicationContexts
> 
> 
> > On Thu, 2003-03-27 at 10:35, Jason van Zyl wrote:
> > > Hi,
> > >
> > > Is there a standard way to setup ApplicationContexts for the server?
> > >
> > > If a client application has not register an application context will the
> > > server still accept messages and store them?
> > >
> > > Say we have trading partner A and B. For A the server is alive and
> > > receives a message from B. If B has not set itself up with the server
> > > will the server still receive and store the messages?
> >
> > Sorry, that should have been: if server A receives a message from server
> > B but client A has not registered an application context with server A
> > will server A still receive and store the message that was sent from
> > server B?
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > ja...@ze...
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> >   -- Jacques Ellul, The Technological Society
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > ebxmlms-develop mailing list
> > ebx...@li...
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

In the current architecture, the client A should register with server A
first before server A accepts messages from server B which are target at
client A.

Regards, -Patrick

----- Original Message -----
From: "Jason van Zyl" <ja...@ze...>
To: <ebx...@li...>
Sent: Thursday, March 27, 2003 11:43 PM
Subject: Re: [ebxmlms-develop] Setup of ApplicationContexts


> On Thu, 2003-03-27 at 10:35, Jason van Zyl wrote:
> > Hi,
> >
> > Is there a standard way to setup ApplicationContexts for the server?
> >
> > If a client application has not register an application context will the
> > server still accept messages and store them?
> >
> > Say we have trading partner A and B. For A the server is alive and
> > receives a message from B. If B has not set itself up with the server
> > will the server still receive and store the messages?
>
> Sorry, that should have been: if server A receives a message from server
> B but client A has not registered an application context with server A
> will server A still receive and store the message that was sent from
> server B?
>
> --
> jvz.
>
> Jason van Zyl
> ja...@ze...
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
>   -- Jacques Ellul, The Technological Society
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

Re: [ebxmlms-develop] Setup of ApplicationContexts

[Jason v. Z. <ja...@ze...>]

On Thu, 2003-03-27 at 10:35, Jason van Zyl wrote:
> Hi,
> 
> Is there a standard way to setup ApplicationContexts for the server?
> 
> If a client application has not register an application context will the
> server still accept messages and store them?
> 
> Say we have trading partner A and B. For A the server is alive and
> receives a message from B. If B has not set itself up with the server
> will the server still receive and store the messages?

Sorry, that should have been: if server A receives a message from server
B but client A has not registered an application context with server A
will server A still receive and store the message that was sent from
server B?

-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

[ebxmlms-develop] Setup of ApplicationContexts

[Jason v. Z. <ja...@ma...>]

Hi,

Is there a standard way to setup ApplicationContexts for the server?

If a client application has not register an application context will the
server still accept messages and store them?

Say we have trading partner A and B. For A the server is alive and
receives a message from B. If B has not set itself up with the server
will the server still receive and store the messages?

-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

RE: [ebxmlms-develop] Client certificate authentication

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

I haven't been able to pick this up for the moment due to some operational
issues on other projects. Discussing this is always an option. I'll try do
put some ideas in a mail tonight (CET).

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: woensdag 26 maart 2003 6:07
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Client certificate authentication



We're going to need to be able to send client certificate authentication
from Hermes real soon now. 

If nobody has started to implement this, can we please have at least a
rudimentary discussion on how this should be done, so I can build it in for
our use without going too far off the track?

Thanks. 

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.

Re: [ebxmlms-develop] MSH v.0.9.3.0-sp1 / MySQL Bug

[Patrick Y. <kc...@ce...>]

Thank you for your note. We will modify it, and include it in 0.9.3.0 sp2
later.

We will release 0.9.3.1 soon. Actually, in every release we will perform a
number of tests. However, our testing team is small when compared with
commercial teams. So, we cannot cover all cases, e.g. MySQL. We count on
users like yourself to report problems.

Wanna use Hermes as production? Wow, we are excited about this. Here in Hong
Kong, Hermes has been deployed in several production systems. In the first
few cases, a lot of nursing is needed. Now, we have more confidence on it.
Of course, a lot of testing is recommended.

Regards, -Patrick

----- Original Message -----
From: "Jean-Baptiste Gadenne" <jbg...@re...>
To: <ebx...@li...>
Sent: Wednesday, March 26, 2003 3:30 PM
Subject: [ebxmlms-develop] MSH v.0.9.3.0-sp1 / MySQL Bug


> Hi,
>
> we are currently building an ebxml platform.
> I'm interested in your project, as it seems to be an
> excellent basis for our project.
> So I'm currently evaluating it, in order to see if it fullfull
> our requirements.
>
> Using msh 0.9.3.0 / Tomcat 4.1.18 / MySQL 4.0
> I had a error during msh initialization.
> Here is the exact error msg :
> "Cannot insert into database: New database connections created are
invalid"
>
> I had a look in DbConnectionPool.java :
> the function isValid(Connection connection) cannot work under MysQL
> as MySQL is case sensitive regarding table names.
>
> So I changed "select distinct 1 from mshconfig" with
> "select distinct 1 from MSHConfig" and it solved my problem.
>
> Hope this helps...
>
> By the way  : can we use the current version of MSH for production use
> or is it to early as it seems to be alpha state ?
>
> Tkx
>
> jb
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

[ebxmlms-develop] MSH v.0.9.3.0-sp1 / MySQL Bug

[Jean-Baptiste G. <jbg...@re...>]

Hi,

we are currently building an ebxml platform.
I'm interested in your project, as it seems to be an
excellent basis for our project.
So I'm currently evaluating it, in order to see if it fullfull
our requirements.

Using msh 0.9.3.0 / Tomcat 4.1.18 / MySQL 4.0
I had a error during msh initialization.
Here is the exact error msg :
"Cannot insert into database: New database connections created are invalid"

I had a look in DbConnectionPool.java :
the function isValid(Connection connection) cannot work under MysQL
as MySQL is case sensitive regarding table names.

So I changed "select distinct 1 from mshconfig" with
"select distinct 1 from MSHConfig" and it solved my problem.

Hope this helps...

By the way  : can we use the current version of MSH for production use
or is it to early as it seems to be alpha state ?

Tkx

jb

Re: [ebxmlms-develop] FYI: Tomcat 4.1.24 released

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Tomcat 4.1.24 has been released. Will Hermes be tested against this version,
> or will you be sticking with 4.0.6 and/or 4.1.18 for now?

        I just change my Tomcat to 4.1.24 LE and find no problem in
deployment and execution. I think if a particular release of the app
server being used does not have serious bug, Hermes should now work
in both 4.0.x and 4.1.x.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] bug in Acknowledgment.java

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi Gait,

        The latest CVS contains what you want. More PartyId's with types
can be added as well.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] bug in Acknowledgment.java

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi Gait,

> while interop testing with SUN, I found a small bug in
> Acknowledgment.java. When receiving an Ack message without the From
> node in the Acknowledgment node, the Ack is not processed and an
> Exception is raised. However, the From node in the Acknowledgment node
> is optional per ebMS2, see diff below for a fix.
>
> Looking a bit further, I think the Acknowledgment node can have
> multiple party id's just like in the header, so the Acknowledgment class
> should support it in the same way as in the header, but that's for
> another day I guess.

        Thanks. I will fix it soon.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

[ebxmlms-develop] bug in Acknowledgment.java

[Gait B. <gai...@ti...>]

Hi team,

while interop testing with SUN, I found a small bug in =
Acknowledgment.java.
When receiving an Ack message without the From node in the =
Acknowledgment node, the
Ack is not processed and an Exception is raised. However, the From node =
in the Acknowledgment node is optional per ebMS2, see diff below for a =
fix.

diff -r1.5 Acknowledgment.java

179a180

> /* GBM 20-3-2003: From is optional

185a187,190

> */

> else {

> fromPartyId =3D null;

> }



Looking a bit further, I think the Acknowledgment node can have multiple =
party id's just like in the header, so the Acknowledgment class should =
support it in the same way as in the header, but that's for another day =
I guess.

regards, Gait.

Re: [ebxmlms-develop] SOAPException: Unable to internalize messag e (Invalid Content-Typ e:text/html)

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] SOAPException: Unable to internalize messag e =
(Invalid Content-Typ e:text/html)Peter,

Please get CVS to work in your place. It worths. :-)

A. We change the class =
hk.hku.cecid.phoenix.message.transport.HttpServlet. When it is about to =
send the SOAP message out, we modify the content type header to make it =
a single line. Here is the trick: don't call saveChanges() to the SOAP =
message. Calling saveChanges() will make the library generate a wrapped =
header again.

B. Sorry my bad English sometimes causes misunderstanding. Deployment is =
OK. But according to our experiment, when Websphere receives a HTTP =
request with wrapper header, it will generate a 400 Bad Request response =
to the sender.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 21, 2003 6:21 AM
  Subject: RE: [ebxmlms-develop] SOAPException: Unable to internalize =
messag e (Invalid Content-Typ e:text/html)


  Doh! :-)=20

  CVS? Used it a long time ago, can't remember how it works, and I =
probably couldn't get it through our firewall if I could.

  As a matter of interest,=20

  a) where did you make the change (not that it matters)=20
  b) why does producing a wrapped header stop deployment into WebSphere =
Application Server?=20

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

  -----Original Message-----=20
  From: Patrick Yee [mailto:kc...@ce...]=20
  Sent: Thursday, 20 March 2003 8:54 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] SOAPException: Unable to internalize =
messag e (Invalid Content-Typ e:text/html)=20



  Peter,=20

  Thank you for your note.=20

  Please check out the latest CVS source tree and try again. We have =
committed the change to make the Content-Type not wrapped. What a =
coincident! We have made the change to get Hermes deployable in =
Websphere.

  Regards, -Patrick=20

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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.