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 !

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.

OpenID Kinect, un nouveau standard pour améliorer l’adoption du SSO par les utilisateurs

La fondation OpenID continue ses efforts pour démocratiser l’authentification unique (SSO – Single Single On) et après la sortie du protocole OpenID Connect, elle s’associe aujourd’hui à Microsoft pour travailler sur un nouveau standard : OpenID Kinect.

OpenID Kinect

La ludification de la sécurité

C’est un fait reconnu en informatique, la ludification des applications a permis une meilleure adoption de celles-ci par les utilisateurs finaux. Et pourquoi n’en serait-il pas de même avec la sécurité ?

C’est en substance ce que promeut Hilary Jone, directrice du programme « La sécurité est mon amie, il nous faut l’aimer aussi » de la fondation OpenID :

Avec l’adoption de la Kinect de Microsoft, de nouvelles perspectives s’ouvrent à nous et vont enfin permettre de s’affranchir des mots de passe en offrant une réelle alternative, bien plus crédible que la biométrie ou les jetons physiques.

En effet, l’innovation principale du protocole OpenID Kinect est la standardisation d’un mode d’authentification alternatif au classique couple identifiant/mot de passe, encore utilisé par les principaux fournisseurs d’identités OpenID Connect tels que Google par exemple.

Ainsi l’utilisateur, au lieu de saisir son mot de passe, pourra prouver son identité en effectuant une chorégraphie qu’il aura au préalable enregistrée sur son fournisseur d’identité.

Une extension du protocole OpenID Connect

Dans OpenID Connect, qui reposait déjà sur un autre standard (OAuth 2.0), la récupération des données de connexion de l’utilisateur était rendue possible par l’utilisation du mot-clé « openid » dans la liste des étendues (scope) transmises dans la requête authentification :

http://auth.example.com/oauth2/authorize?response_type=code&client_id=lemonldap&scope=openid%20profile%20email%2Fauth.example.com%2Foauth2.pl&redirect_uri=http%3A%2F%3Fopenidconnectcallback%3D1&state=ABCDEFGHIJKLMNOPQRSTUVWXX

Désormais, vous pourrez utiliser en plus le mot-clé « kinect » qui indiquera que vous souhaitez récupérer les données d’authentification générée par la Kinect de l’utilisateur. le mot-clé « kinect » devra être également précisé dans les classes d’authentification (acr_values) afin de forcer le fournisseur d’identité à activer le mode Kinect pour l’authentification.

Comme pour OpenID Connect, les informations spécifiques de la Kinect seront transmises au client OpenID Connect dans un JWT (JSON Web Token).

Un prototype en Perl

Bien que la sortie officielle de ce nouveau standard soit prévue en fin d’année, des premiers prototypes sont en cours, dont un en Perl, utilisant, c’est évident, le framework Dancer.

Une extension pour Samba est également en préparation.

Bientôt en France ?

FranceConnect est aujourd’hui en ligne et permet grâce au protocole OpenID Connect de simplifier l’accès aux services en lignes de l’administration pour les citoyens. On peut par exemple accéder au site Service Public ou consulter son solde de points du permis de conduire en passant par cette nouvelle plate-forme d’authentification.

Mais demain, aura-t-on accès à un FranceKinect? On espère que l’État Français saura s’adapter à ce nouveau protocole et proposera cette facilité dans un nouvelle version de sa plate-forme.

OpenID Kinect Sport

Les perspectives sont ensuite infinies : stage de récupération de points de permis via une simulation de course automobile, démarches administratives dématérialisées dans Les Sims (vous pourrez laisser votre avatar faire la file d’attente à votre place !), ou encore cours de sport depuis chez soi (sans limite de nombre d’inscrits).

Bref, un petit pas de danse pour l’homme, mais un grand pas de danse pour l’humanité.