Le principe de l’architecture REST repose sur l’utilisation du protocole http en tirant partie de son enveloppe et de ses en-tête sans ajout de surcouche. Ce paradigme d’architecture se veut parfaitement stateless et laisse donc le soin au client de gérer les sessions (cf. http://fr.wikipedia.org/wiki/Representational_State_Transfer)

Dans cet article nous présupposons que ce type architecture est en place , l’objectif étant de montrer comment il est possible de sécuriser ce type d’architecture en tirant partie des fonctionnalités du http sécurisé avec un cryptage SSL basé sur un algorythme de cryptage RSA.

Vision globale de l’architecture

Dans notre architecture nous avons un client qui va consommer un service REST hébergé sur un server Tomcat. L’application est découpé en 4 couches:

-GATEWAY: Cette couche represente l’interface public d’exposition des services en REST avec les verbes get, post, put, delete permettant respectivement de de faire de la lecture, ajout, modification, suppression.
-SERVICE: Cette couche représente les services de haut niveau et gère donc l’initialisation des transactions et si besoin la gestion des rôles en fonction des besoin de l’application
-BUSINESS: Cette couche représentes les services métier de granularité plus fine qui seront orchestrés par la couche de service
-DAO: Cette couche est une abstraction entre les objet du domaine et les différents supports de persistence

Description de l’échange SSL

1. Le client fait une demande de transaction sécurisé au serveur en envoyant une requête https sur le port 8443. De cette façon il demande le certificat du serveur garantissant la clé publique du serveur.
2. Le serveur lui envoie son certificat d’authentification. Ce certificat comprte une clé publique.
3. Le client s’assure de la validité du certificat puis il envoie au serveur une clé codée à partir de la clé publique. Seul le serveur est donc capable de décoder cette clé à partir de sa clé privée. Cette clé sera ensuite utilisée pour encoder les messages.
4. Le serveur et le client possèdent maintenant la clée partagée (clé de session) et les échanges se font par l’intermédiaire de cette clé.

Mise en place du cryptage ssl

3 étapes sont nécéssaires à la mise en place d’un échange sécurisé.

1- Génération des clés :

Le client et le serveur étant écrit en Java, nous utiliserons l’outil KeyTool fourni par l’api java (cf. http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html).

Voici la procedure de création des clés, certificats, trustore et keystore :

Tips :

Remplacer les éléments suivants par votre config specifique puis utiliser le script:

<server alias (e.g serverkey)>
<ip server (e.g. localhost)>
<organisation unit (e.g. OpenSides Architecture Labs)>
<organisation name (e.g. OpenSides)>
<city (e.g. Paris)>
<country (e.g. Paris)>
<password>
<server keystore name (e.g server.jks)>
<client keystore name (e.g client.jks)>
<client alias (e.g clientkey)>
<client cert alias (e.g clientcert)>
<server alias (e.g serverkey)>
<server cert alias (e.g servercert)>
<client certificat name (e.g. client-public.cer)>
<server certificat name (e.g. server-public.cer)>

#Generate server keystore (CN must contains server IP):
keytool
-genkeypair
-alias <server alias (e.g serverkey)>
-keyalg RSA
-dname "CN=<ip server (e.g. localhost)>,
OU=<organisation unit (e.g. OpenSides Architecture Labs)>,
O=<organisation name (e.g. OpenSides)>,
L=<city (e.g. Paris)>,S=<country (e.g. Paris)>,
C=<code country on 2 digit (e.g. FR)>"
-keypass <password>
-storepass <password>
-keystore <server keystore name (e.g server.jks)>

#Generate client keystore (CN must contains client IP):
keytool
-genkeypair
-alias <client alias (e.g clientkey)>
-keyalg RSA
-dname "CN=<ip client (e.g. localhost)>,
OU=<organisation unit (e.g. OpenSides Architecture Labs)>,
O=<organisation name (e.g. OpenSides)>,
L=<city (e.g. Paris)>,S=<country (e.g. Paris)>,
C=<code country on 2 digit (e.g. FR)>"
-keypass <password> -storepass <password>
-keystore <client keystore name (e.g client.jks)>

#Export the Client’s Public Certificate:
keytool
-exportcert
-alias <client alias (e.g clientkey)>
-file <client certificat name (e.g. client-public.cer)>
-keystore <client keystore name (e.g client.jks)>
-storepass <password>-noprompt

#Import the Client’s Public Certificate in to the Server’s Keystore:
keytool
-importcert
-keystore <server keystore name (e.g server.jks)>
-alias <client cert alias (e.g clientcert)>
-file <client certificat name (e.g. client-public.cer)>
-storepass <password>-noprompt

#View the contents of the keystore (use -v for verbose output):
keytool
-list
-keystore <server keystore name (e.g server.jks)>
-storepass <password>

#Export the Server’s Public Certificate:
keytool
-exportcert
-alias <server alias (e.g serverkey)>
-file <server certificat name (e.g. server-public.cer)>
-keystore <server keystore name (e.g server.jks)>
-storepass <password>
-noprompt

#Import the Server’s Public Certificate in to the Client’s Keystore:
keytool
-importcert
-keystore <client keystore name (e.g client.jks)>
-alias <server cert alias (e.g servercert)>
-file <server certificat name (e.g. server-public.cer)>
-storepass <password>
-noprompt

# view the contents of the keystore (use -v for verbose output):
keytool
-list
-keystore <client keystore name (e.g client.jks)>
-storepass <password>

2- Configuration  de Tomcat :

Configurer le fichier server.xml pour activer le connecteur https :

<Connector
 clientAuth="true"
 port="8443"
 scheme="https"
 secure="true"
 SSLEnabled="true"
 keystoreFile="/emplacement/du/keystore/
 <server keystore name (e.g server.jks)>"
 keystoreType="JKS"
 keystorePass="password"
 truststoreFile="/emplacement/du/keystore/
 <server keystore name (e.g server.jks)> "
 truststoreType="JKS"
 truststorePass="password"
 SSLVerifyClient="require"
 SSLEngine="on"
 SSLVerifyDepth="2"
 sslProtocol="TLS"
 />

3- Configuration du client java :

Le client java doit initialiser les propriétés système pour indiquer à la JVM ou récupérer le keystore client pour opérer à l’authentification lors des échanges.

static{

System.setProperty("javax.net.ssl.trustStore",
"/emplacement/du/keystore/<client keystore name (e.g client.jks)>");

System.setProperty("javax.net.ssl.trustStorePassword","password");

System.setProperty("javax.net.ssl.keyStore",
"/emplacement/du/keystore/<client keystore name (e.g client.jks)> ");

System.setProperty("javax.net.ssl.keyStorePassword","password");

}

Conclusion

Nous avons montré comment sécuriser notre architecture tout en respectant la philosophie RestFul. En espérant que ce post puisse vous être utile !