Bonnes ID ~ Clément Oudot

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - securité

Fil des billets

jeudi, décembre 22 2011

Sortie de Self Service Password 0.7

Présentation

Self Service Password est une interface web très simple permettant à un utilisateur de changer son mot de passe dans un annuaire LDAP. Cet annuaire peut être Active Directory ou un annuaire LDAP conforme au standard.

Le logiciel est en PHP, sous licence GPL.

recaptcha.png

Fonctionnalités principales

  • Mode Samba (pour les mots de passe NT et LM)
  • Mode Active directory (pour les mots de passe AD), avec déverrouillage et réinitialisation à la prochaine connexion
  • Mode Shadow account
  • Politique des mots de passe locale :
    • Taille minimale/maximale
    • Caractères interdits
    • Compteurs pour les majuscules, minuscules, chiffres et caractères spéciaux
    • Non réutilisation du mot de passe actuel
    • Complexité (nombre de classes de caractères différentes)
  • Messages d'aide
  • Réinitialisation par questions/réponses
  • Réinitialisation par un challenge par mail
  • reCAPTCHA (Google API)
  • Notification par mail après changement de mot de passe

L'application est désormais disponible en 8 langues : anglais, français, allemand, espagnol, brésilien, néerlandais, catalan et polonais !

Quelques liens

mercredi, juillet 27 2011

Sortie de Self Service Password 0.6

Présentation

Self Service Password est une interface web très simple permettant à un utilisateur de changer son mot de passe dans un annuaire LDAP. Cet annuaire peut être Active Directory ou un annuaire LDAP conforme au standard.

Le logiciel est en PHP, sous licence GPL.

recaptcha.png

Fonctionnalités principales

  • Mode Samba (pour les mots de passe NT et LM)
  • Mode Active directory (pour les mots de passe AD)
  • Politique des mots de passe locale :
    • Taille minimale/maximale
    • Caractères interdits
    • Compteurs pour les majuscules, minuscules, chiffres et caractères spéciaux
    • Non réutilisation du mot de passe actuel
    • Complexité (nombre de classes de caractères différentes)
  • Messages d'aide
  • Réinitialisation par questions/réponses
  • Réinitialisation par un challenge par mail
  • reCAPTCHA (Google API)
  • Notification par mail après changement de mot de passe

L'application est désormais disponible en 6 langues : anglais, français, allemand, espagnol, brésilien et néerlandais.

Quelques liens

lundi, avril 11 2011

LDAP Tool Box Self Service Password sort en version 0.5

ltb-logo.png

On n'est jamais mieux servi que par soi-même

C'est en tout cas ce que chaque employé d'un service de support informatique vous dira. Traiter les demandes d'utilisateurs ayant perdu leur mot de passe, ou tout simplement voulant changer leur mot de passe, est une activité sans beaucoup de valeur ajoutée.

Pour tenter de réduire le temps investi sur ce sujet, des logiciels dits de "Self Service" sont arrivés. Le principe est simple : si l'utilisateur perd son mot de passe, il se rend sur l'application et demande un nouveau mot de passe, tout seul, comme un grand.

Génial, où est-ce qu'on peut l'acheter ?

Le projet LDAP Tool Box fournit une petite interface Web remplissant ce rôle, elle est nommée avec grande originalité Self Service Password (SSP pour les intimes).

SSP propose les fonctions suivantes :

  • Changement du mot de passe dans un annuaire LDAP
  • Support de Active Directory
  • Support de Samba
  • Politique des mots de passe locale (taille, types de caractères, etc.)
  • Réinitialisation par questions/réponses
  • Réinitialisation par challenge mail

Grâce à de nombreuses contributions, l'interface est disponible en français, anglais, allemand, espagnol, brésilien et hollandais.

La version 0.5 est sortie ce week-end (pas de repos pour les libristes), elle est disponible en archive simple, en paquet RPM ou paquet Debian. N'attendez plus pour l'essayer !

