Que nous réserve la LDAPCon 2017 ?

La LDAPCon est une conférence internationale autour de la technologie LDAP et des enjeux de gestion des identités, d’authentification et d’habilitation.

L’événement qui se déroulera cette année à Bruxelles du 19 au 20 octobre, se tient tous les deux ans dans un pays différent :

Savoir-faire Linux, déjà commanditaire en 2015 (consultez notre retour sur cette édition) renouvelle avec plaisir son soutien à cette communauté en étant une nouvelle fois partenaire de l’édition 2017.

2 jours et 19 conférences, un programme riche et rythmé

Le programme de cette édition promet des interventions intéressantes, parmi lesquelles :

  • ReOpenLDAP : Modification d’OpenLDAP pour une utilisation intensive chez un opérateur de télécommunications
  • OpenLDAP pour Samba 4 : Point sur l’intégration d’OpenLDAP dans Samba 4 en lieu et place de l’annuaire natif codé par l’équipe Samba
  • PHP-LDAP : Des nouvelles de l’évolution de l’API LDAP dans PHP, délaissée depuis plusieurs années et que les développements reprennent
  • OpenLDAP : Des nouvelles du projet OpenLDAP par Howard Chu, le développeur principal

Les sujets afférents à LDAP comme la gestion des identités dans le Cloud, les habilitations/autorisations, l’authentification unique ou encore la supervision seront abordés dans les différentes présentations.

Savoir-faire Linux fera le point sur les différents protocoles de SSO (CAS, SAML et OpenID Connect) dans une intervention donnée vendredi après-midi, juste avant la présentation du logiciel FusionDirectory, le logiciel d’administration des données d’un annuaire LDAP, utilisé dans notre infrastructure interne et chez certains de nos clients.

Si cette conférence vous intéresse, vous pouvez réserver vos billets en ligne sur le site de la conférence.

Un nouveau standard de SSO pour les gouverner tous

L’authentification unique (en anglais Single Sign On ou SSO) est aujourd’hui bien implantée dans les systèmes d’information, grâce à une large offre de produits et surtout de nombreux standards comme CAS, SAML ou OpenID Connect, pour ne citer que les plus importants.

Cependant, ce domaine reste difficile d’accès car chaque nouvelle norme demande un temps d’apprentissage non négligeable et l’adaptation des applications. Afin d’éviter que ces technologies finissent dans un cul-de-sac, un nouveau standard unifiant les protocoles actuels a vu le jour : le standard des anneaux !

La fraternité de l’anneau

Ce standard part du principe que tous les protocoles de SSO fonctionnent sur le même modèle : une requête non authentifiée à un fournisseur de servicesls (application) est renvoyée à un fournisseur d’identité (portail) qui authentifie l’utilisateur puis transmet son identité au fournisseur de service dans un jeton.

Le fournisseur de service et le fournisseur d’identité font partie d’un anneau de confiance (ou cercle de confiance) grâce à l’échange préalable de données de configuration (métadonnées).

Le standard des anneaux conserve donc tout simplement ce fonctionnement en simplifiant les échanges (uniquement des requêtes HTTP GET) mais en exigeant une validation des signatures des messages au bit près.

Les deux tours

Le processus d’authentification se joue en deux tours :

  1. Redirection de l’utilisateur via son navigateur entre fournisseur de services et fournisseur d’identité pour récupérer un jeton opaque (canal frontal)
  2. Validation du jeton directement entre les fournisseurs (canal dorsal)

Concrètement, le standard des anneaux va comme OpenID Connect reposer sur OAuth 2.0, à la différence que les jetons d’accès sont rebaptisés « access tolkien » pour les distinguer justement des jetons OAuth 2.0 classiques.

La redirection initiale est inspirée du protocole CAS (notion de service dans l’URL) et la gestion des signatures du protocole SAML (clé publique publiée dans les metadonnées).

Ainsi, ce nouveau standard tire parti du meilleur des protocoles existants en masquant la complexité de leurs implémentations.

Le retour du R.O.I.

Pour les applications devant intégrer le standard des anneaux, le retour sur investissement est immédiat : le nouveau protocole est simple, basé sur des composants existants, robuste et sûr.

En résumé, la gestion de l’identité de l’utilisateur peut se traduire du point de vue des applications vis-à-vis de utilisateurs par « Vous le savez ? Nous le saurons ! ».

Le standard des anneaux, un nouveau protocole sur lequel il faudra compter !

Des nouvelles du projet LDAP Tool Box, la boîte à outils pour les annuaires LDAP

