Single Sign-On

MOHAMED OUSSAMA NEJI (RT4)

YOUSSEF BEN DHIAF (GL3)

MOHAMED AYMEN KARMOUS (RT2)

TEISSIR BEN SIDHOUM (MPI)

FOUED RKHAIES (RT4)

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

1

Table des matières I. Présentation de l’atelier .................................................................................................... 2

II. Présentation des outils utilisés .......................................................................................... 3

1. Eclipse : .......................................................................................................................... 3

2. CAS : ............................................................................................................................... 3

3. TOMCAT : ....................................................................................................................... 4

4. JDK : ............................................................................................................................... 4

5. Xerces : .......................................................................................................................... 4

6. Navigateur Mozilla Firefox :........................................................................................... 5

III. Topologie du réseau ...................................................................................................... 5

IV. Configuration des outils ................................................................................................ 7

V. Un scénario de test .......................................................................................................... 13

1. Test http : .................................................................................................................... 13

2. Test https : ................................................................................................................... 15

3. SSO externe : ............................................................................................................... 18

VI. Conclusion ................................................................................................................... 23

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

2

I. Présentation de l’atelier

Avec un nombre croissant d'applications à leur disposition, et donc avec autant de mots de

passe à mémoriser, les utilisateurs font de leur mieux : ils inscrivent ces codes secrets dans

leur agenda papier, les notent sur des Post-it qu'ils collent autour de leur écran ou, plus

simple, laissent leurs connexions ouvertes lorsqu'ils quittent leur poste de travail. Et ce, afin

de ne pas avoir à répéter le rituel quotidien de l'accès sécurisé à leurs applications.

Pour juguler cette prolifération de mots de passe, un remède existe : le Single Sign-On (SSO).

L’authentification unique (SSO) est un procédé d’identification qui permet à un utilisateur de

saisir une seule fois son nom d’utilisateur et son mot de passe pour accéder à de multiples

applications.

Vous n’avez plus besoin de vous souvenir de vos multiples noms d'utilisateur et mots de

passe. La suppression de cet obstacle technique vous permet de vous concentrer

directement sur votre travail. Économisez vos clics – ce qui, sur le long terme, vous fera

gagner beaucoup de temps – et réduisez les risques d'erreur humaine.

Il ne vous est plus nécessaire de vous souvenir de vos multiples mots de passe

Connexion Simple via votre navigateur

Réduction du risque de fuite de données liées aux systèmes de gestion

d’authentification.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

3

II. Présentation des outils utilisés

1. Eclipse :

Eclipse est un IDE, Integrated Development Environment (EDI environnement de

développement intégré en français), c'est-à-dire un logiciel qui simplifie la programmation

en proposant un certain nombre de raccourcis et d'aide à la programmation. Il est développé

par IBM, est gratuit et disponible pour la plupart des systèmes d'exploitation.

