SSO

De Justine's wiki
Aller à la navigation Aller à la recherche

Single Sign-On

Liens

Panorama de solutions : <a href="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" alt="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" title="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite">http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite</a>

Présentation

Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plateforme. On peut ensuite appliquer une politique de mdp et gérer l'authentification via des protocoles normalisés et sécurisés (LDAP, Kerberos, CAS, RADIUS, etc). Le SSO est un début pour passer ensuite à l'authentification multi-facteurs. Les buts sont :

  • Amélioration de la sécurité
  • Simplifier l'utilisation
  • Faciliter les opérations pour les gestionnaires

AAA :

  • Authentification : Prouver son identité
  • Authorization : Qu'est-ce que j'ai le droit de faire
  • Accounting : Qu'est-ce que je fais

On a aussi une notion de single logout : je me peut me loguer et me déloguer de manière globale, ce qui est moins évident, parce que chaque application gère son authentification de façon globale. Il faut donc gérer une base centrale des applications qui ont une session d’authentification avec l’utilisateur et mémoriser une URL de déconnexion.–Le single logoutest complexe donc peu implémenté...

Technos utilisées

  • HTTP header : Pour les application proxifiées. On protège les apps, contrôle les urls, et on crée des variables multiples... (???) On a pas besoin de SLO.
    • <img src="/mediawiki/images/3/34/Http_header.png" _fck_mw_filename="Http header.png" _fck_mw_origimgwidth="781" _fck_mw_origimgheight="351" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />
  • SAML (Security Assertion Markup Language) :standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. SAML propose l'authentification unique (en anglais single sign-on ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois, sans pour autant que ces sites aient accès à des informations trop confidentielles. (wikipédia)
  • Authentification formulaire : Elle est utilisée par les applications sans SSO possible, ne permet pas de SLO, et lente et non recommandée. De plus, on doit stocker les mdp utilisateurs...
  • Il reste aussi CAS, OpenID, WS-federation...

LDAP

cf : <a href="Protocoles">Protocoles</a>

Un annuraire LDAP contient de nombreuses informations relatives aux personnes : compte, mdp, etc; mais aussi aux structures. Il sert au contrôle d'accès (en donnant différents droits sur différents services). Un tas de services s'appuient sur LDAP, chez Windows comme chez Unix.

Recommandations

Recommandations nationales SUPANN (juin 2003), pour que les annuaires de la communauté 'Education Recherche' partagent un modèle identique:

  • assurer l'interopérabilité des différents annuaires (ENT),
  • faciliter la mise en place d'un méta-annuaire national

LDAP a une structure arborescente :

<img src="/mediawiki/images/4/4e/Ldap_struc.png" _fck_mw_filename="Ldap struc.png" _fck_mw_origimgwidth="960" _fck_mw_origimgheight="482" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />

Exemple d'une entrée 'personnel' : 