Le projet LDAP Tool Box rassemble différents outils pour aider les administrateurs LDAP, que ce soit des paquets OpenLDAP, des scripts de supervision ou encore des applications Web. L’objectif est de simplifier la vie des administrateurs LDAP, car comme l’indique la description du projet :

Même les administrateurs LDAP ont besoin d’aide

Tous les outils proposés sont sous licence libre et disponibles sur GitHub.

Supervision

Des greffons de supervision sont fournis pour Nagios (ou tout autre logiciel compatible) et Cacti. Ils permettent par exemple de vérifier le statut de la réplication OpenLDAP, de collecter les statistiques sur les opérations LDAP ou encore surveiller le taux de remplissage d’une base MDB.

16c97f6538278bee29e8b9de1aac3516-media-593x381

Des configurations sont également disponibles pour la pile logicielle ELK (ElasticSearch, Logstash, Kibana) afin de tracer en temps réel l’utilisation des annuaires OpenLDAP.

openldap-elk-ldap-operations

Paquets OpenLDAP

OpenLDAP est le serveur LDAP le plus répandu, très proche du standard et offrant d’excellentes performances. Il est présent dans la plupart des distributions GNU/Linux mais celles-ci font souvent des choix de compilations non avalisées par les développeurs du projet, l’exemple le plus représentatif étant la bibliothèque SSL/TLS.

Le projet LDAP Tool Box fournit des paquets pour les environnements Debian/Ubuntu et Red Hat/CentOS. Ils sont compilés avec OpenSSL et embarquent les overlays officiels ainsi que certains overlays contribués comme « lastbind » et « smbk5pwd ».

Ils offrent également des modules spécifiques de gestion de la qualité des mots de passe comme check_password et ppm. Un script de gestion du service est installé par défaut, permettant les sauvegardes/restaurations des données et de la configuration.

Interface de gestion du mot de passe

L’application Self Service Password permet de fournir aux utilisateurs une interface simple pour changer son mot de passe, ou le réinitialiser quand celui-ci est perdu (ou expiré). Cette réinitialisation peut se faire :

  • Par un lien envoyé par mail
  • Par un code envoyé par SMS
  • Par la réponse à une question

Cette interface est compatible avec différents annuaires LDAP dont Active Directory et Samba 4.

ssp_1_0_change_password

La version 1.0 de ce logiciel est sortie en octobre 2016 (voir l’article sur LinuxFR).

Interface de consultation des données

L’application White Pages est une interface de consultation des données d’un annuaire LDAP, avec les fonctionnalités suivantes :

  • Recherche rapide : une invite de recherche dans le menu permet de retrouver directement des entrées à partir du nom, du prénom, du mail ou de l’identifiant
  • Recherche avancée : un formulaire liste les différents attributs sur lesquels une recherche peut être faite
  • Trombinoscope : toutes les entrées de l’annuaire sont affichées avec leur photo

Ces fonctions peuvent être activées/désactivées et les attributs cherchés ou affichés sont configurables. L’interface peut donc être utilisée avec n’importe quel annuaire LDAP.

wp_0_1_full_display

La version 0.1 de ce logiciel est sortie en novembre 2016 (voir l’article sur LinuxFR).

Relier son application à FranceConnect avec le logiciel libre LemonLDAP::NG

Développé depuis 2014 sous l’égide de la DINSIC, FranceConnect est la nouvelle plate-forme d’authentification à destination des citoyens français pour simplifier l’accès à l’administration en ligne.

Annoncé officiellement il y a quelques jours par le secrétaire d’État chargé de la réforme de l’État et de la simplification, FranceConnect est déjà utilisé par de nombreuses administrations.

Le protocole OpenID Connect

C’est le protocole OpenID Connect qui a été retenu pour FranceConnect, choix risqué en 2014 car le standard n’en était qu’à ses débuts, mais il a depuis fait ses preuves, comme en témoigne son adoption par Google.

J’ai eu l’occasion de présenter ce protocole dans différentes conférences, comme à la LDAPCon en novembre dernier :

LDAPCon2015_OpenIDConnect-Diapos

L’avantage d’avoir opté pour un standard comme OpenID Connect, c’est que cela permet d’utiliser n’importe quel logiciel ayant implémenté ce standard pour se relier à FranceConnect.

lemonldap-ng-france-connect

Depuis la version 1.9 de LemonLDAP::NG, on peut utiliser OpenID Connect, soit comme client (Relying Party), soit comme fournisseur (OpenID Provider).  Une application compatible avec LemonLDAP::NG peut donc alors très facilement récupérer une identité via FranceConnect sans développement supplémentaire !

Configuration de LemonLDAP::NG

