SSO

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 :

• publiées avec l’accord de la personne,
• utilisées dans le cadre d ’un objectif précis,
• durée de conservation raisonnable,
• sécurité physique et logique des données,
• accessibles qu’aux seules personnes autorisées.
• <a href="http://www.cnil.fr" alt="http://www.cnil.fr" title="http://www.cnil.fr">http://www.cnil.fr</a>
• <a href="http://www.educnet.education.fr/legamedia" alt="http://www.educnet.education.fr/legamedia" title="http://www.educnet.education.fr/legamedia">http://www.educnet.education.fr/legamedia</a>

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

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.

Apache et les modules d'auth

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

• mod_auth : utilisation des fichiers htpasswd et htgroup
• mod_ssl : gestion SSL et authentification avec certificats
• mod_authldap : authentification LDAP
• mod_authZldap : authentification avec certificats puis autorisation basée sur LDAP
• etc : <a href="http://modules.apache.org" alt="http://modules.apache.org" title="http://modules.apache.org">http://modules.apache.org</a>

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     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-perl 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
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