2008 mikael.ates@univ st etienne.fr
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 2
Contexte La gestion des identités (IdM Identity Management) est une composante majeure de la sécurité des systèmes d'information. En 2005, peu de projets libres adressent la gestion des identités intra et inter systèmes d'information au travers des technologies de fédération des identités. Volonté initiale: Tirer les bénéfices des normes et standards web et de fédération. Concurrencer des solutions propriétaires 3
Contexte FederID adressera deux problématiques de la IdM: La gestion de référentiels d'identités numériques. La délégation de tâches administratives sur les identités entre applications web. 4
Historique Juin 2005 : Décision de participer à l'appel à proposition du RNRT Été 2005 : Formation du consortium : Entr'ouvert, Linagora, ISTASE, ObjectWeb et Thales Décembre 2005 : Projet validé par l'oseo et l'anr, nom de code du projet : FederID Février 2006 : Premières réunions du consortium FederID Avril 2006 : Présentation du projet FederID à la réunion des architectes OW à Grenoble et lancement officiel du projet (T0) 5
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 6
Les Technologies du Web Le transport de messages de requêtes/réponses (HTTP IETF RFC). La sécurité niveau transport (SSL/TLS IETF RFC). Transport, formatage, sécurité et sémantique des messages (ML W3C). Les composants applicatifs: applications et services web. applications réparties ou «architectures orientées services web (wsoa)». 7
La fédération d'identité en qq mots... Partenariat entre organisations: Accords sur les protocoles, espaces de nom, les contextes d'authentification, algorithmes de chiffrement et signature, etc.. Interopérabilité / Ouverture des systèmes d'information pour l'echange d'informations certifiées sur les identités. Attributs certifiés Établir l'identité d'un utilisateur à partir d'une organisation partenaire. Membre d'une organisation partenaire. 8
La fédération d'identité en qq mots... Architecture sensible à cause du transport entre systèmes d'informations d'informations personnelles potentiellement confidentielles. Respect de la vie privée et des lois. Exemple des 2 directives européennes: The Framework Data Protection Directive 95/46/EC (Directive) et The Electronic Communications Data Protection Directive 02/58/EC (ECDP Directive) Interfaçage utilisateur conçu pour permettre à l'utilisateur d'interagir (localisation de la source), d'opérer/d'acquitter les opérations d'association d'identité et de diffusion d'information personnel. Couplage de technologies de sécurité: cryptographie transport et applicatif(sig(trust) + enc(passivereq)) et déploiement de systèmes à pseudonymes (avoid collusion). Facilitation des interactions utilisateurs selon besoin. Ex: SSO. 9
La fédération d'identité en qq mots... C'est une architecture permettant la délégations de tâches administratives portant sur les identités par des applications et services Web (fournisseur de services SP) auprès d'autorités. Les SP s'appuient sur des autorités pour l'établissement de l'identité des utilisateurs (fournisseur d'identités IdP) et la diffusion d'attributs (fournisseurs d'attributs AP) L'architecture de fédération s'appuie sur une architecture de confiance pour autoriser les échanges. Ainsi, les SP et autorités forment un cercle de confiance (CoT). 10
Exemple d'un cercle de confiance Site de consultation de contenus scientifiques partenaire de l'université de Saint Etienne (Fournisseur de Service) Interactions Utilisateur Université Paris Consultation de cours en ligne. Accessible à tous les enseignants des université françaises. (Fournisseur de Service) 5 Échanges «systèmes» 4 1 10 7 2 / 6 3 Fournisseur d'identité 9! 8 Référentiel d'identité central (Annuaire) 11 Fournisseur d'attributs d'identités Université de Saint Etienne
Les spécifications existantes OASIS SAML2 (SAML1.1 + Liberty Alliance ID FF1.2 + Shibboleth 1.3) Liberty Alliance ID FF et IDWSF. WS Federation (WS *) (Consortium Microsoft, IBM, Verisign, etc. normalisation OASIS en cours) Microsoft Cardspace (WS *) Le choix de FederID basé sur les critères suivant: Zero footprint (première étape) Standards complets, ouverts et éprouvés. 12
La gestion des identités intra SI De multiples référentiels d'identités : Annuaires, bases de données et «fichiers textes» La norme majeure est LDAP : modèle d'information, espaces de noms, protocole d'accès et considérations de sécurité. Deux sous objectifs de FederID: Cycle de vie des identités et synchronisation de référentiels. Interfaces d'administration. 13
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 14
Les briques de base Les acteurs du projet apportent certaines briques qui constituent la base des développements : Lasso : bibliothèque C gérant les échanges Liberty Alliance et SAML. Authentic : fournisseur d'identité basé sur LASSO. InterLDAP : gestion de contenu LDAP. LemonLDAP::NG : WebSSO et gestion centralisée des autorisations (Choix d'un websso pour les applications non libertifiées et gestion des autorisations). + = + 15 +
Les briques finales Le projet FederID est la résultante des efforts de développements et d'intégration des logiciels suivants : Lasso : bibliothèque C gérant les échanges Liberty Alliance IDFF1.2 et IDWSF1.2 et SAML 2.0. Authentic : Fournisseur d'identité SAML2 et DS IDWSF1.2. InterLDAP : gestion de contenu LDAP (WUI), partage d'attributs sur un cercle LA IDWSF (LAAP) et synchronisation d'annuaires (LSC). LemonLDAP::NG : WebSSO et gestion centralisée des autorisations compatible SAML2. + = + 16 +
Étude des licences LemonLDAP::NG : GPL v2 Lasso, Authentic : GPL v2 ou ultérieur InterLDAP et modules WUI, LAAP, LSC : Sun Microsystems, Inc. Binary Code licence Agreement Apache MIT JDOM (BSD like) CDDL GPL v2 ou ultérieure Sun API BSD 17
Étude des licences Problématique de distribution La compatibilité se pose en terme de briques distribuées ensembles. La GPL s'étend à l'ensemble comprenant une partie sous GPL Arrivée de la GPL, LGPL et AGPL v3 en 2007 Composants GPL v2 incompatibles avec la LGPL Composants CDDL, APL incompatibles avec la GPL v2 mais pas v3 Choix de la licence Une distribution de projets indépendants agencés ensemble en une suite logicielle avec des licences compatibles entre elles LemonLDAP::NG : GPL v2 Lasso : GPL v2 ou ultérieure Authentic : GPL v2 ou ultérieure InterLDAP, modules WUI et LSC : AGPL v3 InterLDAP, module LAAP : AGPL 18
Prototype FederID 19
AVAIBLE NOW on federid.org Démonstrations accessibles en ligne : http://lemonldapng.demo.interldap.org/ http://wui.demo.interldap.org/ http://laap.demo.interldap.org/ http://authentic.demo.interldap.org/ http://unwind.demo.interldap.org/ www.federid.org Install Authentic... <10 minutes! 20
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 21
Cas d'usage Problématique Soient 2 organisations A et B. Chacune des organisations possède un annuaire LDAP. L'organisation A possède déja une solution de SSO basée sur SAML2 et qui implémente l'idp proxying SAML2. Objectifs Permettre la consultation des annuaires aux utilisateurs des 2 organisations tout en offrant la possibilité aux utilisateurs de modifier les informations les concernant. Permettre l'accès aux applications des 2 organisations à l'ensemble des utilisateurs. 22
Cas d'usage Organisation A Applications de l'organisation Applications de l'organisation Fournisseur d'identité SAML2 de la marque Organisation B Annuaire LDAP standard Annuaire LDAP standard Utilisateurs Utilisateurs Données de l'entreprise 23 Données de l'entreprise
Cas d'usage La solution FederID Phase 1 InterLDAP WUI pour l'interfaçage des annuaires LDAP. Dès lors, les utilisateurs pourront s'authentifier sur cette interface et modifier les informations les concernant. Mise en oeuvre d'une fédération dans B avec un IdP Authentic qui s'appuie sur le LDAP. Intégration des InterLDAP WUI comme SP dans leur fédération respectives, InterLDAP WUI sera intégré à la fédération existante de A conforme SAML2. 24
Cas d'usage Organisation A Applications de l'entreprise Fournisseur d'identité SAML2 de la marque Fournisseur d'identité Authentic Applications de l'organisation Organisation B Annuaire LDAP standard Annuaire LDAP standard WUI Interface Web WUI Interface Web Utilisateurs Utilisateurs Données de l'entreprise 25 Données de l'entreprise
Cas d'usage La solution FederID Phase 2 Soit on lie tous les SP à tous les IdPs (e.g. WAYF sur SP). Soit, on utilise la fonctionnalité de «proxying» SAML2 (schéma): Il est possible que le lien de confiance soit indirecte entre SP et IdP (gestion centralisée de la confiance dans un SI), l'authentification est déléguer sur un IdP auquel le SP n'est pas lié puis établie sur une identité proxy sur l'idp sur SP qui permet d'établir l'identité sur le pseudo (2 pseudonymes). e.g. WAYF sur IdP 26
Cas d'usage Organisation A Applications de l'entreprise Fournisseur d'identité SAML2 de la marque Fournisseur d'identité Authentic Applications de l'organisation Organisation B Annuaire LDAP standard Annuaire LDAP standard WUI Interface Web WUI Interface Web Données de l'entreprise Utilisateurs Données de l'entreprise 27
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 28
{Spécifications, Standard, Normes} & Interopérabilité Requêteur passif SAML based: Convergence vers SAML2: SAML2 dans LA, Shibbolteh2.0, etc... Requêteur passif: SAML2 et WS Fédération PRP: Concordia Q1 2008, Article Ates SITIS Décembre 2007. Non prévu. SAML1.1 (Shib1.3f) et WS Federation 1.0 (ADFS sur W2003R2) opérationnel par module sur composants shibboleth. Requêteur actif: IDWSF Advanced Client et Cardspace à implémenter sur un même selecteur. En cours d'étude. Contextes d'authentification (Authn sur IdP) sur IdP SAML2: OpenID (Concordia / NTT & NRI en cours... «maybe at DIDW» (Paul Madsen)) et Cardspace (Concordia Q1 2008 RSA Conf). En cours de réalisation sur Authentic. De la même façon, Interopérabilité CoT SAML2 vers CoT Cardspace possible mais pas l'inverse avec SAML2 en passif. En cours de réalisation sur Authentic. 29
Sommaire Présentation générale Standards et état de l'art Logiciels et licences Cas d'usage Interopérabilité A venir dans FederID et Avenir de FederID 30
A venir dans FederID: En cours de réalisation... LASSO: passage de IDWSF1.2 vers 2.0 Développements sur Authentic pour l'authentification avec OpenId et Cardspace. Mises à jours et développements de nouvelles fonctionnalités réguliers sur InterLDAP et LemonLDAP::NG. 31
A venir dans FederID: A l'étude... InterCoT au travers de clients actifs aussi appelé sélecteur d'identités. Étude de IDWSF, CardSpace et des questions d'interopérabilité. Étude de LemonLDAP::NG comme fournisseur d'autorisations dans un cercle de confiance. 32
FederID, une solution d'avenir Technologie : Implémentation de normes et standards solides. Acteurs actifs sur leur modules: corrections, améliorations, mises à jour et nouvelles fonctionnalités régulières. Orientation communes. Consortium/Communauté : Consortium vivant! Les membres participent à des projets de recherche et industriels de premier plan sur leur sujet. IRC, listes de diffusion, Wiki, etc... 33
FederID, une solution d'avenir Enjeu : Susciter l'engouement de la communauté OpenSource: Les architectures de fédération sont destinés à un public restreint Un public plus large est touché pour de l'intra SI: SSO: protocoles et softs FederID sont déjà éprouvés (certification de LASSO SAML2) Synchro de référentiels: Il y a beaucoup de travail, beaucoup d'intérêt mais peu d'engouement. Interfaçage annuaire: Gros besoin (GUI) et engouement. Les architectures user centric comme point d'entrée des fédérations et GUI: Grand public. La clé: Gestion des interactions utilisateur notamment au travers de architectures user centric / amélioration des GUI. 34
www.federid.org
Lasso API en C implémentant ID FF1.2, SAML2, IDWSF1.2 et 2.0 (en cours). Historique: Certification Liberty Alliance (mai 2005) Certification SAML 2.0 (décembre 2006) Binding Java, Perl, PHP, Python S'appuie sur des bibliothèques courantes, écrites en C et libres (Glib, Gobject, Libxml2, MLSec, OpenSSL) Multi plateforme (Testée sous GNU/Linux, FreeBSD, Mac OS et Microsoft Windows) 36
Authentic Fournisseur d'identité basé sur Lasso. Support de référentiels d'identités variés : LDAP V3 (Active Directory), Postgresql, MySQL. Relai de fournisseur d'identité SAML2 (SAML2 IdP Proxy) Annuaire de services de fédération ID WSF (Discovery Service). Génération et échange des meta données de fédération. 37
InterLDAP LAAP Fournisseur d'identité Liberty Alliance Utilisateurs LAAP Fournisseur d'attributs Liberty Alliance Annuaire LDAP standard Données de l'entreprise 38 Fournisseur de services Liberty Alliance
InterLDAP WUI Utilisateurs Consultation Administrateurs WUI Interface Web Gestion des autorisation et du schéma enrichi Gestion des accès Gestion des données LAAP Fournisseur d'attributs LSC Synchronisation des référentiels Service RH Applications de l'entreprise Annuaire LDAP d'entreprise 39 Données de l'entreprise
LemonLDAP::NG 40
Avenir de FederID: Positionnement concurrentiel Entreprise Produit IdP SP HP Select Federation IBM Tivoli Federated Identity Manager Novell Identity Provider Sun System Federation Manager Oracle IdP SP extended extended(no (norme IDrme ID-FF FF 1.2) 1.2) Identity Management NTT I-d Live CA SiteMinder FederID FederID SP Lite Attribute Attribute responder requester 41 IdP Lite
Cas d'usage Nouvel objectif: Diffuser des attributs des annuaires LDAP entre organisations pour le contrôle d'accès effectué par les SP. Les sources d'attributs par organisations pourront être multiples à l'avenir Contraintes: On souhaite utiliser IDWSF pour gérer les sources multiples et bénéficier du SSO, or, l'idp SAML2 de A n'est pas IDWSF. 42
Cas d'usage La solution FederID Phase 3: On va déployer un InterLDAP LAAP pas SI. On peut exploiter le DS IDWSF de d'authentic, qui va permettre aux SP d'aller consommer des attributs des AP avec l'accord de l'utilisateur. On enregistre les LAAP auprès de ce DS: Je suis de B, je vais toujours m'authentifier sur l'idp de B. Donc les SP de A et B pourront consommer avec mon accord des attributs de LAAP de A et B. Je suis de A, et je vais consommer des SP dans B. Je m'authentifie dans A, et lorsque l'idp Authentic de B reçois l'assertion de l'idp de A, il ajoute les informations IDWSF, pour permettre aux SP de consommer les attributs des LAAP de A et de B. Problème: Je suis de A et j'accède à des services de A. Pas de lien avec l'idp de B. 43
Cas d'usage La solution FederID Phase 3: Mettre un LAAP dans B qui s'appuie sur les annuaires de A et B, contraire à tout ce qu'on à dit et fait, les organisations n'accepteront jamais. Se limiter à une source d'attributs, l'idp SAML2 qui fournit des attributs dans les assertions. Bien mais limité. Se limiter à des sources d'attributs préalablement connues. AP SAML2 qui seront des SP pour bénéficier du SSO si distinctes de l'idp. Bien mais encore limité. Modifier l'idp A pour qu'il fournisse les informations IDWSF dans ses assertions d'authentification. Seule la localisation du DS/IdP est définie et donnée au consommateurs d'attributs, les emplacements des AP sont gérés par le DS. Mieux mais lourd et encore limité. Faire de l'idp SAML2 de A, un DS IDWSF. Bien mais lourd. Remplacer l'idp A par un Authentic. Le top. 44
Cas d'usage Applications de l'entreprise Organisation A Fournisseur d'identité et DS Authentic Fournisseur d'identité et DS Authentic Applications de l'organisation Organisation B Annuaire LDAP standard Annuaire LDAP standard WUI Interface Web WUI Interface Web Données de l'entreprise Données de l'entreprise LAAP Fournisseur d'attributs Utilisateurs 45 LAAP Fournisseur d'attributs