vendredi, avril 1 2011

Le SSO, cause principale de la maladie d'Alzheimer

Une étude de l'institut NAZ (Neuroscience AlZheimer) vient de prouver le lien entre le déploiement du SSO en entreprise et la maladie d'Alzheimer, désormais classée dans les accidents du travail.

De la paresse mémorielle à la maladie

Le SSO, Single Sign On, est un système informatique permettant aux utilisateurs de n'avoir qu'un seul mot de passe pour accéder à toutes leurs applications. La généralisation de ce système change radicalement les habitudes des usagers, qui sollicitent de moins en moins leur mémoire dans leur travail quotidien.

Certains systèmes SSO peuvent même déclencher l'authentification de l'utilisateur à partir d'une carte à puce, ou de son empreinte digitale : plus aucun accès mémoire n'est requis !

Le cerveau doit être sans cesse sollicité pour fonctionner. Avec le SSO, le voici devenu presque inutile, avec les conséquences que l'on connaît maintenant.

Le téléphone portable, une première alerte ignorée

L'arrivée des téléphones portable avait déjà créé du remous dans la communauté médicale, accusant le répertoire téléphonique d'affaiblir les capacités cognitives de ses utilisateurs : aujourd'hui, personne ne connaît plus que 3 ou 4 numéros de téléphone, contre plusieurs dizaines auparavant.

La riposte est en cours

Pour palier à ce problème, plusieurs entreprises ont décidé d'abandonner le SSO. Elles exigent désormais au moins deux mots de passe pour se connecter aux applications, dont un doit être une date d'anniversaire, ou le prénom d'un proche. Elles espèrent ainsi faire reculer la maladie, au moins jusqu'à la retraite de leurs salariés.

À votre échelle, vous pouvez également agir : jetez tous les papiers que vous trouverez sur lesquels des mots de passe sont écrits. Vous contribuerez ainsi à l'amélioration de la santé mentale de vos collègues.

jeudi, mars 24 2011

Mise à jour de sécurité sur LemonLDAP::NG (sortie de la version 1.0.4)

Une nouvelle version de LemonLDAP::NG est sortie cette semaine, numérotée 1.0.4.

Cette version corrige entre autres un problème important, lié à la refactorisation du code de la cage d'exécution (Safe) : les macros et les groupes étaient conservés en mémoire, et pouvaient donc être copiés d'une session d'utilisateur à une autre. Conséquence : si les règles d'accès utilisent les macros ou les groupes, cela pouvait permettre l'accès à des personnes non autorisées aux applications.

Il est donc vivement conseillé de migrer vers la nouvelle version.

Page de téléchargement de LemonLDAP::NG.

mardi, mars 15 2011

Retour sur ConFoo 2011

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.

vendredi, mars 4 2011

Sujet du jour : comment instaurer une politique des mots de passe commune à OpenLDAP et Samba ?

LDAP.png

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.

lundi, février 28 2011

LemonLDAP::NG se présente à Montréal le 10 mars prochain

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

I am speaking at ConFoo Web Techno Conference. March 9th to 11th 2011. Montreal

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 ;)

mercredi, décembre 1 2010

Sortie de LemonLDAP::NG 1.0 !

Non, vous ne rêvez pas

logo_lemonldap-ng.png

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 :

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

vendredi, juin 18 2010

LemonLDAP::NG sur un nuage

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 .

SAML-Applications.png

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)

Google_Apps_1276952044490.png

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 !

mercredi, juillet 22 2009

Sortie de LemonLDAP::NG 0.9.4

Début juillet est sortie la dernière version de LemonLDAP::NG, un logiciel libre de WebSSO et gestion des accès. Les nouveautés de la version 0.9.4 ont été présentées lors des 10èmes RMLL à Nantes, lors de la journée consacrée à la gestion des identités. Pour ceux qui n'ont pas eu le privilège d'assister à cette conférence, cet article rappelle les principes de fonctionnement du produit et liste les nouvelles fonctionnalités. Les plus intéressés trouveront également dans le Linux Mag de cet été une bonne introduction au logiciel.