dn: uid=declercq,ou=people,dc=univ-lille1,dc=fr
objectClass: inetOrgPerson (classe d'objet par défaut qui caractérise une personne)
  objectClass: supannPerson(recommandations SUPANN)
    objectClass: posixAccount (authentification type Unix)
      objectClass: sambaAccount (ouverture de session Windows)
        objectClass: ustlPerson (interne à l'établissement)
          objectClass: radiusProfile (authentification WiFi)
cn: Declercq Patricksn: Declercq
givenName: Patrick
uid: declercquser
Password:: {CRYPT}ZZZZZZZZZZZZZ
mail: Patrick.Declercq@univ-lille1.fr
telephoneNumber: + 33 3 20 43 44 26
supannCivilite: M.
supannAffectation: CRI – Centre de Ressources Informatiques
supannListeRouge: FALSE
  uidNumber: 6304
  gidNumber: 5000
    lmPassword: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    ntPassword: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
      ustlDepartement: CRI
      ustlRole: Correspondant annuaire de l'USTL
        radiusGroupName: personnel

Les alimentations et les màj peuvent se faire par une base (de scolarité pour les étudiants...), cela permet un changement de mdp interactif, etc. Les personnels passent par Harpège, et par le bouton "mise à jour" de la page annuaire de l'université.
Données nominatives :

 

Authentification web, SSO, fédération d'identités

<pdf>Fichier:Sso.pdf</pdf>

Il faut pouvoir gérer le contrôle d'accès aux applications web. Pour cela :

  • On veut restreindre l'accès à une partie du serveur à une population donnée

On peut identifier l'utilisateur par son IP (pas suffisant) et en l'authentifiant.

Résumé du principe, notamment avec LemonLDAP

Le principe est plutôt simple, en réalité : notre SSO va servir de proxy. L'utilisateur se connecte au SSO, et une fois que c'est fait, celui-ci le laisse accéder à la ressource demandée.

Par exemple, avec LemonLDAP, je vais m'y connecter en rentrant mes logins. Une fois que c'est fait, je vais récupérer un token qui me permet d'accéder à mon GLPI.

Apache et les modules d'auth

On peut étendre les fonctionnalités du serveur web Apache en ajoutant des modules :

Authentification et autorisation sont deux processus disjoints (cf. : le haut de la page)

Les briques d'un SSO

  • Le serveur d'authentification : c'est un élément central. Il authentifie l'utilisateur, assure la persistance de la connexion, propage l'identité vers les applications et se répose sur un ou des référentiels (LDAP, NIS...).
  • Les agents d'authentification : ils sont devant chaque ressource à protéger. Il servent d'interface entre le serveur et l'application : redirigent l'utilisateur vers le serveur d'authentification et transmettent sont identité vers l'application. Il peuvent être implémentés sous la forme de librairies clients ou de modules intégrés au serveur web.

Techniques utilisées

  • Pour la communication vers l'utilisateur distant :
    • Requêtes GET ou formulaires POST
    • Redirections
    • JS
  • Persistence des sessions:
    • Cookies !
  • Protection des échanges:
    • SSL
    • Portée et durée de validité des cookies
    • Jetons non rejouables

La gestion des sessions se fait à deux niveaux :

  • Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois
  • Avec l'agent, ce qui évite de renvoyer l'utilisateur vers le serveur à chaque requête.

Aports du SSO

On y gagne en ergonomie : On ne saisit le mdp qu'une seule fois, à un seul endroit. Il faut donc sensibiliser l'utilisateur.

On y gagne en sécurité : On limite l'accès et la circulation des mots de passe, et cela permet aussi la création d'une politique des mots de passe. Enfin, on peut étendre les mode d'authentification.

Pour les applications, on utilise les mêmes librairies d'authentification dans toutes les applications, ce qui permet de mieux les intégrer.

On a le choix, en matière de SSO : Pas de standardisation, et les besoins deviennent vite pressants. On a une multiplication des solutions, de tous types, plus ou moins sûres...

Single logout

Un utilisateur logué globalement doit pouvoir se déloguer globalement, ce qui est plus difficile que SSO à cause de la multiplication des sessions. Il faut donc gérer une base centrales des applications qui ont une session en cours. C'est une technique complexe et peu implémentée.

Ensuite...

On constate donc que les limites d'un service d'authentification apparaissent lorsque l'on veut ouvrir les portes à quelqu'un de l'éxtérieur. Comment reconnaître localement l'identité de quelqu'un qui vient de dehors?

Fédérations d'identités

SAML

  • SAML=Security Assertion Markup Language
  • Standard OASIS en 2002•Répond à un besoin d’interopérabilité
  • Echanges d’assertions de sécurité entre services
  • Indépendant des mécanismes d’authentification

Types d'assertions SAML :

  • Authentification
  • Échange d’attributs
  • Décisions d’autorisation

Liberty Alliance

  • Consortium d’industriels produisant des spécifications sur la gestion d’identités
  • S’appuie sur SAML
  • Implémenté dans de nombreux produits

Shibboleth

  • Norme et produit développé par Internet2
  • Open source
  • Première version en 200
  • •Basé sur SAML (bibliothèque OpenSAML
  • •Utilisé surtout par des universités
  • Conçu pour interconnecter les SSO des universités
  • Fonctionnalités
    • Délégation d’authentification
    • WAYF pour orienter l’utilisateur
    • Propagation des attributs utilisateur
    • Partage de méta données
    • Définition de règles de confiance

WS-Federation

  • Draft porté par Microsoft et IBM, 2003
  • Basée sur les spécifications WS-*
    • –WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange
  • Définit l’échange d’identités et d’attributs entre domaines de sécurité

ET d'autres...

OpenID <a href="http://openid.net/" alt="http://openid.net/" title="http://openid.net/">http://openid.net/</a>

  • Protocole de délégation d'authentification
  • Origine : authentification sur les blogs
  • Principe :
    • 1.Saisie de l’URI de son OpenID provider
    • 2.Redirection vers l’OpenID provider
    • 3.Authentification
  • Développement rapide de la technologie
  • Nombreux services compatibles
  • Nombreuses implémentations

Oauth <a href="http://oauth.net" alt="http://oauth.net" title="http://oauth.net">http://oauth.net</a>

  • Standard récent (version 1.0, décembre 2007)
  • Définit un standard permettant la délégation d'un utilisateur pour l'accès à un service
  • Exemple d'utilisation
    • –Un utilisateur autorise un service d'impression à accéder à ses photos sur un site de gestion de photos
  • Oauth est complémentaire de OpenID

Apports de la fédération d'identités

Pour l’utilisateur :

  • –Il n’utilise que le mot de passe de son SSO
  • –Adapté aux utilisateurs nomades

Pour l’établissement de rattachement

  • –Niveau de sécurité constant (SSO)
  • –Meilleure maîtrise des données personnelle

Pour les gestionnaires de ressources

  • –Plus besoin de gérer des comptes utilisateurs
  • –Accès à des données utilisateurs fiables

Dans la pratique

LemonLDAP-ng

<a href="https://lemonldap-ng.org/documentation/latest/start" alt="https://lemonldap-ng.org/documentation/latest/start" title="https://lemonldap-ng.org/documentation/latest/start">https://lemonldap-ng.org/documentation/latest/start</a>

LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française, en fourchant le logiciel LemonLDAP. Il fournit une solution d'authentification unique distribuée avec gestion centralisée des droits sous licence GPL. (Wikipédia).

Je pars comme toujours d'une Debian 9.

Dans l'installation suivante, il fournit deux sites web importants :

  • auth.ju.lab : pour que les utilisateurs s'authentifient
  • manager.ju.lab : interface de gestion, à protéger !

Installation et configuration

On commence par installer depuis les repos lemonldap (ert surtout pas les repos debian...) : 

vi /etc/apt/sources.list.d/lemonldap-ng.list
#Ajouter : 
# LemonLDAP::NG repository
deb&nbsp;&nbsp;&nbsp;&nbsp; https://lemonldap-ng.org/deb 1.9 main
deb-src https://lemonldap-ng.org/deb 1.9 main
#Puis
apt install apt-transport-https
wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | apt-key add -
apt update
apt install apache2 libapache2-mod-perl2 libapache2-mod-fcgid
apt install lemonldap-ng

Puis je change le example.org en y mettant mon domaine à la place (penser au DNS ou au fichier hosts par la suite !) 

sed -i 's/example\.com/ju.lab/g' /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.js

On modifie le fichier hosts de notre serveur: 

cat /etc/lemonldap-ng/for_etc_hosts >> /etc/hosts
echo "127.0.0.1 reload.ju.lab" >> /etc/hosts

Suite à l'installation via apt, il n'est en théorie pas nécessaire d'intégrer LemonLDAP à Apache. Il y'a juste à activer les sites et les mods : 

a2ensite portal-apache2.conf
a2ensite manager-apache2.conf
a2ensite handler-apache2.conf
a2enmod fcgid perl alias rewrite headers proxy_http
systemctl restart apache2

Désormais, je peux accéder à auth.ju.lab et à manager.ju.lab.

Le compte de démo par défaut est : dwho - dwho

On arrive sur l'interface :

RTENOTITLE

Je vais ensuite installer un glpi sur la même machine. Pour résumer :

  • Télécharger glpi sur la machine
  • installer:
    • php php-ldap php-imap php-apcu php-xmlrpc php-cas php-mysqli php-mbstring php-curl php-gd php-simplexml php-xml
    • Installer mariadb et faire une base pour glpi avec un utilisateur
    • Créer un fichier de vhost pour glpi
    • Aller sur le site et lancer l'installation.

Lien avec GLPI

  Dans un deuxième temps, nous allons faire en sorte que l'authentification GLPI passe par LemonLDAP.

L'architecture est simple, pour rappel :

-J'ai un serveur avec LemonLDAP.
-J'ai un serveur glpi, qui sert glpi depuis son adresse IP (192.168.1.15 ici) et pas depuis une url (c'est important !)

Nous allons donc proxyfier glpi à travers LemonLDAP. Pour cela :

Sur le serveur lemonldap, ajouter l'hôte virtuel apache suivant : 

###Fichier pour proxifier le glpi à travers LemonLDAP
<VirtualHost *:80>
        ServerName glpi.ju.lab #L'utilisateur se connecte ici, rentre ses identifiants...
        PerlHeaderParserHandler Lemonldap::NG::Handler  #La requête est prise en compte...

        ProxyPass / http://192.168.1.15/ #Et renvoie vers GLPI.
        
        ErrorLog /var/log/apache2/proxysite_glpi_error.log   #Logs custom, assez utiles !
        CustomLog /var/log/apache2/proxysite_glpi_access.log combined
</VirtualHost>

#Ensuite, ne pas oublier a2ensite et systemctl restart apache2

Ensuite de quoi, nous allons configurer cet hôte virtuel depuis le manager de LemonLDAP :

Je créée ici l'hote virtuel de glpi :

Je modifie la règle d'accès par défaut en "accept":

Je modifie l'en-tête exportée :

Une fois que tout ça est sauvegardé, je n'ai plus qu'à me rendre sur GLPI (via son ip pour le moment) pour modifier la méthode d'authentification.

Enregistrer. Il est désormais possible de lancer une fenêtre de navigation privée et de se rendre sur glpi.ju.lab pour se retrouver face à l'interface d'authentification de LemonLDAP.

Ici, je me suis connectée avec dwho, l'utilisateur de démo de lemonldap :

 

Récupérée de « https://wiki.squi.fr/index.php?title=SSO&oldid=2190 »