LP Administration Réseau et Sécurité des

systèmes d’Information

202-2021

Sujet: Mise en place d’un serveur d’authentification centralisée et unique CAS

SSO

Module : ADMINISTRATION DES SERVICES RÉSEAUX

Réalisé par: -Abaamrane Naima

-Mejjani Chaimae
 Plan

 Introduction
 Le but
 CAS un SSO WEB
 L’intérêt de CAS
 Mécanisme
 Technologies utilisées
 Les authentifications
 Certificats
 Développement d’un petit client CAS (php)
 Clients
 phpCAS
 JAVA CASFilter
 Mod_auth_cas
 Pam_cas
 Installation
 Conclusion
Introduction

 La mémorisation de multiples mots de passe est devenue un problème pour les utilisateurs.
Pendant qu'un système SSO mémorise les mots de passe pour chaque application à la place des
utilisateurs, le fournisseur d'identité permettra d'étendre le champ d'action de ces utilisateurs
hors de l'entreprise.
 L'intranet est aujourd'hui une ressource informatique indispensable à une organisation et
destiné essentiellement à mettre en place les services avec conditions d'utilisation. Ainsi, la
centralisation d'authentifications est un élément important dans un intranet. Aussi, La mise en
place d'un système Single Sign-On avec fournisseur d'identité va épargner la tête des
utilisateurs en ne leur faisant mémoriser qu'un seul mot de passe et leur doigts ne seront plus
sollicités car ils ne s'authentifieront qu'une seule fois pour accéder à un nombre important
d'applications.
 En effet, la configuration des serveurs CAS est un exercice professionnel qui demande
beaucoup de compréhension en ce qui concerne le principe de fonctionnement.
Le But

 SSO
 Single Sign-On
 authentification unique et unifiée
 Sécurité
 protéger le mot de passe
 ne pas transmettre le mot de passe aux applications
 un seul point d’authentification
 Plusieurs mécanismes d’authentification
 LDAP, fichier plat, X509
 Le But
Service Service

Appli n°3 Appli n°2 Appli n°1 Appli n°3 Appli n°2 Appli n°1

Navigateur web Navigateur web

sans CAS avec CAS

CAS un SSO WEB

 Centralisation de l’authentification en un point

 Le serveur d’authentification

 Redirections HTTP transparentes

 Application vers serveur d’authentification
 Serveur d’authentification vers les applications

 Passage d’information lors de ces redirections

 Cookies
 Paramètres CGI
L’intérêt de CAS

 Le mot de passe n’est JAMAIS transmis aux applications

 Utilisation de ticket « opaque » et à usage unique (à la Kerberos)
 Mécanisme n-tiers
 Utilisation de services à travers des applications clientes sans transmission du mot de passe
 Librairies clientes
 Java filter, jsp, php, perl, python. Dot net, module Apache et PAM
 Mécanisme
1ère authentification d’un utilisateur
 Mécanisme
1ère authentification d’un utilisateur

•TGC : Ticket Granting Cookie

• Passeport du navigateur auprès du serveur CAS
• Cookie privé et protégé (le seul cookie utilisé dans
CAS ;
il n’est pas obligatoire)
• Ticket opaque rejouable
 Mécanisme
Accès à une application (après authentification)

ST : Service Ticket
Passeport du navigateur auprès
du client CAS
Ticket opaque non rejouable
Limité dans le temps
 Mécanisme
Accès à une application (après authentification)

Toutes les redirections sont

transparentes pour l’utilisateur
 Mécanisme
Accès à une application (avant authentification)
 Mécanisme
Accès à une application (avant authentification)

Il n’est pas nécessaire de s’être

préalablement authentifié auprès du serveur
CAS pour accéder à une application
 Mécanisme
Remarques

 Une fois le TGC acquis, l’authentification devient transparente pour l’accès à toutes les
autres applications CAS-ifiées

 Une fois authentifié pour une application, une session applicative est mise en place
 Mécanisme
Fonctionnement n-tiers
 Mécanisme
Fonctionnement n-tiers
•PGT : Proxy Granting Ticket
– Passeport d'un utilisateur pour une
application auprès du serveur CAS
– Ticket opaque rejouable
Technologies utilisées

 JAVA
 SPRING
 REST
 HTTP
 SSL
