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