Protéger ses applications JEE avec OpenAM

A travers cet article, nous verrons comment protéger plusieurs applications web avec une solution SSO. Le SSO (“Single Sign On”) ou authentification unique permet à un utilisateur de ne s’authentifier qu’une seule fois pour accéder à plusieurs applications. Souvent intégré dans des solutions de type IAM (Identity Access and Management), ces solutions ont pour vocation de protéger les applications d’un SI en garantissant un accès surveillé et contrôlé des ressources et des utilisateurs.

Le SSO améliore autant la sécurité que le confort des utilisateurs. Premièrement, l’ensemble du système d’authentification est centralisé, garantissant ainsi une cohérence d’ensemble sur un SI. De plus, tous les accès sur ce dernier sont obligatoirement contrôlés puisqu’ils “passent” au même endroit. Nous verrons par la suite que nous pourrons gérer les accès en fonction des applications, des utilisateurs, des droits, de règles (partie plus orienté IAM). Enfin, l’utilisateur n’a pas à retenir de nombreux mots de passes, ni à le saisir à chaque accès.

OpenAM

Présentations

Pour intégrer le SSO, nous avons utilisé OpenAM (dans l’exemple ci-dessous) qui permet :

• un système de gestion des identités et de contrôle des accès en open source,
• une plate-forme serveur de fédération d’identités.

Ce produit est distribué par ForgeRock.

Issu d’OpenSSO (Oracle), OpenAM est écrit en Java et fait donc partie plus largement des solutions IAM (Identity Access and Management).

Fonctionnement

Voici un exemple d’architecture que l’on peut trouver facilement en entreprise et qui correspond entre autres à notre problématique SSO.

Comme on peut le voir dans ce schéma, nous avons des utilisateurs qui accèdent à diverses applications réparties sur des serveurs Tomcat/JBoss différents (1)(2)(3). Comme on peut le voir sur chaque serveur d’applications nous avons un agent qui va communiquer avec le serveur Tomcat/JBoss (0) qui contient la partie Serveur d’OpenAM (un war).

Kezako qu’un agent ? => L’agent est mini-applicatif (un war et quelques fichiers de configurations) qui est déployé sur le serveur à protéger et qui assure l’échange des informations entre OpenAM et les applications.

Il existe différents types d’agent :

• Web,
• J2EE,
• Fournisseur de services Web,
• Client de service Web,
• Client STS,
• Agents 2.2,
• Authentificateur d’agent,

Dans notre cas, nous travaillons avec des agents J2EE.

Afin de comprendre au mieux les interactions durant l’accès aux ressources, voici un schéma :

• Étape 0 : Un utilisateur souhaite aller sur une application,
• Étape 1 : Son appel est intercepté par l’agent,
• Étape 2 : Ce dernier initie une demande au serveur OpenAM,
• Étape 3 : Le serveur lui retourne l’autorisation ou non d’aller sur l’application*1,
• Étape 4 : L’agent récupère cette information et route l’utilisateur la page qui convient : Page de login ou d’accueil (si l’utilisateur s’était déjà authentifié auparavant via l’accès à cette ressource ou une autre ressource gérée par notre serveur c).

*1 : il convient de préciser que notre serveur OpenAM peut aller rechercher des utilisateurs dans différents types de Magasin de données : LDAP, Active Directory, Data Store, etc.. L’ “important” étant de bien dissocier les données de configuration et les données utilisateurs dans deux entrepôts de données différents.

L’authentification unique se base sur des cookies sur la machine cliente. Ainsi, certaines informations envoyées par le serveur sont stockées sur ces cookies qui sont créés et mis à jour lors des échanges client serveur. Cela permet surtout au serveur d’identifier les appels venant de la même machine cliente. A chaque appel, ce(s) cookie(s) est(sont) utilisé(s) jusqu’à son(leur) expiration par timed out ou par logout. Afin de réaliser cela, les cookies contiennent le sessionID (et autres informations) qui identifie le client et ses informations côté serveur lors des différentes interactions entre le serveur et le client. Dans le cadre d’un processus complet d’authentification, plusieurs cookies sont effectivement utilisés :

