Introduction à la fédération d'identité et au système d'authentification simplifier à l'aide de la bibliothèque Lasso en PHP
Copyright © 2004 Nowicki Christophe
| Historique des versions | ||
|---|---|---|
| Version v0.5 | 2004-10-08 | CN |
| Première version publique. | ||
Résumé
Au cours de mon stage chez Easter-Eggs (http://www.easter-eggs.com/), j'ai été amené à participer au projet Lasso/Liberty Alliance de la société Entr'Ouvert (http://www.entrouvert.com/) et pour lequel Easter-eggs fournis des compétences en développement dans le cadre du réseau Libre Entreprise (http://www.libre-entreprise.com/).
Celle-ci avait besoin de compétences en langage PHP et C, pour réaliser une sur couche à la bibliothèque qu'ils sont en train de développer. Cette bibliothèque est une implantation des spécifications du projet Liberty Alliance. Ce document décrit le fonctionnement de la bibliothèque et les spécifications Liberty Alliance.
Table des matières
- Gestion des identités digitales
- Présentation du projet Liberty Alliance
- Qu'est ce que LASSO? (Liberty Alliance Single Sign On)
- Ecriture d'une extension Lasso pour PHP
- Ecriture d'un exemple de fournisseur de service en PHP à l'aide de l'extension
- Ecriture d'un Fournisseur de d'identité en PHP
- Exemples de topologie de réseaux d'identité fédérée
- Conclusion
- Bibliographie
De nos jours des bribes de votre identité sont éparpillées à travers les systèmes d'informations des entreprises. Les banques, les entreprises de crédit, de courtage, d'assurances, d'agences gouvernementales, fournisseurs internet et entreprises de télécommunication et la liste ne cesse de s'agrandir avec le temps. Votre identité est éparpillée parmi ces nombreux réseaux et systèmes d'informations. Cela demande beaucoup de coordination de la part de l'utilisateur qui doit parfois gérer une liste impressionnante de mots de passe. Un autre problème se pose : il s'agit du manque de contrôle pour l'utilisateur sur ses identités.
Le problème avec les systèmes d'authentification actuels réside dans la gestion de chaque identité qui est à la charge de l'utilisateur. C'est à lui de se souvenir de ces multiples login/mot de passe et de tenir à jour les informations sur les différents sites web; ce qui amène les utilisateurs à utiliser toujours le même couple de login/mot de passe sur chaque site.
Dans chaque cas cela conduit à une diminution de la sécurité pour l'utilisateur. De plus, pour de nombreux utilisateurs, la vue d'une simple page de "création de compte", qui demande un certain nombre d'informations reste un frein. La plupart des utilisateurs sont lasses de remplir ces formulaires.
La fédération d'identité est une réponse à ce problème.
La création d'une infrastructure de fédération d'identité est une alternative viable au système actuel. Pour les employés ou les utilisateurs, une identité fédérée conduit à une meilleure expérience de l'Internet, un plus grand niveau de personnalisation, plus de sécurité et un véritable contrôle sur cette identité. Cette infrastructure ouvre des nouvelles opportunités commerciales. C'est exactement l'objectif du projet Liberty Alliance.
Cette infrastructure d'identité fédérée repose sur le format phare d'Internet, qui est le XML ( Extensible Markup Language ) et des nombreuses technologies qui tournent autour.
Au premier abord, la gestion centralisée des informations semble être la meilleure solution de gestion des utilisateurs. Mais dans certains cas elle impose de sérieuses limitations.
La gestion des identités centraliseé ne peut pas sortir du cadre des l'entreprises. Par exemple, il n'est pas souhaitable de créer un compte sur le système d'informations pour un collaborateur extérieur à l'entreprise, car celui-ci aurais accès à d'autres ressource du système d'informations de l'entreprise. Cette gestion centralisée devient rapidement complexe lorsque l'authentification sort du cadre de l'entreprise.
Le système de gestion centralisér des utilisateurs ne convient pas à la nature des services web, qui sont par définition distribués et qui exigent une gestion de l'identité interopérable (des sites web aimeraient pouvoir s'échanger les informations sur leurs visiteurs) et mobiles (les utilisateurs aimeraient pouvoir aller sur un site Internet sans devoir remplir les mêmes formulaires à chaque fois).
Le système de gestion d'identité centralisée, stocke les informations d'authentification dans un endroit unique. Le serveur d'authentification, c'est le point faible du système d'authentification. Il suffit de prendre le contrôle de ce dernier pour compromettre le système d'informations.
Le dernier problème lié à la centralisation, est le fait qu'un système centralisé supporte très mal une montée en charge. Lorsque le nombre d'utilisateurs est petit, moins de 5 000 utilisateurs cela pose relativement peu de problèmes, mais lorsqu'on doit répondre aux besoins d'un gouvernement cela pose plus de soucis.
Un système d'authentification centralisé pose aussi un problème psychologique à ces utilisateurs qui ont peur de laisser des informations sensibles dans les mains d'un système d'informations et le voit comme un «big brother». Cette vision peut être renforcée par l'idée que ce système peut être contrôlé par une seul entité, comme cela est le cas du système Passport de Microsoft.
Un système de gestion fédérée d'identité permet de contourner toutes ces limitations.
 |