Les authentifications
 Le choix du/des mode(s) d’authentification est laissé à l’initiative de
l’administrateur
 Configuration XML pour ajouter des « handlers » d’authentification
 Possibilité de développer ses propres couches d’authentification
Développement d’un petit client CAS Algorithme
de base
 Développement d’un petit client CAS (php)

 En cas d’erreur, CAS va répondre :

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code="...">
Optional authentication failure message
</cas:authenticationFailure>
</cas:serviceResponse>

 En cas de succès
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>NetID</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
Développement d’un petit client CAS Algorithme
de base (proxy)
 Développement d’un petit client CAS (php -
proxy)
 En cas de succès
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>NetID</cas:user>
<cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket>
</cas:authenticationSuccess>
</cas:serviceResponse>

 Lors de la demande d’un PT

<cas:serviceResponse>
<cas:proxySuccess>
<cas:proxyTicket>ST-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket>
</cas:proxySuccess>
</cas:serviceResponse>
 Utilisation de client
phpCAS

include_once('CAS.php');
phpCAS::setDebug();

// initialize phpCAS
phpCAS::client(CAS_VERSION_2_0,‘localhost',443,‘/cas');
phpCAS::setNoCasServerValidation();
phpCAS::forceAuthentication();
if (isset($_REQUEST['logout'])) {
phpCAS::logout();
}
?>
<h1>Successfull Authentication!</h1>
<p>login is <b><?php echo phpCAS::getUser();
 Utilisation de client
Java CAS Filter

 Le client CAS Java existe sous forme de filter

 4 filtres
 CASFilter : va gérer l’authentification
 CASValidation: va gérer la validation des tickets
 CASWrapper : va mettre à disposition le username dans le remoteuser
 CAS Single Sign Out Filter : va gérer les requêtes de logout
 Utilisation de client
mod_auth_cas

 Mod_auth_cas est un module apache

LoadModule auth_cas_module /usr/lib/apache2/modules/mod_auth_cas.so

<IfModule mod_auth_cas.c>
CASVersion 2
CASDebug Off
CASValidateServer Off
CASLoginURL https://localhost/cas
CASValidateURL https://localhost/cas/serviceValidate
CASCookiePath /tmp/cas/
CASTimeout 7200
CASIdleTimeout 3600
CASCacheCleanInterval 1800
</IfModule>
 Utilisation de client
pam_cas

 Pam_cas est un module pam

 PAM : Pluggable Authentication Modules
 Peut servir pour des accès à des services linux (FTP, IMAP, etc…)
 Utilisation de client
pam_cas

 /etc/pam.d.imap

auth sufficient /lib/security/pam_cas.so \-simap://imap.univ.fr \-f/etc/pam_cas.conf

auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_pwdb.so shadow nullok
account required /lib/security/pam_pwdb.so shadow nullok

 /etc/pam_cas.conf

host localhost
port 443
uriValidate /proxyValidate
ssl on
debug off
proxy https://localhost/casProxy.php
trusted_ca /Cert/ac-racine.pem
Installation
Nous avons besoin de certaines conditions pour exécuter CAS :

 Java - Vous avez besoin de JDK 11+, installez s'il n'est pas installé auparavant et

définissez JAVA_HOME sur l'endroit où Java a été installé.

 Git — Vous avez besoin de git pour cloner le modèle de superposition CAS, ce n'est pas

obligatoire, mais je suggère de l'utiliser.

Maintenant, nous devons cloner le référentiel Github quelque part sur le système :
git clone https://github.com/apereo/cas-overlay-template

Après le clonage, pour exécuter CAS, nous devons configurer certaines choses

essentielles. Commencez par éditer le fichier cas.properties dans le dossier

{project_root}/etc/cast/config. Définissez « cas.server.name » sur localhost (https), et

ajoutez « server.ssl.key-store » et « server.ssl.key-store-password ». Nous allons ensuite

créer le fichier "thekeystore".
cas.server.name=https://localhost:8443
cas.server.prefix=${cas.server.name}/cas
server.ssl.key-store=file:/etc/cas/config/thekeystore
server.ssl .key-store-password=changerlogging.config=fichier:/etc/cas/config/log4j2.xml#
cas.authn.accept.users=
Ouvrons un terminal et accédez à {project_root}/etc/cas/config. Exécutez cette commande
et entrons localhost pour la question sur le prénom et le nom :

