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