Parmi ses concurrents, on trouve NetBeans (http://www.netbeans.org), gratuit et développé

par Sun, IDEA de JetBrain (http://www.jetbrains.com) qui est payant.

2. CAS :

CAS est un système d'authentification initialement créé par l'Université de Yale pour fournir

un moyen fiable d'authentifier un utilisateur pour une application. CAS est devenu un projet

JASIG en Décembre 2004.

Le projet nous permet également de bénéficier du SSO: l'authentification unique pour les

web services authentifiés par ces soins.

Le CAS est un composant (ensemble de servlets Java) à déployer sur un serveur d'application

Java.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

4

Parmi ses concurrents, on trouve Kerberos : un protocole d'authentification réseau qui

repose sur un mécanisme de clés secrètes (chiffrement symétrique) et l'utilisation de tickets

3. TOMCAT :

Apache Tomcat est un conteneur web libre de servlets et JSP Java EE. Issu du projet Jakarta,

c'est un projet principal de l’Apache Software Foundation. Il implémente les spécifications

des servlets et des JSP du Java Community Process, est paramétrable par des fichiers XML et

de propriétés, et inclut des outils pour la configuration et la gestion. C’est un serveur léger,

gratuit, libre, multiplateforme et assez complet pour ce que nous allons aborder.

Parmi ses concurrents, on trouve JBoss Application Server (ou WildFly) est un serveur

d'applications Java EE Libre entièrement écrit en Java, publié sous licence GNU LGPL.

4. JDK :

Le Java Development Kit (JDK) désigne un ensemble de bibliothèques logicielles de base

du langage de programmation Java, ainsi que les outils avec lesquels le code Java peut être

compilé, transformé en bytecode destiné à la machine virtuelle Java.

5. Xerces :

Xerces est un ensemble de bibliothèques logicielles pour lire et traiter les informations au

format XML, il fait partie des logiciels de l'Apache Software Foundation.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

5

Les langages de programmation sont notamment java (bibliothèque format .jar), C++ et Perl.

Parmi les standards mis en œuvre, il y a DOM et Simple API for XML.

6. Navigateur Mozilla Firefox :

Bien évidemment qui dit application web dit navigateur, Mozilla Firefox est un navigateur

Web libre et gratuit, développé et distribué par la Mozilla Foundation avec l'aide de milliers

de bénévoles grâce aux méthodes de développement du logiciel libre/open source et à

la liberté du code source.

III. Topologie du réseau

Lorsqu'un client qui s'est authentifié sur une première application essaye d'accéder au

contenu protégé d'une deuxième application, celle-ci va réagir de la même manière que la

première, à savoir qu'elle va le rediriger sur le serveur CAS avec son serviceID en paramètre.

Le serveur CAS va alors observer que le client possède un cookie sécurisé CASTGC. Si celui-ci

est valide, il va en extraire l'identifiant de l'utilisateur. Du coup il va considérer celui-ci

comme déjà authentifié et sauter l'étape de l'affichage de la mire d'authentification.

La conséquence, c'est que dans le cas nominal, le client ne va même pas se rendre compte

qu'il a été redirigé vers le serveur CAS. Après deux redirections successives, il accédera au

contenu protégé de la deuxième application sans avoir eu à rentrer à nouveau son login et

son mot de passe utilisateur.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

6

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

7

IV. Configuration des outils 1. Télécharger et installer le JDK.

2. Télécharger la dernière version de TOMCAT et décompresser la dans le fichier

d’installation.

3. Télécharger un client cas à partir de http://downloads.jasig.org/cas-clients/ (la

version 3.2.1).

4. Télécharger xerses2 pour java à partir de

http://xerces.apache.org/mirrors.cgi#binary (la version 2.11.0).

5. Télécharger, installer et lancer Eclipse :

On commence par l’ajout d’un nouveau serveur Apache TOMCAT :

Bouton droit dans la fenêtre des serveurs, « New » puis « Server ».

Si la fenêtre des servers n’est pas affichée automatiquement : cliquer sur « Window »,

« Show View », « Other » puis « Server ».

Ajouter le chemin de votre installation d’apache TOMCAT en appuyant sur « Add ».

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

8

Le nouveau serveur TOMCAT est ajouté à la liste des serveurs.

Maintenant, on va préparer notre projet :

Extraire le contenant de l’archive du serveur CAS téléchargé et naviguer dans le dossier

« modules » jusqu'au ficher « cas-server-webapp-VERSION.war ». On va Renommer le fichier

simplement en « cas.war ».

On va mettre en place 3 applications qui utilisent le serveur CAS pour l’authentification

La configuration de WEB.xml de chaque application :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

9

Maintenant, on va récupérer notre « cas.war » à partir d’ECLIPSE :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

10

Maintenant, à partir du client cas qu’on a téléchargé on va récupérer les archives « cas-

client-core-3.2.1.jar », « commons-logging-1.1.jar » et « xmlsec-1.3.0.jar » dans le dossier

« modules » et à partir de l’archive xerces on va récupérer les bibliothèques

« xercesImpl.jar » et « xml-apis.jar »

Puis on va coller ces 5 bibliothèques dans le dossier « WebContent/WEB-INF/lib » de

chacune des 3 applications.

Le résultat de cette configuration :

Serveur cas, serveur TOMCAT, 3 applications

Cette configuration est effectuée pour un test en http

Un serveur HTTP ou serveur Web, est un logiciel servant des requêtes respectant

le protocole de communication client-serveur Hypertext Transfer Protocol (HTTP), qui a été

développé pour le World Wide Web.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

11

Pour le 2eme test, on va travailler avec le https et pour cela on va mettre en place une

communication sécurisée SSL de machine à machine en Java/Java EE.

- Le SSL (Secure Socket Layer) / TLS (Transport Layer Security) est le protocole de

sécurité le plus répandu qui créé un canal sécurisé entre deux machines

communiquant sur Internet ou un réseau interne. Dans notre société centrée sur un

Internet vulnérable, le SSL est généralement utilisé lorsqu'un navigateur doit se

connecter de manière sécurisée à un serveur web.

Pour générer un certificat autosigné, on accède via un terminal au bin du fichier

d’installation du JDK ou on exécute la commande :

keytool -genkey -keyalg RSA -alias mylocaltomcat1 -keystore C:\NAGUI\keystore.jks -

validity 365 -keysize 2048 -storepass myKeystorePassword -keypass myKeystorePassword

- keytool est une clé et l'utilité de la gestion des certificats. Il permet aux utilisateurs

d'administrer leurs propres paires de clés publiques / privées et les certificats

associés à l'utilisation de l'auto-authentification (où l'utilisateur s'authentifie lui-

même / elle-même à d'autres utilisateurs / services) ou l'intégrité des données et

des services d'authentification, l'utilisation des signatures numériques. Il permet

également aux utilisateurs de mettre en cache les clés publiques (sous la forme de

certificats) de leurs pairs de communication.

En exécutant cette commande la question la plus importante parmi les questions qui vont

être posé c’est « Quels sont vos nom et prénom ? » il faut répondre : localhost

Apres l’exécution on va avoir notre keystore sous le répertoire « C:\NAGUI »

Maintenant, on va effectuer quelques changements dans le fichier web.xml du serveur

TOMCAT :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

12

- On va supprimer la redirection sur le port 8443 dans cette ligne :

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1"

redirectPort="8443" />

On trouve cette ligne de commande en commentaire par défaut :

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS" />

- On va ajouter cette ligne de commande avec les paramètres : keystoreFile et

keystorePass pour déclarer le chemin de notre certificat pour qu’il la récupère en cas

de besoin.

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="C:\PATH\TO\YOUR\keystore.jks"

keystorePass="myKeystorePassword"/>

Maintenant, on va télécharger le fichier InstallCert.java (http://java-use-

examples.googlecode.com/svn/trunk/src/com/aw/ad/util/InstallCert.java) et on l’exécute à

l’aide de la commande javac InstallCert.java

L’exécution de cette commande ajoute 4 nouveaux fichiers dans le même répertoire :

On récupère « jssecacerts » et on le place dans le dossier « jre\lib\security » du répertoire

d'installation de notre JRE de la machine qui a besoin de communiquer avec notre serveur

TOMCAT.

Pour vérifier que notre configuration a été bien effectuée, en démarrant le serveur TOMCAT, ces lignes vont être affichées dans la console :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

13

Et en ouvrant un Web Browser dans l’ECLIPSE et on mettant https://localhost:8443 on aura :

Ce qui signifie que notre configuration est bien validée.

Maintenant, on revient à nos web.xml de nos 3 applications pour changer tout ce qui est

http://localhost:8080 par https://localhost:8443

V. Un scénario de test 1. Test http :

On ajoute au serveur TOMCAT : le serveur cas et les 3 applications

Avec le bouton droit sur le serveur, « Add and Remove »

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

14

Puis, on démarre le serveur et on met l’url de notre 1ere application dans l’un de nos navigateurs « http://localhost:8080/mywebapp » :

En cliquant sur « Authentification » :

On est redirigé vers le serveur cas pour entrer le login et le mot de passe.

Dès que l’authentification est bien validée on revient vers le contexte de notre application

avec d’autres services réservés aux utilisateurs authentifiés :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

15

En essayant de s’authentifier dans notre 2eme application, on est redirigé une autre fois vers

le serveur cas pour entrer un login et un mot de passe alors que dans un contexte SSO, on

doit être authentifié automatiquement sans être redirigé vers le serveur CAS, cela est dû à

l’utilisation du protocole http qui empêche l’utilisation du cookie CASTGC avec lequel

l’authentification est partagée. Donc la sécurité du protocole CAS repose de manière

intensive sur le protocole SSL (https)

2. Test https :

En effectuant la configuration déjà citée dans la partie précédente, on démarre le serveur

TOMCAT et on accède à l’authentification de notre 1ere application :

On est redirigé vers le serveur cas pour être authentifié.

Pour notre 2eme et 3eme application, si on clique sur le bouton « Authentification » on voit

bien qu’on est déjà authentifié sans être redirigé vers le serveur cas :

Application 2 :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

16

Application 3 :

Pour la déconnexion ou logout :

Si on appui sur le bouton « Deconnexion » dans l’une des 3 applications :

On est redirigé vers le serveur cas pour effectuer le logout, cette étape peut être effectuée

sans la redirection vers une page logout.

Si on revient vers les autres applications et on actualise la page on remarque qu’on ait plus

authentifié.

Ce qui se passe dans la console :

Apres le succès de l’authentification en entrant un login et un mot de passe, un CASTGC va

être créé.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

17

Puis un « Service Ticket », « Proxy_Granting_Ticket »vont être crées. On est encore dans

l’application 1.

Le « Service_Ticket » déjà créé pour l’application 1 va être validé, puis lorsqu’on a fait un

appel pour l’authentification de notre 2eme application « mywebapp8 » un

« service_Ticket » créé et puis l’authentification doit être établie directement, donc cette

étape dans l’application 2 remplace toute la procédure d’authentification effectuée pour

l’application 1.

- Ticket-Granting Cookie(TGC) :

C'est un cookie de session qui est transmis par le serveur CAS au navigateur du client lors de

la phase de login. Ce cookie ne peut être lu / écrit que par le serveur CAS, sur canal sécurisé

(HTTPS).

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

18

- Service Ticket(ST) :

Ce ticket va servir à authentifier une personne pour une application web donnée. Il est

envoyé par le serveur CAS après que l'utilisateur se soit authentifié, et est transporté dans

l'URL.

- Proxy-Granting-Ticket(PGT) :

Il est envoyé par le serveur CAS à une application web proxy CAS disposant d'un ST valide. Ce

ticket confère au proxy CAS la possibilité de demander au serveur CAS de générer un Proxy

Ticket (PT) pour une application tierce et une personne donnée.

Pour le logout, l’action effectuée est la suppression de du cookie CASTGC.

3. SSO externe :

Supposons qu’on veut faire une authentification via un serveur externe (Linkedin) :

Si c’est notre première authentification, on sera redirigé vers le site externe pour vérifier si

l’utilisateur veut vraiment donner ses informations au serveur interne.

S’il accepte alors il reviendra au site interne et même dans la prochaine authentification il ne

sera jamais redirigé vers le site externe pour être interrogé une autre fois, c’est-à-dire, la

prochaine fois qu’il clique sur «Sign-in with serveur-externe », il va se connecter

automatiquement. Ceci ne marchera que s’il est déjà connecté dans le serveur externe bien

évidemment, sinon il sera redirigé vers la page de connexion du site externe pour

s’identifier :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

19

Une fois connecté, une clé unique sera générée qui ne sera connue que par le serveur

interne et le serveur externe.

De plus, puisque l’utilisateur a accepté l’accès du serveur interne à ses informations

contenus dans le serveur externe alors on peut afficher ces informations facilement sur le

site interne:

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

20

Si on veut se déconnecter et revenir à la page precedente:

Après déconnexion, on revient à la page dédié aux utilisateurs de LinkedIn :

On remarque qu’après déconnexion, la clé access_token a expiré ce qui est logique.

Maintenant si on veut switcher la connexion entre LinkedIn et Facebook, on obtient :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

21

Lorsqu’on recharge la page, on remarque que la clé du Facebook (access_token) a changé,

donc chaque fois qu’on charge une page, cette clé change en temps réel et même si

quelqu’un possède une clé d’un autre utilisateur, il n’a rien à faire avec puisqu’elle ne sert à

rien toute seule.

Ceci donne au SSO un avantage sur les sessions qui peuvent être interceptés et utilisés pour

se connecter par un compte qu’on n’a jamais tapé ni son identifiant ni son mot de passe.

- Créer un utilisateur à partir d’un autre utilisateur externe existant :

On peut même aller plus loin en faisant une authentification sur notre serveur web par

l’intermédiaire de cette technique en stockant les informations générales collectés, dans la

base de données de notre serveur dès la première connexion.

On peut de même associer les informations d’un compte d’un site externe (facebook,

google, linkedin, yahoo…) à un compte existant dans notre serveur, afin de se connecter plus

rapidement (il faut qu’on soit préalablement connecté sur le serveur externe utilisé dans

notre serveur). Ceci est valable même quand on oublie le mot de passe du compte dans

notre serveur, il suffit de se connecter à l’aide de l’autre compte associé sans être obligé de

taper ni l’identifiant ni le mot de passe.

- Exemple :

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

22

Lorsqu’on utilise l’authentification unique externe du site Facebook sur notre site, sachant

qu’on est déjà connecté sur Facebook, une authentification est déclenchée.

Si les informations de cet utilisateur n’existent pas dans la base de données alors un

nouveau compte est créé qui possède ces informations avec une génération d’un mot de

passe associé au compte du site interne.

Si on n’est pas connecté avec le site externe et on veut s’y connecter avec alors une page de

connexion apparaitra comme suit :

Mais si on veut se connecter par un identifiant et un mot de passe alors l’authentification

unique ne sera pas utilisée durant cette connexion (connexion par les Sessions).

Finalement on peut faire une authentification à travers le compte du site interne qui

nécessite l’identifiant et le mot de passe ou bien on peut s’en passer par l’authentification à

travers le compte du site externe qui nécessite uniquement la connexion à ce dernier.

Single Sign-On |SECURIDAY 2014 ACCESS CONTROL

23

VI. Conclusion Dans ce tutoriel nous avons montré comment mettre en place une maquette de faisabilité

du serveur CAS, et expliqué les grands principes. Chaque fois qu'un nouvel utilisateur se

connecte à une application, celle-ci le redirige sur le serveur CAS, qui lui présente un

formulaire d'authentification s'il ne le reconnaît pas, puis dans tous les cas une fois

l'utilisateur connu, redirige celui-ci vers l'application, muni d'un ticket de service. À son tour,

l'application se connecte sur le serveur CAS et lui communique le ticket de service de

l'utilisateur. Le serveur CAS renvoie alors à son tour à l'application l'identifiant unique de

l'utilisateur qui est désormais authentifié. C'est ce mécanisme qui fonde le SSO CAS, et qui

permet une authentification unique quel que soit le nombre d'applications visitées.

Donc l’SSO est une source de confort et de gain de temps pour l'utilisateur comme pour

l'administrateur, ce qu’il l’a fait une des priorités des entreprises françaises (d’après une

étude de Pierre Audoin Consultants).

Même les grands noms de l'informatique s'y sont mis:

Google: avec un compte Gmail, on peut avoir accès aux mails, à un comte YouTube

avec la même adresse mail.

Facebook: le compte Facebook est valable aussi pour Instagram.

Par ailleurs, comme toute technologie, le SSO présente un nombre important de limites.

Tout d'abord la compatibilité avec toutes les applications est loin d'être garantie. On a

besoin de développer, pour les applications non supportées, une interface permettant au

SSO d'authentifier automatiquement l'utilisateur, ce qui représente un travail qui n'est

pas des moindres.

Aussi l'intégration complète est difficile dans le SI. Les inconvénients de la mise en place

d´une telle solution sont avant tout les inconvénients d´une mise en conformité du SI de

l´entreprise

Il y'a aussi la contrainte coût et lourdeur. L´affiliation d´une application à un système de

SSO à un coût non négligeable, en termes de budget mais également au niveau des accès

serveur.

Pour finir, le SSO peut également nuire à la sécurité. Il donne accès à une multitude de

ressources une fois l'utilisateur authentifié. C'est pour cette raison qu’il est préférable de

coupler les solutions de SSO, avec un système d'authentification forte. Un autre risque est

également que si le serveur d´authentification tombe, l´application de SSO tombe. Il est

donc préférable de mettre en place un serveur de secours.