La vision du projet Liberty Alliance est celle d'un monde interconnecté dans lequel chaque individu et entreprise peuvent échanger des informations d'une manière sûre et sécurisée sans remettre en cause la vie privée et l'identité. Pour accomplir cette vision le projet Liberty Alliance définit un ensemble de standards et de spécifications ouverts : |
support d'une large gamme de produits et services autorisation d'une utilisation commerciale et non-commerciale de ces spécifications choix du fournisseur d'identité
Il s'agit du concurrent direct du système Microsoft .NET Passport : http://www.microsoft.com/net/services/passport
L'identité d'un individu sur le réseau pour Liberty Alliance est constituée des différents comptes et des informations personnelles. Des attributs tels que les informations personnelles, nom, numéro de téléphone, numéro de sécurité sociale, adresse, numéro de carte de crédit peuvent être fournis par cette identité. Ces informations sont protégées soigneusement par l'individu et c'est lui qui choisit comment les entreprises peuvent accéder à ces informations.
Membres du projet Liberty Alliance Le projet est soutenu par plus de 150 entreprises : http://www.projectliberty.org/membership/current_members.php
Parmi celles-ci on trouve : American Express, Sun, Oracle, AOL, Ericsson, Francetelecom, Intel, HP, Novel, Versign, SAP et Sony.
-
La fédération, permet à un utilisateur qui a de multiples comptes de les transformer en un seul compte.
-
Le SSO, permet à un utilisateur de se connecter une fois sur un site et de naviguer authentifié sur une autre site sans devoir rentrer son mot de passe.
-
Déconnexion globale, lorsque l'utilisateur se déconnecte d'un site; il est automatiquement déconnecter de tous les autres sites.
-
Anonymat, liberty alliance préserve l'anonymat de l'utilisateur. Il est possible d'aller sur un site de météo et de ne donner que son code postal pour obtenir la météo dans sa région.
Partage des attributs, le protocole permet à un utilisateur de définir quels sont les attributs qui peuvent être exploités par le site et en cas de besoin le site peut réclamer les attributs à l'utilisateur.
Les différentes technologies qui composent le projet Liberty Alliance et la bibliothèque Lasso. Les spécifications de Liberty Alliance sont disponibles sur le site du projet à l'adresse http://www.projectliberty.org/. La version 1.2 utilise largement les technologies suivantes.
Il s'agit d'une spécification du W3C ( The World Wide Web Consortium ) disponible à l'adresse suivante : http://www.w3.org/Signature/. L'objectif de cette spécification est de développer une syntaxe basée sur le langage XML pour signer une ressource (pointer par une URI) ou bien la portion d'un message. Cette spécification explique comment signer numériquement un message . Liberty Alliance utilise cette spécification pour signer numériquement les requettes échangés.
Il s'agit d'une norme définie par la groupe OASIS (Organisation for Avancement Structured Information Sciences). Ce standard dans sa version 1.0, définit comme échangées des informations de sécurité entre plusieurs sites Web.
SAML est conçu pour faciliter "l'identification unique". La norme fournit l'intéropérabilité nécessaire pour que les internautes puissent, en se connectant à un site, voir leurs informations automatiquement transférées vers les sites partenaires, ce qui leur permettra de ne pas ressaisir les informations d'authentification.
En SAML, la sécurité est exprimée sous la forme d'assertions concernant des sujets (humains ou virtuels) qui ont une identité pour le système de sécurité. Il s'agit par exemple d'une personne, identifiée par son adresse mail, login etc ... Les assertions définissent les propriétés et attributs opérant sur les sujets, et définissent les droits de ceux-ci quant à l'accès aux ressources.
 |