logo_lemonldap-ng.png

LemonLDAP::NG fournit des mécanismes d'authentification unique à l'intérieur d'Apache en utilisant les capacités de mod_perl à traiter les requêtes HTTP depuis leur arrivée, leur traitement jusqu'au renvoi de la réponse au client. La gestion de la session repose sur un cookie échangé entre les clients et les agents LemonLDAP::NG (Handlers) ne contenant qu'une clé permettant d'accéder aux données de session qui sont partagées entre les agents.

Ces données de sessions sont collectées lors de la phase d'authentification et permettent d'établir des règles d'accès complexes, avec notamment la possibilité de recourir aux expressions régulières, ou d'appeler des fonctions qui contrôlent par exemple les jours et horaires d'accès.

Le portail d'authentification présente à l'utilisateur connecté la liste des applications qui lui sont autorisées ainsi qu'un formulaire de changement de mot de passe.

Pour les administrateurs, une interface graphique permet de modifier les principaux paramètres de configuration ainsi que de naviguer dans les sessions ouvertes par les utilisateurs.

La version 0.9.4 apporte les nouveautés suivantes :

  • Utilisation de LDAP pour la configuration et les sessions : il était déjà possible d'utiliser un annuaire LDAP pour l'authentification, l'obtention des informations de session et pour le changement de mot de passe. À présent la configuration et les sessions peuvent être stockées dans l'annuaire, ce qui simplifie la configuration en mode réparti ou en cluster. Cela ne nécessite pas d'extension de schéma.
  • Accès SOAP : les fonctions SOAP ont été entièrement réécrites, avec pour conséquence la perte de compatibilité avec les configurations SOAP des versions précédentes. Toutefois l'objectif étant la simplification de l'architecture, c'est le portail qui devient un point d'accès SOAP, rendant obsolète l'écriture de scripts CGI dédiés. La protection du point d'accès SOAP est gérée directement dans l'hôte virtuel du portail au niveau de la configuration Apache.
  • Notifications : des notifications peuvent être envoyées aux utilisateurs qui devront les valider pour poursuivre leur accès au portail. Cela permet en particulier d'avertir un utilisateur de l'ouverture d'un accès à une application.
  • Fonctions dans les règles d'accès : des nouvelles fonctions permettent de configurer des accès sur une période (date de début, date de fin) ou sur des jours et horaires (par exemple du lundi au vendredi de 8h à 19h).
  • Adresse du portail dynamique : cela permet de présenter un portail différent selon l'application protégée d'origine ou la provenance des utilisateurs. Il est alors possible d'héberger plusieurs WebSSO avec une seule instance d'Apache.
  • Séparation claire des modules d'authentification, de données utilisateur et de mots de passe : il est possible alors de choisr par exemple Kerberos pour l'authentification et LDAP pour la lecture des informations utilisateur. Le module Multi permet de chaîner plusieurs méthodes.
  • Politique des mots de passe LDAP : le WebSSO gère à présent l'ensemble de la politique des mots de passe implémentée dans la plupart des annuaires LDAP. En particulier, le portail saura exiger le renouvellement du mot de passe lorsque celui aura été réinitialisé par un administrateur. Lors du changement de mot de passe, des messages d'erreurs explicites sont retournés aux utilisateurs (mot de passe trop court, historique, etc.).
  • Configuration du cross-domain : l'activation du cross-domain est simplifiée par l'ajout d'un paramètre dans le portail et dans l'agent. Le cross-domain permet d'ouvrir une session SSO sur plusieurs domaines DNS différents.
  • Validation de formulaires : cette fonctionnalité est juste apparue dans cette version et doit être utilisée avec précaution. Elle permet de poster des données sur des applications protégées, ce qui étend la compatibilité de LemonLDAP::NG avec n'importe quelle application Web.
  • Double cookie : si activée, cette fonction créée deux cookies, un pour HTTP et l'autre pour HTTPS. Ainsi un cookie dérobé en HTTP ne pourra pas servir à entrer sur des applications HTTPS.