Nous allons configurer LemonLDAP::NG comme client OpenID Connect. Pour cela il faut tout d’abord paramétrer le service OpenID Connect :

  • Gérer les règle de redirections (Apache ou Nginx) pour le chemin /oauth2/
  • Choisir « OpenID Connect » comme module d’authentification
  • Définir l’identifiant de l’entité (par défaut l’URL du portail)
  • Laisser les valeurs par défaut pour les points d’accès OAuth2
  • La configuration d’une clé de signature n’est pas nécessaire

Il reste ensuite à inscrire FranceConnect comme fournisseur OpenID Connect :

  • Créer les métadonnées JSON (non fournies par FranceConnect), par exemple (valeurs de la plate-forme de développement) :
{
"issuer": "https://fcp.integ01.dev-franceconnect.fr",
"authorization_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/authorize",
"token_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/token",
"userinfo_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/userinfo",
"end_session_endpoint":"https://fcp.integ01.dev-franceconnect.fr/api/v1/logout"
}
  • Déclarer les attributs de l’identité pivot à collecter, par exemple : given_name, family_name, birthdate
  • Dans les options, renseigner le client_id et client_secret fourni par FranceConnect (voir l’étape suivante), et le scope lié aux attributs demandés, par exemple : openid email profile birth

Enregistrement auprès de FranceConnect

Pour que votre instance de LemonLDAP::NG puisse être reliée à FranceConnect, il faut formuler une demande officielle via ce formulaire.

Il est important de fournir l’URL de callback, qui par défaut dans LemonLDAP::NG est http://auth.example.com/?openidcallback=1. Mais vous devrez adapter cette URL avec votre propre nom de domaine, et si besoin d’autres paramètres en fonction des modules utilisés dans LemonLDAP::NG.

FranceConnect vous fournira alors les valeurs de client_id et client_secret dont vous avez besoin dans la configuration de LemonLDAP::NG.

C’est terminé !

LemonLDAP::NG est désormais configuré pour s’authentifier sur FranceConnect. Si certaines choses ne fonctionnent pas, référez-vous à la documentation technique disponible sur le site.

Les attributs collectés lors de l’authentification sont disponibles dans la session SSO et peuvent être transmis par LemonLDAP::NG aux applications de différentes façons : en-têtes HTTP, CAS, OpenID Connect ou SAML.

À vous de jouer !

Utilisation de Keepalived pour la haute-disponibilité LDAP et HTTP

Nous déployons régulièrement des infrastructures LDAP et WebSSO chez nos clients, et se pose toujours la question de la haute-disponibilité : la plate-forme d’authentification devenant centrale, il est indispensable de se prémunir d’un arrêt de service, que ce soit de l’annuaire LDAP ou du portail d’authentification Web. Nous allons voir comment le logiciel Keepalived peut nous aider à répondre à ce besoin.

ka-header

Des logiciels d’infrastructure adaptés

Avant d’envisager la mise en place d’outils de haute-disponibilité, il faut s’assurer que les logiciels principaux de l’infrastructure sauront fonctionner dans ce mode, c’est-à-dire qu’ils peuvent être installés sur plusieurs nœuds (serveurs physiques, virtuels ou conteneurs) et opérer de la même façon quelque soit le nœud actif.

Dans notre cas, nous utiliserons les logiciels suivants :

  • OpenLDAP : serveur d’annuaire compatible LDAPv3
  • LemonLDAP::NG : produit de WebSSO compatible CAS, SAML et OpenID Connect

OpenLDAP-logo

OpenLDAP sait fonctionner en mode multi-maîtres depuis plusieurs années, via le protocole SyncRepl. Le mode « miroir » (mirror mode) est particulièrement pertinent dans une architecture à deux nœuds où un seul d’entre eux sera contacté par les clients (l’important ici est d’éviter que des opérations d’écriture soient faites simultanément sur les deux nœuds). La configuration de ce mode est détaillée dans le guide d’administration d’OpenLDAP.

LemonLDAP::NG

LemonLDAP::NG pour sa part a été conçu dès le départ pour pouvoir utiliser des bases externes pour la gestion de ses données (configuration et sessions). Ainsi il est possible de déployer autant de nœuds que nécessaire en partageant les données entre les nœuds. Pour ma part, j’utilise régulièrement l’annuaire OpenLDAP comme stockage de la configuration et des sessions : l’annuaire étant déjà redondé, pas besoin de travail supplémentaire pour le WebSSO. Mais vous pouvez également utiliser des bases de données SQL (MySQL, PostGreSQL) ou NoSQL (MongoDB, Redis, Cassandra) pour assurer ce service.

