Spring REST Service Certificate auth

Question

I have written Spring controller. This get's requests from clients. It's just REST style.

This is very good. But I need certificate authentication. Only the clients must have access to the rest service (spring controller), which have client certificates with key (In the other words client should have keystore with key).

How can I configure this security to spring? Could you give me an example or link where this is written?

Thanks

Answer 1

What you are looking for is called Mutual Authentication.

It is the servers responsibility to make/request the client to send its certificate. Each server does this differently and you'll have to look up how to configure your particular server.

For Spring Security, I would recommend looking into X.509 Authentication. This type of authentication is fairly easy to use and extend as needed.

EDIT

So, here are a couple of references that show examples of what you are asking:

http://whiteycode.blogspot.com/2012/04/part-3-x509-authentication-with-spring.html

PDF Warning

http://www.promixis.com/pdfs/SpringSecurityAndX509ClientCertificates.pdf

The above pdf file is no longer reachable...

This example is really good about explaining how to setup your certificates and creating your own personal CA (Certificate Authority). Warning, the way that they show making the client certificate is just A WAY, not the way. Your client (IE web browser or java httpclient client) should determine which way to create your client certificate. Java likes to use its java keystore of course and browsers tend to like the p12 style of certificates.

Final advice/warning... I don't know your level of knowledge with certificates, but... Mutual Authentication is all about who trusts whom. It is the severs responsibility to say, I need you to authenticate yourself with a certificate and here is a list of certificate providers I trust. It is then the clients responsibility to reply with a certificate signed by one of those server trusted certificate providers. It is the applications responsibility to then say, do I trust this person based on their name inside of the certificate? If and when things start to go wrong think about who is and or isn't trusting who.

One great tool is using -Djavax.net.debug=ssl on your application. It will show the entire ssl handshake and what is being requested and what the specific responses are. That option is a bit verbose, but it is nice to have when needed.

EDIT X 2

Here is how to enable mutual authentication on Tomcat 7.

In your server.xml config file you should see close to the following for an SSL connector:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           clientAuth="want" sslProtocol="TLS"
           keystoreFile="C:\Java\Certs\localhost.jks"
           keystorePass="changeit"
           URIEncoding="UTF-8" />

The important value to note is the clientAuth value.

Setting clientAuth to 'want' tells the client to send a signed client ssl certificate from a list of certificates that the server trusts if you have one. If not, go ahead and make your request as normal.

Setting clientAuth to 'true' tells the client that they HAVE to send a signed client ssl certificate from a list of certificates that the server trusts. If you do not have a certificate signed by a list of certificates that the server trusts, the client is NOT allowed to make the request.

The list of certificates that the server trusts either comes from the default java truststore or can be set using the -Djavax.net.ssl.trustStore="C:\Java\Certs\jssecacerts1" VM option.

Generally, when having a specific CA Certificate that you trust that isn't in the default Java truststore, the default truststore is copied, the new CA certificate is imported into the copied truststore and then used with above VM option.

WARNING

It is super important NOT to change the default Java truststore in place. If you do, all java applications by default on that machine will be using the new updated truststore. Not always what people want and can possible cause security risks.