keytool -genkey -keyalg RSA -alias thekeystore -keystore thekeystore -storepass changeit -validity
360 -keysize 2048

Cette commande créera un fichier "thekeystore". Veuillons noter que vous devez saisir
« localhost » pour le prénom et le nom afin d'éviter les erreurs SSL lors de l'exécution de la
gestion CAS et d'autres applications clientes. Nous devons maintenant importer ce fichier

dans le JDK à utiliser pour les applications clientes. (Remarque sur la variable

d'environnement JAVA_HOME, vous devez l'avoir définie auparavant)

keytool -importkeystore -srckeystore thekeystore -destkeystore

$JAVA_HOME/lib/security/cacerts

Après l'importation, nous devons redémarrer toutes les instances Java en cours
d'exécution ou redémarrer le système.

Ensuite, installons toutes les dépendances et construisez CAS (cette commande copiera les

fichiers de configuration de {project_root}/etc/cas/config dans le dossier /etc/cas/config de

le système d'exploitation, assurons que vous avez l'autorisation de créer et d'écrire dans ce
dossier .)
./gradlew clean copyCasConfiguration build

Nous pouvons maintenant exécuter le CAS et le tester.

./gradlew run

Après avoir vu ça :
Le serveur CAS est prêt, nous pouvons y accéder sur le système local

: http://localhost:8443/cas/ . Peut-être que nous obtenons une erreur SSL lorsque nous
ouvrons cette URL.

Vous pouvez voir la page de connexion du CAS. Il existe un utilisateur par défaut que vous
pouvez utiliser pour vous connecter. Entrez « casuser » comme nom d'utilisateur et « M ellon
» comme mot de passe.
Charger des utilisateurs à partir d'une base de données :

CAS prend en charge de nombreuses manières différentes d'authentifier les utilisateurs, par

exemple LDAP, X.509, Azure Active Directory, REST, Redis, Database et bien d'autres. Nous
allons configurer une base de données PostgreSQL comme source qui sera utilisée par CAS
pour authentifier les utilisateurs.

Pour activer l'authentification de la base de données, nous devons ajouter la dépendance

suivante à la superposition de guerre. Pour cela, éditez le {project_root}/build.gradle et

ajoutez cette ligne dans la section des dépendances (où se trouve cette ligne « // D'autres
dépendances/modules CAS peuvent être répertoriés ici… ») :
implémentation "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
implémentation "org.apereo.cas:cas-server-support-jdbc-drivers:${project.' cas.version'}"
Nous devons créer une table dans postgres pour stocker les informations de
l'utilisateur. Vous pouvez utiliser cette requête pour créer la table à tester. Nous insérons
également un utilisateur pour le test (email/nom d'utilisateur : '[email protected]', mot de
passe : 'testpass' qui est encodé par l'algorithme bcrypt)
CREATE TABLE utilisateurs
(
id bigint NOT NULL,
booléen désactivé,
caractère d'e - mail variant (40) COLLATE pg_catalog."default",
first_name caractère variant (40) COLLATE pg_catalog."default",
last_name character variant (40) COLLATE pg_catalog."default" ,
booléen expiré,
caractère de mot de passe variable (100) COLLATE pg_catalog."default",
CONSTRAINT users_pkey PRIMARY KEY (id),
CONSTRAINT uk6dotkott2kjsp8vw4d0m25fb7 UNIQUE (email)
)
WITH (
OIDS = FALSE
);INSERT INTO users(
id, disabled, email, first_name, last_name, expiré, mot de passe)
VALUES (1, false, ' [email protected] ', 'test', 'user1', false,
'$2y$12$7XQUDwK3QE7oBB0wmVpht.aT7gJESI205SgWar2 .');
Conclusion

 Comme le SSO donne accès à de nombreuses ressources, une fois l'utilisateur authentifié,
il a les "clés du château". Les pertes peuvent être lourdes si une personne mal intentionnée
a accès à des informations d'identification des utilisateurs. Avec le SSO, une attention
particulière doit donc être prêtée à ces informations, et des méthodes d'authentification
forte devraient idéalement être combinées.
 Nous avons remarqué des difficultés en terme de ressource pour la réalisation de ce projet
car la partie pratique a été échouée au niveau de notre machines .