SOAP ( http://www.w3.org/TR/soap/ ) est un protocole de transmission de messages. Il définit un ensemble de règles pour structurer des messages pour exécuter des dialogues requête-réponse RPC (Remote Procedure Call). Il n'est pas lié à un protocole particulier mais il est le plus souvent utilisé avec le protocole HTTP. Il n'est pas non plus lié à un système d'exploitation ni à un langage de programmation, donc, théoriquement, les clients et serveurs de ces dialogues peuvent tourner sur n'importe quelle plate-forme et être écrits dans n'importe quel langage du moment qu'ils peuvent formuler et comprendre des messages SOAP. En tant que tel, il s'agit d'un important composant de base pour développer des applications distribuées qui exploitent des fonctionnalités publiées comme services par des Intranets ou Internet. C'est le protocole phare des Web Services avec le protocole XML-RPC. |
Recommandation du W3C ( http://www.w3.org/TR/wsdl ) permettant de décrire des services web.
Le projet Open Source SourceID (http://www.sourceid.org/), qui démarre en 2001 est soutenu par la société de services PingIdentity Corporation ( http://www.pingidentity.com ). Ecrit entièrement à l'aide du langage JAVA, elle est conforme aux spécifications ID-FF 1.2. La licence Source ID Open Source Licence 1.2 n'est pas libre au sens Debian. Ce produit supporte les spécifications IDFF-1.2 il a été certifié conforme aux spécifications par le consortium. Les développeurs de chez Entr'ouvert ont testé l'interoperabilité de Lasso avec SourceID.
Pour comprendre le fonctionnement du «framework» Liberty Alliance, il faut connaître les différentes dénominations et leurs significations
Les termes utilisés dans les spécifications "Liberty Alliance"
- Principal
- Il s'agit d'un individu ou bien d'une machine avec ses attributs et ses informations d'authentification.
- IdP, Identity Provider (Fournisseur d'identité)
- Le fournisseur d'identité, est le serveur qui stocke les identités et les attributs des utilisateurs.
- SP, Service Provider (Fournisseur de services)
- Le fournisseur de services est un site ou une application qui cherche à authentifier un utilisateur.
- SSO, Single Sing On ( Authentification Simplifiée Unique )
- Principe qui permet à un utilisateur de l'authentifier une fois et d'être authentifié auprès de tous les autres services.
- Single Logout ( Déconnexion unique )
- Principe qui permet de se déconnecter sur tous les services du réseau à partir d'un seul point du réseau.
- Name Identifier
- LECP, Liberty Enabled Clients or Proxies ( les clients qui parlent «Liberty Alliance» ).
- Il s'agit d'une application qui est capable d'interagir directement avec un fournisseur d'identité.
 |
Lasso est une implantation libre des spécifications Liberty Alliance développées par la Société Entr'Ouvert ( http://www.entrouvert.org). Il s'agit d'une bibliothèque écrite en langage C qui permet de mettre en oeuvre les spécifications Liberty Alliance. Elle est disponible sous licence GNU General Public Licence (http://www.gnu.org/copyleft/gpl.html ). |
Les bibliothèques utilisés dans Lasso
- libxml2
- pour la gestion des fichiers au format XML. (http://www.xmlsoft.org)
- XML Security Library
- pour la gestion des standards de sécurité du format XML (signature et chiffrement des requêtes et documents XML). (http://www.aleksey.com/xmlsec)
- OpenSSL
- pour la gestion du chiffrement et des certificats SSL. (http://www.openssl.org)
- GObject
- pour la gestion des objets en langage C. (http://developer.gnome.org/doc/API/2.0/gobject)
Pour l'instant la bibliothèque implémente seulement la spécification ID-FF de «Liberty Alliance», c'est-à-dire la fédération d'identité.
Il existe des sur couches en Python, PHP, C# et Java qui permettent d'utiliser la bibliothèque.
La bibliothèque qui est développée sous GNU/Linux, fonctionne sous les différents environnement Unix (*BSD, Mac OS X, etc ... ) mais aussi sous Microsoft Windows.
Le projet est développé dans le cadre du programme «Carte de Vie Quotidienne» de la communauté du Grand Nancy et la ville de Vandoeuvre-lès-Nancy.
L'équipe de développement est composée de 6 personnes :
- Emmanuel Raviart
- Frédéric Péters
- Nicolas Clapies
- Romain Chantereau
- Valéry Febvre (travaillant pour Easter-Eggs)
- Christophe Nowicki (travaillant pour Easter-Eggs)
Il s'agit d'une solution logicielle, qui permet aux utilisateurs d'un réseau d'accéder, en toute transparence, à l'ensemble des ressources autorisées, sur la base d'une authentification unique effectuée lors de l'accès initial au réseau. Un seul mot de passe permet ainsi d'accéder à l'ensemble des applications et des systèmes.
Les avantages d'un système d'authentification simplifié
- une centralisation de l'authentification sur un serveur qui est le seul à accéder aux mots de passe des utilisateurs.
- apport ergonomique pour l'utilisateur, qui n'a plus besoin de se souvenir de tous ses mots de passe.
- centralisation de la politique de sécurité, comme le système d'authentification est centralisé, il est plus facile d'appliquer une politique de gestion des mots de passe.
- Le principal veut accéder à un service qui demande une authentification.
- Le fournisseur de service rédirige le principal vers le fournisseur d'identité.
- Le principal s'authentifie auprès du fournisseur d'identité.
- Le fournisseur d'identité redirige le principal vers le fournisseur de services et lui donne un artefact d'authentification.
- Le principal donne l' artefact au fournisseur de service.
- Le fournisseur de service demande au fournisseur d'identité de valider l' artefact.
- Le fournisseur d'identité valide l'artefact, ce qui authentifie le principal.
- Le fournisseur de service redirige le principal vers le service.
Il s'agit de déconnecter un utilisateur de tous les fournisseurs de services en une seule fois. Au lieu d'avoir à se déconnecter lui-même de chaque service, il se déconnecte une seule fois auprès du fournisseur d'identité
- Le principal veut se déconnecter de tous les services, pour cela il clique sur le bouton «logout».
- Le fournisseur de services redirige l'utilisateur vers le fournisseur d'identité avec une demande de déconnexion.
- L'utilisateur présente sa demande de déconnexion.
- Le fournisseur d'identité envoie une requête SOAP vers le fournisseur de services sur lequel le principal a été authentifié.
- Le fournisseur de service détruit la session de l'utilisateur et répond à la requête.
- Le fournisseur d'identité fait autant de requêtes SOAP qu'il y a de sessions ouvertes par l'utilisateur sur les fournisseurs de services.
- Chaque fournisseur de services détruit la session et répond à la requête.
- Le principal est déconnecté de tous les services.
Les spécifications Liberty définissent plusieurs façons de réaliser une action. Il y a par exemple 3 façons différentes d'effectuer un SSO. Ces différentes méthodes sont appelées profils (profile en anglais).
Les profils pour le Single Sign-On
- Single Sign-On using Artifact Profile
- Il s'agit d'une rédirection HTTP de l'utilisateur vers le fournisseur d'identité, celui-ci revient vers le SP avec un "Artifact" que le fournisseur de services va valider auprès du fournisseur d'identité.
- Single Sign-On using Browser POST Profile
- Il s'agit de la même technique mais cette fois-ci l'utilisateur valide un formulaire à l'aide de la requête HTTP POST et non une redirection HTTP.
- Single Sign-On using LECP Profile
- Il s'agit d'un client compatible Liberty Alliance qui se connectera directement sur le fournisseur d'identité grâce à une requête SOAP.
Les profils pour le Single Logout
- Single Logout (IdP Initiated) HTTP-Redirect
- Il s'agit de déconnecter l'utilisateur à partir du serveur d'identité en le dirigeant vers le fournisseur de service sur lequel il est connecté à l'aide d'une redirection HTTP. C'est une méthode assez lourde lorsque l'utilisateur est connecté à plusieurs fournisseurs de services.
- Single Logout (IdP Initiated) HTTP-GET
- Le fournisseur d'identité affiche une page avec des liens dans une page qui pointe vers les différents fournisseurs de service ou l'utilisateur est connecté. Il s'agit généralement d'une page avec des images qui se trouvent sur les différents fournisseurs de services.
- Single Logout (IdP Initiated) SOAP
- Le fournisseur d'identité envoie un message SOAP au fournisseur de services pour le prévenir que la session de l'utilisateur est terminée.
- Single Logout (SP Initiated) HTTP-Redirect
- Le fournisseur de services rédirige l'utilisateur vers le fournisseur d'identité.
- Single Logout (SP Initiated) - SOAP
- Le fournisseur de service envoie un message SOAP au fournisseur d'identité.
Les profils pour notifier la fin d'une fédération
- Federation Termination Notification (IdP Initiated) - HTTP-Redirect
- Le fournisseur d'identité renvoie par une rédirection HTTP l'utilisateur vers le site du fournisseur de service pour lui signaler la fin d'une fédération.
- Federation Termination Notification (IdP Initiated) - SOAP/HTTP
- Le fournisseur envoie un message SOAP pour signaler au fournisseur de services que la fédération pour cette utilisateur est terminée.
- Federation Termination Notification (SP Initiated) - HTTP-Redirect
- Le fournisseur de service renvoie avec une rédirection HTTP l'utilisateur vers le site du fournisseur d'identité pour lui signaler la fin d'une fédération.
- Federation Termination Notification (SP Initiated) - SOAP/HTTP
- Le fournisseur envoie un message SOAP pour signaler au fournisseur d'identité que la fédération pour cet utilisateur est terminée.
Au cours de mon stage, on m'a demandé d'écrire une extension pour le langage PHP. Il s'agit d'un «binding» au dessus de la bibliothèque. Celui-ci permet d'écrire un fournisseur de service et un fournisseur d'identité à l'aide du langage PHP et des spécifications Liberty Alliance.
Un «binding» est une interface dans un autre langage de programmation. Dans notre cas, la bibliothèque Lasso est écrite en ANSI C, et nous avons besoin d'utiliser les fonctionnalités de la bibliothèque dans un langage de programmation plus approprié pour le Web, tel que le PHP.
 |
PHP est un langage de script objet permettant de gérer un site Internet de A à Z, en allant de la simple génération de documents au format HTML à la production d'images PNG à la volée en passant par les requêtes aux serveurs de données, l'envoi automatique de mails ou encore le chiffrement des données. Il est très complet et évolue vite, en parfaite adéquation avec le couple terrible GNU/Linux et le serveur Web Apache. Il s'agit d'un logiciel libre sous licence PHP. Ce langage a l'avantage d'être très facilement extensible notamment grâce à une API en C. |
Une extension PHP se présente sous forme de bibliothèque dynamique (fichier «.so» sous Unix et «.dll» sous Microsoft Windows). Celle-ci permet d'ajouter des nouvelles fonctions au langage et d'étendre les possibilités. Dans notre cas, nous avons besoin d'appeler la fonction de la bibliothèque Lasso à partir d'un script PHP afin de bénéficier de ces fonctionnalités. (SSO, Federation, etc ... ). Pour cela il faut écrire des fonctions et une API en tenant compte des spécificités du langage.
Cette extension mappe près de 60 fonctions de la bibliothèque et permet d'écrire un fournisseur de services en PHP. Je l'ai développé en une semaine à l'aide de la documentation fournie sur le site de PHP et d'un compilateur C. Il y a eu une réécriture du binding par le biais de l'outil libre SWIG (Simplified Wapper and Interface Generator), car cet outil realise des binding de meilleure qualité et de façon plus simpl et rapide au\une écriture manuelle..
Afin de tester le bon fonctionnement de l'extension, j'ai écris des tests unitaires. Il s'agit de tester un seul module logiciel, indépendamment du reste du programme, afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toute circonstance. Cette vérification est essentielle dans les applications critiques, et s'accompagne d'une vérification de la couverture de code, c'est-à-dire que le test passe dans la totalité (ou une fraction de la totalité) des branchements possibles. Le test unitaire doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements, ce qui est très utile dans notre cas car la «couche» base du programme évolue très vite. Il y a de nombreuses modifications dans l'API de la bibliothèque C et il arrive souvent que la bibliothèque ne fonctionne plus.
Au cours de mon stage, j'ai fais un rapide audit des différentes solutions de mise en oeuvre de SSO en PHP. Il existe très peu de solutions de SSO en PHP et aucune n'est basée sur les spécifications standard comme ceux de Liberty Alliance. Il n y a pas de solutions entièrement libres pour réaliser un SSO en PHP.
L'extension Lasso pour PHP est la première solution entièrement libre.
Les solutions qui j'ai trouvés pour mettre en oeuvre un SSO en PHP sont les suivantes
C'est-à-dire des solutions sous licence libre reposant sur un «framework» propriété. Ces solutions sont basées sur le langage propriétaire de Sun Java.
CAS ( http://www.yale.edu/tp/cas ) est un système de SSO développé par la prestigieuse université de Yale. Il s'agit d'un système de SSO qui utilise un serveur écrit en Java qui distribue des tickets lorsque l'utilisateur s'est bien authentifié. Le système ne gère pas la fédération d'identité ni le single logout. Le plus gros avantage de ce système c'est la simplicité de son interface de programmation. Il est très facile d'authentifier un utilisateur en quelques lignes de codes PHP.
Dans la dernière monture du serveur d'application de la société Oracle ( http://www.oracle.com ), il est possible d'ajouter des fonctionnalités de SSO à une application PHP qui utilise Oracle : http://www.oracle.com/technology/oramag/webcolumns/2003/techarticles/bennett_php.html
Il s'agit d'un module pour Apache ( mod_osso ), qui s'occupe d'envoyer les requêtes d'authentification vers le système d'authentification du serveur d'application d'oracle. Cette solution propose un simple SSO, sans fédération d'identité ni «single logout».
Pour montrer le bon fonctionnement de mon «binding» PHP. Un premier exemple de fournisseur de services a été écrit. Cet exemple sert à montrer la fonctionnalité de la bibliothèque et permet de documenter entre autre l'utilisation de l'API PHP. Pour m'aider dans cette tâche, j'avais à ma disposition la documentation en anglais sur l'écriture d'un fournisseur de services à l'aide du langage C :
http://lasso.entrouvert.org/documentation/writing-a-c-sp.html
et le code source d'un fournisseur de services écrit en Python par Emmanuel Raviart.
Pour simplifier la mise en place de l'exemple, j'ai écris une interface d'installation. Il faut simplifier la mise en place de l'exemple en entrant les informations importantes (Informations de connections à la base de données, chemin des différents fichiers) à l'aide d'une interface web et non en éditant des sources manuellement. Ma philosophie était la suivante : «plus l'exemple sera facile à mettre en place et plus l'API sera utilisé par les autres développeurs ».
Cette interface web permet d'indiquer les informations de connexion à la base de données sous forme de DSN (Data Source Name). Ce DSN se présente comme une URL classique : pgsql://sp:sp@localhost/sp
Il fournit les informations nécessaires à l'application pour se connecter à une base de données. Dans notre cas, il s'agit d'un base de données de type Postgres sur la machine locale et à la base «sp».
Cette notation est beaucoup plus facile que l'utilisation de plusieurs champs dans un formulaire.
L'interface d'administration du SP permet d'indiquer les informations le concernant : Le fichier metadata, les clés prive/publique et le certificat x509.
Il est possible de configurer un fournisseur d'identité en indiquant l'emplacement du fichier metadata, la clé publique et le certificat.
A propos de la configuration de l'application PHP. De nombreuses applications PHP stockent les informations de configuration dans la base de données.
Dans le cas des mes exemples, j'utilise une technique bien plus simple qui consiste à stocker la configuration de l'application sous forme de tableau PHP sur le disque dur. Le fonction «serialize» de PHP permet de linéarise une variable, c'est-à-dire transformer son contenu en chaîne de caractères. (cf. http://www.php.net/manual/fr/function.serialize.php) La fonction unserialize récupère cette chaîne de caractères sous forme de variable. Cela permet une gestion simple et efficace de la configuration.
Une fois le fournisseur de services configuré correctement, il est possible d'utiliser ces fonctionnalités.
Parmi ces fonctionnalités, il y a un système de gestion des utilisateurs simple.
Celui-ci permet d'obtenir les informations suivantes : identifiant de l'utilisateur sur le SP, l'identifiant de l'utilisateur sous sa forme XML, le nom et le prénom de l'utilisateur, ainsi que la date de création de son compte et la date de sa dernière connexion sur le site. Il est aussi possible d'effacer l'utilisateur de la base des comptes.
La page principale permet de s'authentifier par rapport à un IdP (Fournisseur d'identité) à l'aide de plusieurs méthodes (choix du profil de sso). Lorsque l'utilisateur n'est pas authentifié, il accède à cette interface :
Il peut s'authentifier en cliquant sur le bouton «login». Il est dirigé vers le fournisseur d'identité qui lui demande les informations d'authentification. Au moment de l'écriture du SP en PHP seule la méthode d'authentification par mot de passe HTTP a été implémantée par le fournisseur d'identité en Python mis à ma disposition.
Une fois l'utilisateur authentifié, il revient vers le fournisseur de services. Si l'utilisateur n'est pas présent dans la base du fournisseur de services, celui-ci lui demande des informations. Mon site demande le nom et le prénom de la personne.
Ce dialogue représente à lui seul la philosophie des spécifications «Liberty Alliance» . Il ne s'agit pas d'un système de Single Sign On classic. Le fournisseur d'identité ne dit pas au fournisseur de services que c'est l'utilisateur dont le login est «joe» et le mot de passe est «test» qui se connecte sur son site. Il lui dit simplement qu'il connait l'utilisateur et que celui-ci est bien authentifié et qu'il a le droit d'accéder à ce service. Il y a une relation de confiance entre le fournisseur d'identité et le fournisseur de service. Cette philosophie est différente par rapport aux systèmes de SSO classic et doit donner plus de confiance aux utilisateurs.
Techniquement cela, ce traduit par l'existence d'un identifiant unique, le name idenitifier partagé entre le serveur d'identité et le fournisseur de service. Il ne s'agit pas d'un identifiant unique pour un utilisateur partagé par tous les systèmes.
Une fois que l'utilisateur est authentifié, une session PHP classique est établie.
L'utilisateur peut accéder aux ressources privées du site. Une fois qu'il a fini, il peut se déconnecter grâce au bouton «logout» prévu à cet effet.
Le code source de ce projet est relativement petit, moins de 1000 lignes de codes en PHP/HTML ont été nécessaires. De plus la réécriture du «binding» PHP avec SWIG a permis de simplifier le code grâce à une approche orientée objet.
Le système de stockage des informations utilisé est la base de données relationnelle libre PostgreSQL ( http://www.postgresql.org/ ). Mon choix s'est porté vers ce système de gestion de base de données car je n'aime pas MySQL ( http://www.mysql.com ) et sa gestion laxiste des références. Il est très facile de convertir la structure de base pour MySQL en sacrifiant l'intégrité référentielle de la base, vue que MySQL ne gère par les clés étrangères et les intégrités référentielles.
Plusieurs modules Pear ( http://pear.php.net ) ont été utilisés pour simplifier le code source de l'exemple.
- DB
- Le module DB ( http://pear.php.net/package/DB ) permet d'avoir un niveau d'abstraction par rapport à la base de données utilisées.
- HTML_QuickForm
- Ce module permet de crée des formulaires HTML rapidement. ( http://pear.php.net/package/HTML_QuickForm )
- Log
- Le module Log ( http://pear.php.net/package/Log ) permet d'obtenir une abstraction au niveau de la gestion des «logs» de l'application. Il propose plusieurs méthodes de stockage des événements et une gestion de filtre d'événements. Grâce à ce module, il est possible de choisir l'emplacement des fichiers des événements dans l'application. La méthode la plus utile est le stockage dans une base de données relationnelle. Cela permet à l'administrateur d'avoir une «console de gestion» des événements et voir rapidement les problèmes survenus dans l'application. Il permet au développeur d'afficher les informations de «debugage» et de corriger les erreurs de programmation plus vite.
Une fois que l'écriture d'un SP en PHP est finie, je me suis lancé dans l'écriture d'un IdP en PHP. Un fournisseur d'identité est beaucoup plus complexe à écrire qu'un fournisseur de service; car il doit gérer la base de comptes des utilisateurs et leurs fédérations avec les différents fournisseurs de services.
Comme le fournisseur de services, celui-ci doit pouvoir proposer plusieurs méthodes possibles pour effectuer une action.
Pour m'aider dans cette tâche, j'avais à ma disposition le code source d'un IdP écrit en langage C, un IdP écrit en Python, mais aucune documentation n'était disponible sur l'écriture d'un IdP.
Le code source du fournisseur d'identité est beaucoup plus grand. Ce dernier fait plus de 2000 lignes de code en PHP/HTML.
Comme pour le fournisseur de services, il est possible de configurer la base et les différents certificats à l'aide d'une interface HTML
L'écran de configuration du fournisseur d'identité est beaucoup plus complexe. Il est tout d'abord possible d'indiquer les informations de configuration de la base de données.
Le fournisseur d'identité s'occupe de l'authentification des utilisateurs. Pour s'authentifier les utilisateurs doivent fournir un login et un mot de passe valides. Pour récupérer ces informations, il existe plusieurs techniques : l'authentification HTTP basique (le navigateur de l'utilisateur lui demande un login/mot de passe à l'aide d'une fenêtre pop-up), formulaire HTML (l'utilisateur remplit un formulaire et le soumet au site grâce à une requête «post» HTTP). Les deux méthodes d'authentification sont implémantées dans mon IdP. Il est possible d'ajouter d'autres méthodes d'authentification plus solides assez facilement, comme par exemple une authentification par certificat SSL, ou bien une authentification via une Carte à Puce. (Smart Card).
Il est possible de configurer le niveau de «logs» ainsi que le gestionnaire de sauvegarde. Grâce au paquet Log de Pear, plusieurs gestionnaires de logs sont disponibles. Tout d'abord, le gestionnaire NULL qui ne sauvegarde pas l'activité sur le serveur, un gestionnaire Syslog qui la sauvegarde dans le programme du même nom. Et le gestionnaire par défaut, sql qui sauvegarde l'activité du serveur dans une table de la base de données.
On peut configurer les «metadata» du fournisseur d'identité et les certificats SSL. Pour l'instant il est possible seulement d'indiquer, le chemin des fichiers PEM. Ces fichiers PEM contiennent, le certificat et la clé publique du serveur.
Grâce à cette interface, il est possible d'ajouter n'importe quel nombre de fournisseur de services. Comme la saisie de «metadata» est une opération longue et fastidieuse, j'ai écris une page pour pouvoir les saisir et les éditer sans connaître la syntaxe XML de ces fichiers.
L'édition des fichiers «metadata» se fait aussi facilement à l'aide d'une interface d'un formulaire HTML
Exemple de fichier «metadata» Liberty Alliance utilisé par Lasso pour un fournisseur de services
Ce fichier XML décrit le fournisseur de services dont l'adresse Internet est https://sp1 et le provider ID est https://sp1/metadata.
L'interface de gestion permet d'effectue les tâches suivantes
-
effacement d'un utilisateur
-
voir l'identité et la session de l'utilisateur sous sa forme XML
-
voir la date de création de l'utilisateur
-
voir la liste des fédérations de l'utilisateur et terminer une fédération.
L'interface propose à l'administrateur du serveur d'identité de se déplacer facilement parmi les utilisateurs à l'aide d'un système de pagination.
Il est possible d'afficher tous les utilisateurs d'un coup, les sélectionner pour effectuer des actions, se déplacer entre les pages qui contiennent en moyenne 8 utilisateurs. L'interface affiche aussi les fédérations du l'utilisateur avec les fournisseurs de services.
Celui-ci indique, la date, le nom du fichier, l'importance de l'évènement et le message. Grâce à cette interface, on peut voir l'activité sur le serveur, garder des traces de cette activité et identifier les problèmes. Cette interface, m'a permis d'accélérer le développement de l'application.
La partie la plus dure du développement du fournisseur d'identité est la gestion des messages SOAP. Ces messages sont échangés entre les différents serveurs sans que l'utilisateur (et donc le développeur) ne les voie. Grâce au stockage des événements dans la base, il est possible de voir les messages échangés entre les serveurs et donc de les corriger plus aisément.
Il est aussi possible de s'authentifier en «local» sur le fournisseur d'identité.
Il ne s'agit pas de SSO, mais simplement d'une authentification sur l'IdP pour géré le profil utilisateur qui se trouve sur l'IdP. Une fois l'utilisateur authentifié localement sur son fournisseur d'identité, il peut gère son profil. Pour l'instant, il lui est possible seulement de terminer des fédérations avec des fournisseur d'identité.
Cette fonctionnalité sera utile plus tard lorsque l'utilisateur pourra éditer et gerer ces attributs à partir du serveur d'identité.
Le support des sessions PHP est un moyen de préserver des données entre plusieurs accès. Le principal problème vient du fait que le protocole HTTP est un protocole sans état et sans gestion de session. Grâce au système de gestion des sessions de PHP il est possible de contourner le problème en assignant un identifiant unique, appelé «identifiant de session» à chaque utilisateur. Cette identifiant se propage à l'aide d'un «cookie» ou bien dans une URL.
Le support des sessions enregistre un nombre illimitée de variables.
Par défaut ces variables sont stockés sous forme de fichiers textes sur le système de fichiers du serveur HTTP dans un répertoire prévu à cet effet.
On peut changer ce comportement et réaliser son propre gestionnaire de session. Dans mon cas, le gestionnaire de sessions par défaut de PHP était trop limité : il ne permet pas de voir toutes les sessions en cours sur le serveur. Cette limitation est voulue. L'objectif est d'empecher sur un serveur HTTP «mutualise» de lire les sessions d'un autre site. Pour contourner cette limitation, il faut écrire un gestionnaire de session qui stocke les informations dans une base de données relationnelle. Cela permet de connaître exactement le nombre d'utilisateurs sur le site.
Une session correspond à un client connecté sur le site.
C'est le gestionnaire de sessions le plus simple, lorsque l'utilisateur se ballade sur le site on lui attribue un identifiant de session, lorsque celui-ci veut accéder à un contenu protégé par mot de passe. Il crée une session Liberty Alliance avec le fournisseur d'identité. On conserve cet identifiant de session et le «name identifier» dans une table. Lorsque l'utilisateur ferme sa session localement, c'est à dire à partir du fournisseur de services, on détruit la session et on efface l'identifiant de la table. Dans le cas d'un utilisateur qui est parti sur un autre fournisseur de services c'est l'IdP qui nous informe que la session de l'utilisateur doit être détruite à l'aide d'un message SOAP.
Le fait de stocker les identifiants de session PHP dans une table nous permet de connaître le nombre d'utilisateurs présents sur le site et quel est leur fournisseur de services. Le fournisseur de services permet de voir les sessions SSO en direct sur le serveur.
Du coté du fournisseur d'identité, le même système de stockage est utilisé. Les sessions PHP évitent de demander les informations d'authentification lors d'une demande d'authentification de la part d'un fournisseur de services. Lorsqu'un utilisateur vient de la part d'un fournisseur de services pour se faire authentifier auprès de l'IdP la première fois, une session est démarrée sur le fournisseur d'identité pour l'utilisateur. Si l'utilisateur s'authentifie correctement sur le serveur, les informations sur son identité sont stockées dans la session PHP. Lorsque l'utilisateur revient pour une autre authentification de la part d'un autre SP, ou bien de la part d'un même SP qui veut vérifier la validité de la session. Il suffit de récupérer les informations sur l'identité de l'utilisateur dans la session puis les valider. Si les informations sont valide, l'utilisateur n'aura pas besoin de fournir les informations d'authentification. C'est sur ce principe que marche le système de Single Sign On de «Liberty Alliance».
Les sessions PHP sont utilisées lors d'un «Single Logout» de l'utilisateur. Quant celui-ci désire fermer sa session, Il clique sur un bouton sur le site du fournisseur de services qui informe le fournisseur d'identité que l'utilisateur doit se déconnecter. A ce moment là, le fournisseur de service informe le fournisseur d'identité de l'évènement. Celui-ci détruit la session de l'utilisateur en question. Dans le cas d'un message SOAP envoyer par le fournisseur de service au fournisseur d'identité, il n'est pas possible de récupérer les informations sur l'utilisateur dans la session courante, car si on démarre une session, cette session sera une session qui identifie le fournisseur de services et non l'utilisateur qui a demandé d'être déconnecté.
Comme pour le fournisseur de services nous savons à qui appartient la session donc nous pouvons afficher les utilisateurs connectés et les sites sur lesquels ils sont actuellement connectés.
 |
Le principal problème qui se pose, c'est la gestion de la durée d'une session PHP. Il n'est pas envisageable d'avoir une session sans fin. Dans le cas d'un utilisateur connecté à partir d'un point public, comme un «cyber café» cela pose problème. Dans le cas d'une session SSO simple nous avons au moins 3 sessions (deux sessions de type PHP et une session de type «Liberty Alliance») . C'est-à-dire qu'il faut gère les trois sessions et leur durée pour éviter d'avoir des problèmes de désynchronisation de sessions. |
Pour bien comprendre à quoi peuvent bien servir ces deux sites en PHP, Il faut décrire les différentes topologies possibles de réseaux fédérée. J'ai tiré ces exemples de topologie dans le site de la société PingID qui distribue le projet Source ID. Elles sont tirées de leurs observations sur le terrain.
 |
Dans cette topologie, une entité propose un service qui est utilisé par plusieurs entreprises. Par exemple une entreprise de services qui propose un site de gestion comptable. Cette structure permet de délocaliser plus facilement les applications de l'entreprise. Il s'agit d'une application qui se trouve en dehors des limites de l'entreprise. Dans ce cas, les managers de l'entreprise aimeraient pouvoir contrôler qui accède au service. Pour les employés de l'entreprise cette application est vu de la même façon que n'importe quel autre application métier et s'intègre parfaitement dans l'environnement de travail habituel. L'utilisateur utilise son login et mot de passe comme d'habitude mais l'application qu'il utilise est delocalisée et n'est pas sous le contrôle de l'entreprise. Cette topologie devrait particulièrement intéresser les entreprises qui font de la gestion de l'épargne salariale, des solutions de gestion de contenu. |
 |
Il s'agit d'une topologie totalement opposée a la précédente, et elle ressemble à un mini système Microsoft Passport. Effectivement, les entreprises qui gèrent beaucoup d'informations sur l'identité des clients, comme les fournisseurs d'abonnement à Internet (AOL, Free, Nerim, ... ), ou bien les portails (Yahoo, MSN, Caramail, ...) peuvent apporter des services à leurs clients. Le client se connectera sur son portail habituel et se verra proposer une certaines quantité de services. Ce type de topologie est utilisé dans les systèmes de "B2C" et sont généralement orientés vers l'utilisateur et le client final. |
 |
Petit à petit, avec l'établissement des relations entre les différents fournisseurs de services et les fournisseurs d'identifié. La topologie utilisée est de plus en plus dure à définir. On arrive comme dans le cas de l'Internet d'un réseau d'identité fédère dans lequel l'identité de l'utilisateur se balade librement. Néanmoins, on peut distinguer deux types de relations cross domaine : Les cross domaine interne à l'entreprise et les cross domaines externe. Dans le premier cas il s'agit principalement de multinationales qui à force coups d'acquisitions et de fusions se retrouvent avec des systèmes d'authentification hétérogènes. Il est très difficile de certifier que le bon utilisateur auras les droits d'accéder à la bonne ressource. Il est donc plus aisé de créer une fédération entre les deux départements et de donner les bons droits que d'essayer d'unifier les systèmes. La deuxième topologie de ce type est la topologie externe à l'entreprise qui a force de fédérer des services donne le droit à une autre société de fédérer d'autres entités. Cette relation de confiance permet de créer des fédérations a sa place. Un sorte de réseau de confiance entre fournisseurs. |
Les sources des mes programmes sont disponible sur le serveur CVS du projet Lasso, http://lasso.entrouvert.org/download dans le répertoire php/examples. Si vous voulez ajouter un système de SSO a votre application en PHP, n'hésiter pas a contacter les personnes d'Entr'Ouvert (http://www.entrouvert.org). Plusieurs projets sont en cours, notamment la rédaction d'une documentation développeur. Nous envisageons aussi de transformer le navigateur Mozilla (http://www.mozilla.org/).
Site Web du projet Lasso
Sources, Documentation, Base de Bugs http://lasso.entrouvert.org/
Site Web du projet Liberty
Le spécifications Liberty Alliance : http://www.projectliberty.org/
Site Web du projet Source ID
Nombreux documents techniques en anglais qui décrivent la fédération d'identité http://www.sourceid.org/content.do?page=Welcome
Description d'un architecture basée sur les spécifications Liberty Alliance
Description d'un architecture basée sur les spécifications Liberty Alliance : http://www.easter-eggs.com/article_346_Liberty_Alliance_SSO_deploiement_des_services.html.
Liberty Alliance Project, Meilleures pratiques pour le respect de la vie privée et la sécurité
Christine,
Varney
12 Novembre 2003
Liberty Alliance Project, Meilleures pratiques pour le respect de la vie privée et la sécurité : http://projectliberty.org/specs/Meilleures_Pratiques.pdf.
Introduction aux architectures web de Single Sign-on
Novembre 2003
Description d'une architecture SSO pour le Web http://www.cru.fr/sso/jres-sso/.
Introduction à la technologie SOAP
Une très bonne introduction à la technologie SOAP en français : http://www.soapuser.com/fr/basics1.html