Bonnes ID ~ Clément Oudot

La version 2.4.28 d'OpenLDAP est sortie en début de semaine, et les RPMs du projet LDAP Tool Box ont suivi peu après.

Ces RPMs apportent les fonctionnalités suivantes:

• Backend BDB, HDB, MDB et LDAP
• Tous les overlays officiels
• Certains overlays "contrib" (lastbind et smbk5pwd)
• Support SSL (via OpenSSL)
• Support de la délégation SASL
• Support SLAPI
• Autoconfiguration de la rotation des logs
• Script d'initialisation en version 1.3
• Module pwdChecker pour la politique des mots de passe

Le script d'initialisation propose de nombreuses fonctionnalités, comme la sauvegarde et la restauration des données. Ces simples commandes suffisent:

# service slapd backup
# service slapd restore

Il permet également de démarrer simplement OpenLDAP en mode debug:

# service slapd debug

Ce script est bien entendu compatible avec cn=config, et permettra dans sa prochaine version la sauvegarde et restauration de la configuration :

# service slapd backupconfig
# service slapd restoreconfig

Cette fonctionnalité sera fournie dans la prochaine version (1.4).

Pour télécharger tout ça, rendez-vous sur le site du projet LDAP Tool Box : http://ltb-project.org

Ceci est la reprise de l'article rédigé pour LinuxFR, disponible ici : http://linuxfr.org/news/sortie-de-lemonldapng-11

Le 8 juillet dernier, à la veille de l'ouverture des RMLL, est sortie une nouvelle version majeure de LemonLDAP::NG.

LemonLDAP::NG est un logiciel de Web-SSO destiné à protéger des applications Web. Pour les utilisateurs, cela permet de ne s'authentifier qu'une seule fois (Single Sign-On) et pour les administrateurs du WebSSO cela permet de contrôler de manière centralisée les droits d'accès aux applications. LemonLDAP::NG supporte désormais de nombreux protocoles d'authentification et de fédération d'identités comme CAS, OpenID ou SAML 2.0.

La version 1.1 apporte un certain nombre de nouveautés présentées ci-dessous.

Gestion des notifications

Une notification est un message affiché à l'utilisateur lors de son accès au portail d'authentification (accès obligatoire pour la création de sa session SSO). Une notification peut contenir des cases à cocher, qui devront alors être activées par l'utilisateur pour poursuivre.

Ce système permet par exemple d'avertir un utilisateur sur la modification de ses habilitations, ou sur l'ajout ou la suppression d'une application dans le portail.

Les notifications existent dans LemonLDAP::NG depuis la version 0.9.4, mais le paramétrage de cette fonctionnalité était complexe. Depuis la version 1.1, le Manager (interface d'administration de la solution) possède désormais un explorateur qui permet de créer et parcourir les notifications.

De plus, les notifications peuvent désormais :

• S'adresser à tous les utilisateurs (auparavant, une notification était enregistrée pour un utilisateur précis)
• Posséder une condition d'affichage (ce qui permet par exemple d'afficher une notification pour des utilisateurs provenant d'un certain réseau, ou possédant certains attributs)

Pour plus d'informations, vous pouvez consulter la documentation en ligne.

Réinitialisation du mot de passe par mail

Lorsqu'un utilisateur a perdu son mot de passe, LemonLDAP::NG propose une page où il peut réinitialiser son mot de passe par mail. Il n'est bien entendu pas question de lui transmettre son mot de passe actuel, mais bien de lui permettre d'en changer via un challenge par mail. Cette méthode est inefficace si le mot de passe du WebSSO est le même que le mot de passe de sa messagerie, mais dans les autres cas, elle permet d'alléger considérablement les appels au support.

La cinématique est la suivante :

• L'utilisateur fait une demande de réinitialisation en entrant son identifiant (ou tout attribut permettant de l'identifier de manière unique, comme son mail)
• Un mail est envoyée avec un lien, dont la validité est configurable (par défaut 24 heures)
• Le lien mène à une page permettant de saisir un nouveau mot de passe, ou de demander sa génération automatique
• Le nouveau mot de passe est envoyé par mail

Pour plus d'informations, vous pouvez consulter la documentation en ligne.

Authentification par Yubikey

La Yubikey est un périphérique physique permettant de faire de l'authentification avec mot de passe à usage unique (One Time Password, OTP).