AMAuthCookie : Ce cookie est utilisé au début du processus d’authentification et abandonné dès lors que l’utilisateur réussit à se connecter.
iPlanetDirectoryPro : Dès que l’utilisateur se connecte correctement, ce cookie est utilisé afin de permettre au client d’accéder aux différentes ressources autorisées.
Et autres (en fonction de la configuration du serveur) : amlbcookie01, DProPCookie…

OpenAM permet de gérer les authentifications sur des applications sur un même domaine (DNS) mais aussi sur des domaines différents (au sein d’une même organisation) aussi, cela se nomme le CDSSO (Cross Domain Single Sign On) :

• ipserveur1.sousdomaine1.domaine.com,
• ipserveur2.sousdomaine2.domaine.com,
• et ipserveuropenam.sousdomaine1.domaine.com.

OpenAM gère de manière transparente le transport des informations d’authentification lors de configurations CDSSO.

Par la pratique

Nous allons mettre ensemble un environnement protégé et contrôlé par OpenAM. Dans cet exemple, nous allons utiliser deux tomcat : un pour OpenAM, un pour l’application test. L’objectif étant pour nous de déporter la gestion de l’authentification dans OpenAM et de permettre à celui-ci d’instaurer des règles d’accès à notre application.

Pré-Requis

• La notion de FQDN (fully qualified domain name == le nom complet/absolu de mon hôte) est capital dans OpenAM. C’est dans ce sens que nous allons définir deux FQDN : openam.myhome.com et agent.myhome.com. En fonction de votre système d’exploitation, cela se passe dans un fichier différent : Linux et MacOS : /etc/hosts et Windows : c:\windows\system32\drivers\etc\hosts. Le premier openam.myhome.com sera destiné à l’usage du serveur OpenAM tandis que le second sera celui utilisé par l’application cliente (là ou il y a un agent qui portège).
• Java installé (1.6),
• Avoir deux Tomcat distincts,
• Avoir une application web de type J2EE à protéger.

Partie OpenAM

Obtenir OpenAM

• OpenAM étant un projet Open Source, il est possible de récupérer les sources : Guide
• Ou plus “simplement” par le site de Forgerock : OpenAM Version 9.5.3 (zip) (Release Notes : Release Notes)

(Pour obtenir un Tomcat, rendez-vous ici : Tomcat )

Installer OpenAM

• Une fois le openam_953.war (ou openam_953RC1, dans le cadre de tests, prendre une Release Candidate n’est absolument pas gênant) téléchargé, déplacer le dans votre répertoire webapps de votre premier Tomcat,
• Démarrer votre Tomcat,
• Vérifier que le déploiement n’a pas généré d’erreurs dans les logs du Tomcat :
  
• Accèder à l’url (UTILISER LES FQDNs):
  http://openam.myhome.com:9080/openam_953 ou http://openam.myhome.com:9080/openam_953RC1, vous arrivez alors sur cette page :
• Dans le cadre de nos tests, nous choisissons l’installation par défaut (très déconseillé sur un environnement autre que la dév) :
  
• L’installation est terminé :
  

Nous allons maintenant pouvoir accéder et configurer au serveur OpenAM.

Configurer OpenAM

Il faut se connecter avec le compte amAdmin, le mot de passe est celui que vous avez configuré en premier lors de l’installation par défaut :

Nous arrivons alors sur la page suivante :

Sur cette page, nous avons accès à l’ensemble de la configuration du serveur. Dans le cadre de notre démonstration, nous allons faire simple et juste protéger une application se situant sur un autre serveur. L’accès aux utilisateurs sera permis s’ils appartiennent à notre magasin de données.

Pour commencer, rendons-nous sur l’onglet “Contrôle d’accès”. Puis cliquons sur domaine de niveau supérieur. OpenAM peut gérer le SSO sur plusieurs domaines et pour chaque avoir des configurations différentes.

Nous allons créer un utilisateur de test, allons sur l’onglet Objet et créons un nouvel utilisateur :

Procédons maintenant à la configuration de notre agent. Pour cela, cliquons sur Agents, puis sur J2EE :

Créons un nouvel agent :

Notez avec attention :

• le nom de l’agent : c’est ainsi que nous nommons notre agent et que côté client nous l’appellerons,
• son mot de passe : partagé avec l’agent (le même sera à utiliser lors de l’installation de l’agent sur le Tomcat client via un fichier à supprimer dès que l’agent est configuré des deux côtés),
• la configuration centralisé qui signifie que l’ensemble du paramètrage de l’agent sera porté par le serveur,
• les URLs serveur et d’agent.