Utilisation d’une adresse virtuelle

Une fois les deux nœuds installés, chacun possède son adresse IP propre et il faut trouver un moyen d’indiquer aux applications clientes quel nœud utiliser.

Une première solution est le Round-Robin DNS : au nom DNS ldap.example.com ou auth.example.com on associe les deux adresses IP, et charge aux clients de se débrouiller avec ça. Dans le cas de HTTP, la plupart des clients sauront rejouer les requêtes sur la seconde IP si la première ne fonctionne pas, mais ce n’est pas aussi évident pour les clients LDAP.

L’autre solution est d’utiliser une adresse IP virtuelle qui sera associée au nœud principal. Le nœud secondaire est opérationnel mais ne sera pas associé à l’adresse IP virtuelle, jusqu’à ce que celle-ci bascule en cas de problème du nœud principal. Dans cette situation, la haute-disponibilité est bien gérée du côté des serveurs, et non du côté des clients qui ne contacte qu’une seule adresse, l’adresse IP virtuelle.

Utilisation de Keepalived

Le logiciel Keepalived permet de gérer une IP virtuelle qui sera associée au nœud principal tant que celui-ci est opérationnel. Le protocole VRRP est utilisé entre les nœuds pour gérer cette adresse IP virtuelle.

Sa configuration est assez simple :

vrrp_instance VI_SFL {
  state MASTER
  priority 150
  nopreempt
  interface eth0
  virtual_router_id 69
  advert_int 5
  authentication {
     auth_type PASS
     auth_pass KEEPALIVED_PASSWORD
  }
  virtual_ipaddress {
    10.10.0.10/22 brd 10.10.0.255 dev eth0 scope global
  }
}

Il est intéressant de paramétrer la partie « authentication » pour éviter que les ordres VRRP soient pris en compte par d’autres routeurs non associés à la grappe de serveurs. Seuls les serveurs disposant du même mot de passe consommeront les requêtes.

Le paramètre « priority » permet d’indiquer le nœud principal. Le ou les nœuds secondaires auront une priorité plus faible (par exemple 100).

Script de surveillance

Cette configuration initiale n’est pas suffisante pour palier à des problèmes applicatifs : l’adresse IP virtuelle basculera si le nœud principal ne répond plus au protocole VRRP, mais rien n’est fait pour surveiller l’annuaire LDAP ou le serveur HTTP.

Keepalived permet d’utiliser un « track_script » dans lequel nous sommes libres de lancer les commandes que nous souhaitons. Si ce script s’exécute sans erreurs, alors le nœud est considéré comme opérationnel, sinon il est mis en quarantaine.

L’appel au script se configure simplement :

vrrp_script check_server_health {
  script "/usr/local/bin/check_server_health.sh"
  interval 2
  fall 2
  rise 2
}

vrrp_instance VI_SFL {
  ...
  track_script {
    check_server_health
  }
}

Voici un exemple de script :

#!/bin/bash

# Script that do several checks to verify LDAP/SSO service is up
#
# Returns 0 if all is fine
#
# Copyright (c) 2016 Clement Oudot @ Savoir-faire Linux


# Disks

rootuse=$(df -H / | grep -v 'Filesystem' | awk '{ print $5 }' | cut -d'%' -f1)

if [ $rootuse -ge 95 ]; then
        echo "Partition / is full ($rootuse%)"
        exit 1
else
        echo "Partition / is OK ($rootuse%)"
fi

# Process
            
openldapprocess=$(/bin/pidof slapd)
apacheprocess=$(/bin/pidof apache2)

/usr/local/openldap/bin/ldapsearch -x -H ldap://localhost -b '' -s base -l 3 > /dev/null 2>&1
ldapresponse=$?

if [ -z "$openldapprocess" ]; then  
        echo "OpenLDAP is not running"
        exit 1
else
        echo "OpenLDAP is running (PID $openldapprocess)"
fi

if [ "$ldapresponse" -gt 0 ]; then
        echo "OpenLDAP is not anwering on RootDSE"
        exit 1
else
        echo "OpenLDAP is answering on RootDSE"
fi

if [ -z "$apacheprocess" ]; then
        echo "Apache is not running"
        exit 1
else
        echo "Apache is running (PID $apacheprocess)"
fi

# Exit without problem
exit 0

J’utilise plusieurs type de vérifications dans ce script :

  • Contrôle de l’espace disque
  • Contrôle des démons lancés
  • Réponse à une requête LDAP

Bien entendu, charge à vous d’y mettre les vérifications qui vous semblent pertinentes.