LemonLDAP::NG permet désormais d'utiliser ce périphérique pour ouvrir une session SSO. Les attributs de l'utilisateur peuvent être ensuite récupéré en associant l'identifiant de la clé à l'identifiant de l'utilisateur dans la base des comptes (LDAP ou SQL).

Pour plus d'informations, vous pouvez consulter la documentation en ligne.

Personnalisation

La personnalisation du produit est facilitée dans la dernière version, en particulier :

• Les messages d'erreurs peuvent être surchargés dans le fichier INI
• Les thèmes possèdent désormais des modèles HTML "custom" inclus dans les modèles par défaut

Pour plus d'informations, vous pouvez consulter la documentation en ligne.

La version 2.4.24 d'OpenLDAP est sortie en début d'année. Les RPMs ont été mis en ligne sur LTB-project et sont téléchargeables ici.

Les paquets fournis par LTB-Project incluent en plus d'OpenLDAP un script d'initialisation et un module de contrôle de mot de passe pour l'overlay ppolicy.

Le script d'initialisation est en version 1.2, qui apporte en particulier une fonctionnalité supplémentaire : le démarrage en mode "debug". Cela permet de demander le lancement d'OpenLDAP dans la console avec un niveau de logs configurable (niveau "stats").

Par exemple :

root@ader:~# service slapd debug
slapd[3519]: [INFO] Using /etc/default/slapd for configuration
slapd[3524]: [INFO] Halting OpenLDAP...
slapd[3528]: [OK] OpenLDAP stopped after 1 seconds
slapd[3529]: [INFO] no data backup done
slapd[3530]: [INFO] Halting OpenLDAP replication...
slapd[3531]: [INFO] no replica found in configuration, aborting stopping slurpd
slapd[3532]: [INFO] Launching OpenLDAP replication...
slapd[3533]: [INFO] no replica found in configuration, aborting lauching slurpd
slapd[3534]: [INFO] no db_recover done
slapd[3535]: [INFO] Launching OpenLDAP...
slapd[3536]: [OK] file descriptor limit set to 1024
@(#) $OpenLDAP: slapd 2.4.23 (Dec  8 2010 14:28:30) $
        clement@ader:/home/clement/Programmes/openldap-2.4.23/servers/slapd
slapd starting
conn=1000 fd=13 ACCEPT from IP=127.0.0.1:48634 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="" method=128
conn=1000 op=0 RESULT tag=97 err=0 text=
connection_input: conn=1000 deferring operation: binding
conn=1000 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)"
conn=1000 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
conn=1000 op=2 UNBIND
conn=1000 fd=13 closed

Liens :

• Site du projet LTB
• Annonce de la sortie des RPMs
• Annonce de la sortie du script d'initialisation
• Téléchargement

Voilà, j'ai quitté la belle province de Montréal pour rentrer en France en début de semaine, après avoir passé quelques jours au Québec pour participer à ConFoo, et entre autres présenter LemonLDAP::NG.

Sécurité et HTML5

Mon penchant naturel pour les sujets de gestion des identités et des accès m'ont amené à suivre une grande majorité des conférences sur la sécurité. Celles-ci traitaient en général des attaques classiques sur les applications Web, en tenant compte des nouvelles spécificités du cloud computing, et des web services, souvent ignorés et sources de failles majeures.

Une grande partie des conférenciers sur ce sujet appartenaient à l'OWASP, comme Sébastien GIORIA, Philippe GAMACHE, Sylvain MARET ou Antonio FONTES.

J'ai également pu croiser Allan Foster de ForgeRock qui a présenté XACML et son support dans OpenAM.

L'autre sujet à l'honneur, c'est bien entendu HTML5, accompagné de CSS3. Sur cette dernière technologie, une conférence très intéressante de Daniel GLAZMAN, co-chairman W3C CSS Working Group, dont on peut retenir en substance : CSS 2.1 est enfin publié, CSS 3 en en maturation. Les démonstrations sur les transformations ou les bordures de cadres donnent toutefois très envie d'utiliser CSS 3 dès à présent. Quelques démonstrations sur HTML5, en particulier la vidéo, ont fait également leur petit effet. Là aussi, la bonne nouvelle est que le support des périphériques d'entrée (comme une webcam) sont des sujets à l'étude.

Microsoft se joint aux festivités