L’agent est créé :

Toutefois, nous allons modifier quelques valeurs :

Dans l’onglet Global, partie Général, nous allons changer le mode de filtre afin de ne laisser passer que les gens existant dans notre magasin de données et tentant d’accèder à la ressource demo :

Dans l’onglet SSO, partie SSO inter domaine,

Puis dans la partie CD SSO, il faut activer cela et ajouter notre fqdn client :

Nous avons configuré notre agent côté Serveur mais côté client toujours rien et c’est pour cela que nous pouvons toujours y accéder sans être “intercepté” par OpenAM. Avant de poursuivre, quelques explications, il est important de noter :

• Nous avons configuré le nom de l’application protégé : “demo” en mode “SSO_ONLY” : il faut appartenir aux users OPENAM pour se connecter à toutes les ressources protégées (Mettre seulement SSO_ONLY dans la valeur protège toutes les applications du serveur client dans ce mode),
• Nous avons configuré le SSO Interdomaine (puisque finalement openam.myhome.com et agent.myhome.com pointent sur le même),
• Nous avons configuré l’asymétrie d’horloge (ne sert à rien si tout est sur la même machine puisque l’heure des clients/serveurs sera la même.),
• Nous avons configuré le CD SSO pour l’exemple (exemple si openam.myhome.com et agent.myhome.com pointaient sur des domaines différents, exemple : openam.myhome.com et agent.yourhome.com),
• Et Nous avons configuré la liste de tous les domaines CD SSO : openam.myhome.com, agent.myhome.com (si nous voulions faire une configuration CD SSO).

Il faut redémarrer le serveur OpenAM car certaines de nos modifications ne sont pas prises à chaud.

Partie application

Note : Protéger un Tomcat entier ou juste une application

Avant cela vérifions toujours que l’application cliente est toujours accessible sans authentification :

Obtenir un agent

Il faut se rendre ici et télécharger la version idoine : OpenAM
Dans la partie qui nous concerne : “Download Stable J2EE Policy Agents”, nous téléchargeons la version Tomcat.

Installer notre agent

Ensuite, nous dézippons l’installeur à côté de nos Tomcat. Nous lançons la commande agentadmin –install à partir du sous répertoire bin de l’installeur. Voici les configurations que j’ai choisis :

Une fois sur de vos configurations, veuillez choisir 1 à ce niveau.
Bien entendu, il est important d’avoir son serveur OpenAM démarré à ce niveau mais pas le serveur contenant l’application cliente.

• Tomcat Server Config Directory : Répertoire où se trouve la conf du Tomcat : \conf,
• OpenSSO Server URL : URL du serveur OpenAM : http://openam.myhome.com:9080/openam_s953RC1/,
• CATALINA_HOME / TOMCAT_HOME : Répertoire principal du Tomcat,
• Tomcat global web.xml filter install : true (faut-il protéger toutes les ressources sur le Tomcat (cela va modifier le web.xml de tomcat pour y insérer un filter SSO),
• Agent URL : URL de l’agent => http://agent.myhome.com:9081/appAgent,
• Agent Profile name : Nom de l’agent => agentj2ee (le même nom que celui choisi côté serveur),
• Agent Profile Password file name : chemin du fichier contenant le mot de passe de notre agent (peut être supprimé par la suite).

L’installation se poursuit alors en mettant à jour votre Tomcat contenant l’application cliente. Attention, j’ai choisis de protéger tout le Tomcat.
Suite à cela, vous pouvez redémarrer votre Tomcat client. Lors de l’accès à votre application, vous êtes interceptés par l’agent qui vous redirige vers la page d’authentification d’OpenAM. Vous pouvez ainsi vous logguer avec l’utilisateur créé précédemment.

L’authentification réussit et vous avez donc accès à l’application cliente :

Comme tout le Tomcat est protégé, l’accès à une autre ressource est donc interdit :

Note : Sur des JBoss des fichiers dans le répertoire de l’installeur sont à ajouter dans le répertoire conf du jboss, il s’agit de :
/NuméroAgent/OpenSSO*.properties
/NuméroAgent/locale/*.*

Ressources

Livre : OpenAM vu par Indira Thangasamy

Pour vos questions et remarques : François Descamps