Liens :

lundi, janvier 19 2009

Sortie de LemonLDAP::NG 0.9.3

LemonLDAP::NG est un logiciel de Web-SSO, développé par Xavier Guimard et destiné à protéger des applications Web. Pour les utilisateurs, cela permet de ne s'authentifier qu'une seule fois, et pour les administrateurs du WebSSO cela permet de contrôler de manière centralisée les droits d'accès aux applications.

logo_lemonldap-ng.png

LemonLDAP::NG est une réécriture de la version initiale LemonLDAP, qui n'est aujourd'hui plus maintenue. Eric German, leader historique de la communauté, est à présent impliqué sur un nouveau projet, LemonID, que nous vous invitons à découvrir.

Cette version est normalement la dernière avant la 1.0 qui se concentrera sur la refonte de la configuration (utilisation de XML, exhaustivité des paramètres de configuration dans la console d'administration Web, etc.). Elle apporte toutefois un lot conséquent de corrections et d'améliorations, telles qu'un menu des applications autorisées, un explorateur de session, et des paquetages pour les systèmes basés sur Debian et RedHat.

Cette version est également importante en terme de sécurité car elle corrige quelques failles de Cross Site Scripting (XSS) et ajoute un contrôle plus fort sur les URL de redirection.

LemonLDAP::NG permet de déployer trois types d'architectures de WebSSO :

  • Un système de mandataire inverse (reverse-proxy) qui concentre en un point unique le portail d'authentification et les agents de contrôles. L'utilisateur n'accède alors jamais directement aux applications mais utilise toujours le mandataire.
  • Un système de délégation, où les agents de contrôles sont déployés au plus près des applications. Dans ce cas l'utilisateur accède directement aux applications, dont les agents interagissent avec le portail d'authentification pour valider les sessions.
  • Un système mixte, mélangeant le mandataire inverse et la délégation.

Voici quelques détails supplémentaires sur les principales fonctionnalités du produit :

  • Indépendance des mécanismes d'authentification et de recherche des données de l'utilisateur : la phase d'authentification permet de valider la création de la session WebSSO, elle peut être effectuée sur un annuaire LDAP, par certificat SSL, par Liberty Alliance, par CAS, par Kerberos ou tout autre méthode d'authentification disponible dans Apache2. La phase de recherche des données correspond elle à la récupération des informations propres à l'utilisateur (nom, mail, etc.) qui serviront d'une part à valider les règles d'accès, et d'autre part à approvisionner les applications protégées. Cette phase ne peut à l'heure actuelle être opérée que sur un annuaire LDAP (l'ajout d'autres méthodes est prévu dans les futures versions).
  • Utilisation des Web-Services (SOAP) : il est possible d'activer les Web-Services pour s'authentifier (et donc créer la session SSO correspondante), consulter et modifier les sessions existantes, consulter et modifier la configuration.
  • Portail d'authentification : il permet de s'authentifier lorsque l'on est redirigé depuis des applications protégées, mais propose également un module de menu dynamique des applications (seules les applications autorisées sont affichées à l'utilisateur) et un module changement de mot de passe. L'affiche de ces modules est également dynamique, et peut permettre par exemple de ne proposer le changement de mot de passe qu'à une certain profil d'utilisateurs.
  • Interface d'administration graphique : LemonLDAP::NG fournit par défaut un Manager qui permet d'éditer à travers une page Web la configuration générale du WebSSO ainsi que les droits d'accès et les en-têtes spécifiques à chaque application protégée. Cette nouvelle version propose également un explorateur de sessions, offrant une vue hiérarchique des sessions (par identifiant ou adresse IP), et affichant le contenu de chacune d'elles. Cette interface peut être protégée directement par le WebSSO.
  • Choix des backends de session et de configuration : les sessions peuvent être stockées comme fichiers, dans une base MySQL, par SOAP ou dans memcached. La configuration peut être stockée comme fichier, dans une base MySQL ou par SOAP. Ce choix permet de mettre en place très rapidement des solution de haute-disponibilité. En cas de configuration stockée sur un système distant, un mécanisme de cache permet de limiter le transfert des données sur le réseau.
  • Agents et applications compatibles : un certain nombre d'applications sont déjà compatibles avec LemonLDAP::NG, en particulier GLPI, Sympa, Dokuwiki, ... Mais des agents sont également disponibles, en particulier une valve pour Tomcat permettant le SSO sur les application J2EE délégant leur sécurité au conteneur de servlets (par exemple le CMS Lutece, probe, etc.). De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles (c'est le cas de Nagios). Enfin, la nouvelle version de LemonLDAP::NG peut à présent mettre le mot de passe de l'utilisateur en session, ce qui permet par exemple le SSO sur des applications protégées par HTTP Basic (en particulier le fameux Outlook Web Access).
  • Pages de statuts et scripts de supervision : une page de statut est à présent disponible (équivalent au mod-status d'Apache), permettant de réaliser simplement des graphiques avec des outils de supervision (un script pour MRTG est fourni dans les exemples).
  • Politique des mots de passe : LemonLDAP::NG est compatible avec la politique des mots de passe des annuaires LDAP qui suivent le draft de la RFC. C'est le cas d'OpenLDAP avec l'overlay policy. Cela permet à l'utilisateur de savoir que son compte est bloqué ou expiré, et de changer son mot de passe en respectant les critères fixés dans l'annuaire (taille minimale, présence dans l'historique, etc.)