Le sponsor principal de ConFoo 2011 était Microsoft. Suprenant, sachant que ConFoo n'est que le digne successeur de PHPQuébec, une conférence dédiée à PHP. On a même pu croiser des affiches ventant le support de Java, Python ou PHP sur Microsoft Azure, leur offre cloud.

Le responsable Open Source de Microsoft, Gianugo Rabellino, est venu en personne parler d'Internet Explorer 9, et de l'implication de sa société dans l'établissement des standards et dans l'interopérabilité.

Un bon lavage de cerveau en quelque sorte, même si l'on ne peut que saluer les efforts faits par Microsoft pour rattraper son retard dans ce domaine.

Pour conclure

Je tiens à remercier toute l'équipe de l'organisation de ConFoo, qui a fait un travail remarquable, dont le résultat n'est pas moins que 150 conférences assurées par une centaine d'intervenants sur trois journées bien remplies !

Vous trouverez quelques photos de l'évènement sur mon compte picasa. Un article plus complet devrait sortir prochainement dans Linux Magazine.

La politique c'est pas fait pour les politiciens

Rappelons d'abord qu'une politique des mots de passe est un ensemble de règles permettant :

• de contrôler les authentifications (blocage de compte après plusieurs tentatives infructueuses)
• de contrôler les changements de mot de passe (expiration, force du mot de passe, réinitalisation à la prochaine connexion, présence dans un historique, etc.)

Samba et OpenLDAP sont sur un bateau

