Single Sign-On

Transcription

Single Sign-On

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
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
1
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.
2
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.
3
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.
4
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.
5
6
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 ».
7
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 :
8
Maintenant, on va récupérer notre « cas.war » à partir d’ECLIPSE :
9
Maintenant, à partir du client cas qu’on a téléchargé on va récupérer les archives « casclient-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.
10
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 luimê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 :
11
-
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-useexamples.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 :
12
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 »
13
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 :
14
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 :
15
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éé.
16
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).
17
-
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 :
18
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:
19
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 :
20
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 :
21
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.
22
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úne telle solution sont avant tout les inconvénients dúne mise en conformité du SI de
léntreprise
Il y'a aussi la contrainte coût et lourdeur. Láffiliation dúne 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áuthentification tombe, lápplication de SSO tombe. Il est
donc préférable de mettre en place un serveur de secours.
23

Single Sign-On

Transcription

Documents pareils

CA Single Sign-On

CA Single Sign-On Implementation Services

Tableaux comparatif de solutions logiciels pour M2L

Packages de séjour et cures thermales

Packages de séjour et cures thermales Hotel Al Sole

DRIVING LICENCE Pretoria, Le Nom Prénom Addresse A Monsieur

Logiciel: Xelios VNA 5 (Virtual Network Access)

hebergement

Edition 2006 du Programme de recherche transnational en

Documentation spécifique du programme