Cette version fait donc état de la grande maturité du produit et des nombreuses fonctionnalités offertes. Toute la communauté reste à l'écoute des utilisateurs pour répondre aux questions et enrichir le logiciel selon leurs besoins. Toutes les contributions sont également les bienvenues.

Liens :

lundi, mars 31 2008

Sortie de Perl-LDAP 0.35 et politique des mots de passe

Perl

Ce week-end une nouvelle version des bibliothèques Perl Net::LDAP est sortie en version 0.35, apportant un certain nombre d'améliorations (listées ici), dont un nouveau module dédié au contrôle LDAP Password Policy.

Rappelons que ce contrôle permet par exemple de bloquer des comptes suites à plusieurs authentifications ratées, de conserver un historique des mots de passe, d'avoir une taille minimale, de chiffrer à la volée, etc. Si vous souhaitez plus d'informations sur ce standard (qui n'en n'est pas vraiment un puisque la RFC n'est encore qu'un brouillon), vous trouverez une documentation ici.

L'installation se fait de manière très classique :

# perl Makefile.PL
# make
# make test
# make install

Ainsi, vous pouvez à présent dans vos programmes Perl récupérer les messages spécifiques de ce contrôle :

        use Net::LDAP;
        use Net::LDAP::Control::PasswordPolicy;
        use Net::LDAP::Constant qw( LDAP_CONTROL_PASSWORDPOLICY );

        $ldap = Net::LDAP->new( "ldap.example.com" );

        $pp = Net::LDAP::Control::PasswordPolicy->new;

        $mesg = $ldap->bind( "cn=Bob Smith,dc=example,dc=com",
                             password => "secret",
                             control => [ $pp ] );

        # Get password policy reponse
        my($resp)  = $mesg->control( LDAP_CONTROL_PASSWORDPOLICY );

        if (defined($resp)) {
          my $v = $resp->error;
          print "Password policy error $v\n" if defined $v;
          $v = $resp->time_before_expiration;
          print "Password expires in $v second(s)\n" if defined $v;
        }