Pour ceux qui ont pratiqué Samba, il est assez simple de gérer la politique des mots de passe Samba (à l'aide des outils Samba ou des Samba LDAP tools). Cependant cette politique ne s'applique qu'à Samba, et ses mots de passes spécifiques (sambaLMPassword et sambaNTPassword).

Pour ceux qui ont pratiqué OpenLDAP, il est aussi assez simple de gérer la politique des mots de passe, en activant l'overlay ppolicy. Cependant cette politique ne s'applique qu'au mot de passe LDAP (userPassword).

Je ne veux voir qu'une politique !

C'est donc bien joli tout ça, mais il me faut une solution pour gérer de manière unique ces contraintes suivantes :

• Taille du mot de passe au moins de 8 caractères
• Stockage des 4 derniers mots de passe dans un historique

Bien entendu cela devra être appliqué pour une modification du mot de passe à travers Samba (donc potentiellement à travers la GINA Windows) et à travers une interface Web de changement de mot de passe LDAP.

Et on est bien d'accord que si je change le mot de passe LDAP par l'interface Web, les mots de passe Samba sont aussi mis à jour.

Et plus vite que ça !

Samba

Configurons Samba pour qu'il ne modifie que le mot de passe LDAP. En effet, on va déléguer le reste du travail à OpenLDAP :

# vi /etc/samba/smb.conf

---8<---
ldap passwd sync = only
---8<---

Cela va en fait indiquer à Samba de ne changer que le champ 'userPassword', et ne de pas toucher aux champs 'sambaLMPassword' et 'sambaNTPassword'.

À noter que Samba utilise l'opération étendue password modify pour changer le mot de passe.

OpenLDAP

Il faut activer deux overlays :

• ppolicy : politique des mots de passe OpenLDAP (contrôle des authentifications et des changements de mot de passe)
• smbk5pwd : modification des mots de passe Samba et Kerberos en parallèle du mot de passe LDAP, uniquement sur l'opération étendue de changement de mot de passe

L'overlay smbk5pwd n'est pas un overlay officiel, il se trouve dans le répertoire contribs/slapd-modules/smbk5pwd. Certains distributions l'incluent toutefois dans leurs paquetages OpenLDAP (par exemple CentOS), sinon il faut compiler l'overlay à la main.

# vi /etc/openldap/slapd.conf

---8<---
modulepath /usr/lib/openldap/
moduleload ppolicy.la
moduleload smbk5pwd.la

database bdb
overlay ppolicy
ppolicy_default ou=default,ou=ppolicy,dc=example,dc=com

overlay smbk5pwd
smbk5pwd-enable samba
---8<---

Et on configure par exemple la politique des mots de passe avec cette entrée :

dn: ou=default,ou=ppolicy,dc=example,dc=com
objectClass: organizationalUnit
objectClass: pwdPolicy
objectClass: top
ou: default
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdInHistory: 4
pwdMinLength: 10

Croisons les doigts

Changement de mot de passe d'un utilisateur par Samba :

• Mot de passe valide :

# smbpasswd coudot
New SMB password:
Retype new SMB password:

• Mot de passe invalide (trop court ou dans l'historique) :

# smbpasswd coudot
New SMB password:
Retype new SMB password:
ldapsam_modify_entry: LDAP Password could not be changed for user coudot: Constraint violation
        Password fails quality checking policy
Failed to modify entry for user coudot.
Failed to modify password entry for user coudot

L'erreur LDAP remontée est bien celle de la politique des mots de passe OpenLDAP.

Ça ira pour cette fois

Cette solution a le mérite de fonctionner, mais on s'aperçoit vite qu'il est impossible par exemple d'avoir un seul compteur d'authentification erronées (car Samba ne fait pas de BIND LDAP), ou encore d'avoir une seule information pour forcer la réinitialisation à la prochaine connexion.

Reste à espérer que les travaux sur Samba 4 amélioreront l'interopérabilité des deux politiques.

Pour la première fois, LemonLDAP::NG traverse l'atlantique et va se présenter lors de l'événement ConFoo à Montréal.

ConFoo propose 3 journées de conférences sur les technologies Web, avec des pointures du domaines. On retrouvera en particulier parmi nos compatriotes Damien Seguy (Alterway) et Fabien Potencier (Sensio Labs), deux des acteurs les plus influents de la communauté PHP en France. ConFoo donne aussi la parole à des intervenants du domaine de la sécurité, comme Allan Foster de ForgeRock qui viendra parler d'OpenAM, le fork d'OpenSSO suite au rachat de SUN par Oracle.

Pour ma part, j'aurai le plaisir de représenter LINAGORA, et de faire découvrir LemonLDAP::NG au public québecois, et parler un peu de Perl au milieu des conférences Java, Python et PHP ;)

Non, vous ne rêvez pas

Le bruit courrait depuis quelque temps déjà, c'est aujourd'hui chose faite : La version 1.0 de LemonLDAP::NG est sortie !

Il ne faut évidemment pas se fier au numéro de version, LemonLDAP::NG est un logiciel qui a vu le jour il y a plusieurs années, au sein du Ministère des Finances et de la Gendarmerie Nationale. La version 1.0 marque la stabilisation d'un certain nombre de fonctionnalités et l'arrivée de modules très importants, comme les fournisseurs d'identité CAS, SAML et OpenID. Une attention toute particulière a été accordée à la gestion de la configuration, qui pouvait être l'un des reproches fait aux précédentes versions, afin que les futures évolutions de versions soient beaucoup plus simple.

L'heure des présentations

Mesdames, messieurs, j'ai le plaisir de vous présenter LemonLDAP::NG, un logiciel libre d'authentification unique (WebSSO) et de contrôle d'accès aux applications Web.

Écrit en Perl et intégré directement au cœur du serveur HTTP Apache (à travers mod_perl), il analyse chaque flux HTTP pour d'une part vérifier les habilitations de l'utilisateur, et d'autre part enrichir la requête d'en-têtes HTTP pour transmettre les informations de session à l'application protégée. La cinématique complète est décrite ici.

Une de ses grandes forces est la simplicité d'intégration des applications. En effet, il suffit de lire une en-tête HTTP ou une variable d'environnement pour utiliser le WebSSO. Et c'est sans compter les applications qui sont nativement compatibles (OBM, Bugzilla, Dokuwiki, Linshare, etc.)

C'est en forgeant des en-têtes qu'on devient forgeron

À ses débuts, LemonLDAP::NG ne savait interagir qu'avec un annuaire LDAP pour authentifier les utilisateurs (d'où son nom). Aujourd'hui, il a bien mûri et peut utiliser les protocoles suivants :

• LDAP
• SQL
• SSL X509
• Apache built-in modules (Kerberos, NTLM , OTP, …)
• SAML 2.0 / Shibboleth
• OpenID
• Twitter
• CAS

La grande nouveauté, c'est que LemonLDAP::NG est désormais fournisseur d'identités, c'est-à-dire qu'il peut transmettre l'identité d'un utilisateur à d'autres services en passant par des protocoles standards :

• CAS (cf. article sur CAS)
• SAML 2.0 / Shibboleth (cf. article sur SAML)
• OpenID

Il SAML de quoi ?

C'est sur SAML que le travail a été le plus important, ce qui explique le laps de temps entre la précédente version (0.9.4.1 en octobre 2009) et celle-ci. Toutefois l'attente n'aura pas été vaine puisque LemonLDAP::NG est désormais :

• Fournisseur de service (conforme SP Lite)
• Fournisseur d'identités (conforme IDP Lite)
• Autorité d'attributs
• Fournisseur d'identités mandataire (Proxy IDP)

Cela a été rendu possible par l'utilisation de la librairie GPL Lasso (cf. article sur Lasso). L'interaction a été bénéfique aux deux logiciels puisque la dernière version de Lasso (2.3) a bénéficié de nombreux tests et rapports d'anomalies issus du développement de LemonLDAP::NG.

Il y en a un peu plus, je vous le mets quand même ?

L'enrichissement des modules d'authentification et de fournisseur d'identités est certes une avancée majeure pour LemonLDAP::NG, mais la nouvelle version apporte également d'autres améliorations notables :

• Refonte de l'interface de configuration (Manager) et de l'explorateur de sessions, avec une utilisation intensive de jQuery et jQuery UI.
• Nouveau thème (dark) pour le portail, ce qui porte à 3 le nombre de thèmes fournis par défaut.
• Possibilité de configurer les paramètres de redirection (port et HTTPS) pour chaque hôte virtuel, et non plus de manière globale par serveur physique.
• Configuration graphique du rejeu de formulaire, avec support des hôtes virtuels.
• Handler Zimbra.
• Choix d'authentification au niveau du portail.
• Fusion des fichiers de configuration locaux dans un fichier unique au format INI.
• Refonte du menu des applications pour une meilleure présentation des catégories et des applications.
• Dépôts YUM et Debian.
• Nouveau wiki.
• ...

L'ensemble des changements est visible sur le projet JIRA.

Merci, merci

LemonLDAP::NG est avant tout le fruit de la collaboration entre la Gendarmerie Nationale et la société LINAGORA.Cette nouvelle version a monopolisé ces deux acteurs sur l'année qui vient de s'écouler.

Le support du SAML a été réalisé avec la collaboration de la société Entr'ouvert (éditrice de Lasso).

Bien évidemment, tous les utilisateurs qui ont pu tester les versions candidates et qui ont fait des retours précieux ont grandement contribué à la sortie de la version 1.0.

Vous pouvez retrouver LemonLDAP::NG à travers l'offre LinID de LINAGORA, par le module LinID Access Manager.

J'espère au nom de toute l'équipe de LemonLDAP::NG que cette nouvelle version comblera vos attentes, et vous donnera l'envie de parler de ce projet autour de vous. En attendant, n'hésitez pas à nous rejoindre !

Quelques liens pour la root

• Site officiel de LemonLDAP::NG
• Téléchargement
• Captures d'écran
• Documentation

CAS que c'est ?

CAS (Central Authentication Service) est un système de SSO alternatif à LemonLDAP::NG, basé sur le principe de la délégation : chaque service fait appel au serveur central SSO pour obtenir l'identité de l'utilisateur. Le protocole CAS utilise des tickets transmis via des redirections HTTP, puis validés par l'application elle-même en interrogeant directement le serveur central (ce qui est appelé lien dorsal, ou backlink en anglais).

L'avantage de CAS est donc de cloisonner les services, c'est-à-dire qu'un ticket de service ne permettra pas d'accéder à un autre service. Reste que le cookie SSO principal (celui du portail d'authentification) permet lui d'obtenir tous les tickets pour tous les services.

CAS est un protocole, passé successivement aux versions 1.0 et 2.0. Par amalgame CAS désigne aussi souvent l'implémentation serveur de référence fournie par JASIG. Toutefois il est possible d'utiliser d'autres produits en tant que serveur CAS, comme c'est le cas désormais de LemonLDAP::NG.

Fidèle CAS trop

En effet, comme mentionné dans des billets précédents, les développements sur LemonLDAP::NG sont très actifs ces derniers temps. La plupart des efforts ont été concentrés sur l'implémentation de SAML 2.0, mais la nouvelle mouture de LemonLDAP::NG proposera également le support d'OpenID et de CAS (à la fois en tant que client -consumer- et serveur -provider-).

CAS a mia

Intéressons-nous tout d'abord à la partie cliente. Elle existe depuis quelques années dans LemonLDAP::NG, permettant de "CASsifier" le portail d'authentification. Concrètement, cela permet d'utiliser un serveur CAS externe comme authentification primaire sur LemonLDAP::NG.

La nouvelle version de ce module apporte une nouveauté : le mode mandataire (proxy).

Ce mode permet de déclarer des applications protégées par LemonLDAP::NG comme mandatées. Dans ce cas des tickets proxy CAS sont obtenus pour chacune des applications et ensuite disponibles dans la session de l'utilisateur. Ils peuvent donc être ensuite transmis à l'application qui pourra les valider directement avec le serveur CAS. Cela est très utile par exemple pour protéger un webmail CASsifié, qui utilise en sous-main pam_cas pour valider l'identité de l'utilisateur.

Mare à CAS

La partie serveur elle est toute neuve. Basé sur l'interface de fournisseur d'identité créée pour l'intégration SAML, le fournisseur CAS implémente tout le protocole CAS 1.0 et CAS 2.0.

LemonLDAP::NG devient donc le premier serveur CAS écrit en Perl !

Vodka Lemon ou Gin CAS ?

Désormais, CAS n'est plus une alternative à LemonLDAP::NG, mais l'un de ces protocoles d'authentification. Il est donc possible de passer à LemonLDAP::NG en conservant les applications CASsifiées. Avantage supplémentaire : en protégeant l'application CASsifiées, l'authentification est laissée en protocole CAS, mais LemonLDAP::NG peut désormais gérer les autorisations d'accès à l'application, et cela toujours de manière non-intrusive.

Toutefois, l'implémentation de référence de CAS poursuit sa route, et implémente certaines fonctionnalités qui n'apparaissent pas dans la description du protocole. C'est le cas de certains services web utilisés pour obtenir des informations sur l'utilisateur, ou la gestion de la déconnexion des applications.

Et bien entendu, reste le choix technologique de Java par rapport à Perl, matière à beaucoup de discussions qui ne font pas l'objet de cet article !

CAS qu'on attend ?

Ces nouvelles fonctionnalités peuvent être testées en utilisant la version de développement. Une archive est construite toutes les nuits et disponible ici.

Il faudra attendre encore un peu avant la sortie de la version 1.0, qui contiendra des nombreuses autres fonctionnalités, dont certaines feront peut-être l'objet de nouveaux articles sur ce blog.

N'hésitez pas à contacter la communauté (sur la liste lemonldap-ng-user AT ow2.org ou sur IRC #lemonldap-ng@freenode) pour obtenir de nouvelles informations !

Pas de fumée sans feu

Depuis quelques mois, les développements sur LemonLDAP::NG sont consacrés à l'implémentation du standard SAML2. Une première version candidate (1.0rc1) est sortie au mois d'avril, permettant de tester LemonLDAP::NG en tant que fournisseur de service SAML2 (SP).

Aujourd'hui, la fonctionnalité de fournisseur d'identités SAML2 est pratiquement implémentée à 100%, et les premiers tests grandeur nature commencent.

L'implémentation SAML de LemonLDAP::NG repose sur Lasso.

Le village dans les nuages

L'un de ces tests a porté sur Google Apps : la suite d'applications Google a destination des entreprises. Ce sont donc les premiers pas de LemonLDAP::NG dans le fameux cloud dont tout le monde parle .

Stairway to heaven

Je livre ici la recette pour faire fonctionner Google Apps avec LemonLDAP::NG (version de développement au 18/06/2010). Cela demande quelques manipulations qui seront certainement facilitées dans la version stable qui sortira cette année.

On suppose qu'on a investi chez Google Apps pour acheter des comptes pour le domaine entreprise.com. D'un autre côté, on a installé dans son réseau LemonLDAP::NG, dans le domaine mon-entreprise.net. Ce domaine peut-être accessible d'internet, ou réservé aux utilisateurs internes seulement (on préférera généralement le rendre accessible d'internet, pour accéder à Google Apps depuis l'extérieur de l'entreprise).

Du côté de LemonLDAP::NG

Après une installation standard du produit, il faut activer plusieurs paramètres depuis le Manager (http://manager.mon-entreprise.net) :

• Portail : auth.mon-entreprise.net
• Domaine : mon-entreprise.net
• Authentification/Utilisateurs : LDAP (ou SSL, DB, Apache, ...)
• Fournisseur : SAML

Toujours dans le Manager, configurer le service SAML, en particulier les clés de signature et de chiffrement, ainsi que tous les points d'accès SAML. Par exemple pour le point d'accès SSO HTTP-REDIRECT : http://auth.mon-entreprise.net/saml/singleSignOn. Un peu d'aide sur cette partie peut se trouver ici : http://wiki.lemonldap.ow2.org/xwiki/bin/view/NG/AuthSAML.

Reste à insérer les metadonnées de Google Apps en tant que fournisseur de service SAML dans le Manager. Google Apps ne fournit pas de metadonnées, il faut donc les générer soit-même. Pour cela, copier le fichier ci-dessous, en modifiant entreprise.com avec votre domaine Google Apps (paragraphe AssertionConsumerService) :

<EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
                <KeyDescriptor>
                        <ds:KeyInfo>
                                <ds:KeyValue>
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANZ2b5wb43eJRYnln2bfo+neq6ZQYksm
Ftn3juDB/UklfwVN0XPi8NBHXFQjfXPeVse6Ztjl+C443jRCkSawVZMCAwEAAQ==
                                </ds:KeyValue>
                        </ds:KeyInfo>
                </KeyDescriptor>
                <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
                <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                        Location="https://www.google.com/a/entreprise.com/acs" />
        </SPSSODescriptor>
</EntityDescriptor>

La valeur de la clé publique est factice, mais nécessaire pour que les metadonnées soient reconnues par Lasso (ce ne sera peut-être plus le cas dans la version stable).

Depuis le Manager, insérer ces metadonnées dans un nouveau fournisseur de service, et configurer les options suivantes :

• Format de NameID par défaut : email
• Vérifier la signature des requêtes SSO : non

Du côté de Google Apps

Depuis l'interface d'administration de votre domaine, aller dans Outils avancés > Configurer l'authentification unique (SSO)

Il suffit de faire pointer Google Apps vers les points d'accès définis dans LemonLDAP::NG :

• Page de connexion : URL où est transmise la requête d'authentification SAML
• Page de déconnexion : URL où est redirigé l'utilisateur lors de sa déconnexion depuis Google Apps (ce n'est pas du SLO SAML)
• Page de changement de mot de passe : URL où l'utilisateur peut changer son mot de passe (ce sera le menu LemonLDAP::NG)

Il faut également charger un certificat qui contient la clé publique de notre fournisseur d'identité. On peut générer ce certificat à partir de la clé privée de signature disponible dans le Manager :

$ openssl req -new -key lemonldap-ng-key.pem -out cert.csr
$ openssl x509 -req -days 3650 -in cert.csr -signkey lemonldap-ng-key.pem -out cert.pem

C'est alors le fichier cert.pem qu'il faut charger dans Google Apps.

On enfonce le cloud

À présent tout est prêt, les utilisateurs peuvent accéder à un service Google Apps de l'entreprise, comme le calendrier : http://www.google.com/calendar/hosted/entreprise.com

Il sont alors redirigés avec un requête d'authentification SAML vers LemonLDAP::NG. Ils peuvent s'authentifier avec les ressources de l'entreprise (Annuaire LDAP, Active Directory, PKI, etc.) et reviennent alors sur Google Apps avec un jeton SAML qui est validé chez Google (en particulier la signature est contrôler à l'aide du certificat chargé précédemment).

L'utilisateur est alors authentifié sur Google Apps !

Des ombres au tableau

Google Apps supporte SAML et c'est une très belle opportunité pour le déploiement de ce standard.

Toutefois, on regrette certaines choses :

• Les requêtes d'authentification de Google Apps ne sont pas signées, impossible de s'assurer que l'utilisateur n'est pas victime d'hameçonnage
• Il n'y a pas de support du Single Logout (SLO) : on peut se déconnecter de Google Apps et être dirigé vers la page de déconnexion du fournisseur d'identité, mais pas l'inverse : si l'utilisateur ferme sa session SAML depuis un autre fournisseur d'identité, alors se session Google Apps ne sera pas fermée.

Lucy in the sky with diamonds

J'espère que cet article vous aura donné envie de tester la nouvelle version de LemonLDAP::NG. On se donne rendez-vous aux RMLL pour une démonstration IRL !