Liberty Alliance pour FederID. Pierre Cros <pcros@entrouvert.com>



Documents pareils
Implémentation libre de Liberty Alliance. Frédéric Péters

st etienne.fr

Formation SSO / Fédération

LemonLDAP::NG / SAML2. Xavier GUIMARD (Gendarmerie Nationale) Clément OUDOT (Groupe LINAGORA)

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants

Single Sign On. Nicolas Dewaele. Single Sign On. Page 1. et Web SSO

Authentification et contrôle d'accès dans les applications web

Architectures de fédération d'identités et interopérabilité

SAML et services hors web

Tour d horizon des différents SSO disponibles

Guide Share France. Web Single Sign On. Panorama des solutions SSO

Drupal et les SSO Nicolas Bocquet < nbocquet@linalis.com >

Secure Java Card for Federate Identity Management

Authentification avec CAS sous PRONOTE.net Version du lundi 19 septembre 2011

ENVOLE 1.5. Calendrier Envole

Service d'authentification LDAP et SSO avec CAS

La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014

WebSSO, synchronisation et contrôle des accès via LDAP

Mémoire de fin d'études

Responsable du cours : Héla Hachicha. Année Universitaire :

Authentification EoleSSO

Support de sources d'authentification multiples dans un portail de travail collaboratif

Single Sign-On open source avec CAS (Central Authentication Service)

Shibboleth. David Verdin - JOSY "Authentification centralisée pour les applications web" - Paris - 4 février mai

EoleSSO EOLE 2.3. Documentation sous licence Creative Commons by-nc-sa - EOLE (http ://eole.orion.education.fr) révisé : Septembre 2014

Un exemple d'authentification sécurisée utilisant les outils du Web : CAS. P-F. Bonnefoi

La gestion de l'identité en ligne

Les technologies de gestion de l identité

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO)

Emmanuel Dreyfus, janvier 2011 Emmanuel Dreyfus, janvier 2011

La gestion des identités dans l'éducation Nationale, état des lieux et perspectives

CAS, un SSO web open source. 14h35-15h25 - La Seine A

Sécurisation des architectures traditionnelles et des SOA

Formation en Logiciels Libres. Fiche d inscription

Authentification et Gestion des Identités. Jean-Noël Colin

CAHIER DES CHARGES D IMPLANTATION

Gestion des identités

Urbanisation des SI Conduite du changement IT 20/03/09. Patrick CHAMBET

Solutions d accès sécurisées pour opérer une Market Place Saas multitenante

La gestion des identités au CNRS Le projet Janus

DESCRIPTION DU COMPOSANT

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3.

REAUMUR-ACO-PRES. Wifi : Point et perspectives

Fédération d'identités et propagation d'attributs avec Shibboleth

Stratégie de sécurité grâce au logiciel libre. Frédéric Raynal Cédric Blancher

Oauth : un protocole d'autorisation qui authentifie?

Introduction aux architectures web de Single Sign-on

Plan. Présentation du logiciel Sympa Architecture La gestion des hôtes virtuels Listes avec inclusion des abonnés Les modules d authentification

Séminaire EOLE Dijon 23/24 novembre Architecture Envole/EoleSSO

Introduction. aux architectures web. de Single Sign-On

Sun Java System Access Manager Notes de version pour Microsoft Windows

Sommaire Accès via un formulaire d'identification... 4 Accès en mode SSO... 5 Quels Identifiant / mot de passe utiliser?... 6

DESCRIPTION DU PLUGIN D AUTHENTIFICATION AVEC CAS POUR SPIP

L'AAA, késako? Bruno Bonfils, fr.org>, Novembre Sous ce terme d'apparence barbare est regroupé l'ensemble des concepts suivants :

Hébergement de sites Web

CAS, la théorie. R. Ferrere, S. Layrisse

Evolutions du guichet de la fédération et gestion des métadonnées SAML

Groupe de travail Gestion des identités Les usages et les services ATELIER 2

Manuel d'installation

Présentation du relais HTTP Open Source Vulture. Arnaud Desmons Jérémie Jourdin

JOSY. Paris - 4 février 2010

Gestion des utilisateurs et Entreprise Etendue

Sécurité des sites Web Pas un cours un recueil du net. INF340 Jean-François Berdjugin

Gestion d identités PSL Installation IdP Authentic

L'intégration de Moodle à l'université Rennes 2 Haute Bretagne

Guide d'intégration de l'application IAM

Programmation Web Avancée Introduction aux services Web

Cédric Ouvry Bibliothèque nationale de France Liberty Alliance Deployment Workshop Paris December 7, 2005

Joomla! Création et administration d'un site web - Version numérique

Note Technique Sécurité. Système d'authentification. Authentification hors APN LuxGSM Authentification 3G/APN. Système de notification

Référentiel Général d'interopérabilité

Internet Information Services (versions 7 et 7.5) Installation, configuration et maintenance du serveur Web de Microsoft

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

Gestion des Identités : 5 règles d'or. Patrice Kiotsekian Directeur Evidian France

Programmation Web. Introduction

Documentation CAS à destination des éditeurs

Formation Webase 5. Formation Webase 5. Ses secrets, de l architecture MVC à l application Web. Adrien Grand <jpountz@via.ecp.fr> Centrale Réseaux

Introduction aux «Services Web»

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2).

Sécurisation d une application ASP.NET

LemonLDAP::NG. LemonLDAP::NG 1.2. Clément OUDOT RMLL 9 juillet 2012

EJBCA PKI. Yannick Quenec'hdu Reponsable BU sécurité

EXPOSE. La SuisseID, qu est ce que c est? Secrétariat d Etat à l Economie SECO Pierre Hemmer, Chef du développement egovernment

Déclarer un serveur MySQL dans l annuaire LDAP. Associer un utilisateur DiaClientSQL à son compte Windows (SSO)

Configuration des ressources dans VMware Workspace Portal

Par KENFACK Patrick MIF30 19 Mai 2009

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Sécurité des applications Retour d'expérience

Serveur de partage de documents. Étude et proposition d'une solution afin de mettre en place un serveur de partage de documents.

INFORMATIQUE & WEB. PARCOURS CERTIFICAT PROFESSIONNEL Programmation de sites Web. 1 an 7 MODULES. Code du diplôme : CP09

Outil de planification en ligne pour des créations de rendez-vous ou de sondage

Déclarer un serveur MySQL dans l annuaire LDAP. Associer un utilisateur DiaClientSQL à son compte Windows (SSO)

Authentification unique Eurécia

Aspects techniques : guide d interfaçage SSO

Avant-propos 1. Avant-propos Organisation du guide À qui s'adresse ce guide?...4

Direction de la Sécurité Sociale

Groupe Eyrolles, 2004 ISBN :

La fédération d identité Contexte, normes, exemples

Transcription:

Liberty Alliance pour FederID Pierre Cros <pcros@entrouvert.com>

Formateurs Pierre Cros pcros@entrouvert.com Frédéric Péters fpeters@entrouvert.com

Pourquoi Entr'ouvert a choisi Liberty Alliance Consultance en transparence et en démocratie Chantiers potentiellement liberticides Solutions de vote (besoin d'anonymat, éviter l'identifiant unique) Carte de Vie Quotidienne Nécessité de trouver une solution d'authentification forte respectant la vie privée

Pourquoi utiliser Liberty Alliance? Standard ouvert Aujourd'hui en production Sécurité et confidentialité Contrôle de l'utilisateur Certification assurant une compatibilité réelle Utilisé par l'administration française (ADAÉ) et recommandé par l'ue Gestion des aspects politiques et organisationnels

Standards concurrents : WS-* WS-Federation, WS-Security, WS-Trust, WSMetadataExchange (Microsoft, IBM, Verisign) Centré sur l'entreprise, b2b, b2e Utilisation de la confidentialité optionnelle. Relativement récent et peu déployé CardSpace (InfoCard)

Standards concurrents : Shibboleth Internet2 Spécifications et produit J2EE Licence Apache 2.0 Compatible SAML 2.0 Déploiements essentiellement universitaires (CRU)

Standards concurrents : OpenID Protocole de fédération simple et clair Pas de certification ou de big player Communauté peu étendue Pas de compatibilité SAML 2.0 Yadis = Discovery Service

Standards concurrents : LID Light-Weight Identity Pas de fournisseur d'identité Identité juste définie par une URL (CGI scriptable) Protocole de base (MinimumLID) + nombreux profils Communauté restreinte Pas de compatibilité SAML 2.0 Yadis = Discovery Service

Panorama des standards concurrents

Principales solutions Liberty Alliance Sun : Access Manager, Federation Manager Oracle : Identity Management Hewlett-Packard : OpenView Select Federation IBM : Tivoli Access Manager Novell : Novell Access Manager NTT : i-dlive

Solutions LA ouvertes : OpenSSO Sun (Access Manager) J2EE Petite communauté Common Development and Distribution Licence, non compatible GPL

Solutions LA ouvertes : Higgins Eclipse Trust Framework Novell, IBM J2EE Licence libre EPL, non compatible GPL CardSpace Liberty Alliance Bandit : WS-* + LA

Solutions LA ouvertes : SourceID Ping Identity J2EE Licence? Ping Federate, IdP propriétaire

Solutions LA ouvertes : ZXID Symlabs Plusieurs bibliothèques en C Différence avec Federated Identity Access Manager? Licence Apache 2.0 Code semblant difficile à exploiter

Solutions LA ouvertes : Lasso Lasso, Larpe, Authentic Les seuls en GPL

Le consortium Dirigé par Sun Regroupe les principaux acteurs à l'exception de Microsoft Forte présence des opérateurs de télécom En France : France Télécom, Caisse des Dépôts et Consignations, l'adaé (DGME)... Entr'ouvert!

Types d'utilisateur Early adopters Utilisateurs pragmatiques Ceux qui n'ont pas le choix

Glossaire Liberty Alliance Fournisseur de Service (SP) Fournisseur d'identité (IdP) Cercle de confiance (CoT) Assertion Identifiant Unique (NameIdentifier) Single Sign On Single Logout Fédération - Défédération

Trois types d'acteurs l'utilisateur : personne physique ou morale qui peut acquérir une identité (principal) ; le fournisseur d'identité (IdP) : crée, et gère l'identité des utilisateurs, et les authentifie auprès des fournisseurs de service ; le fournisseur de services (SP) : fournit des services aux utilisateurs une fois qu'ils sont authentifiés par un fournisseur d'identité.

Réseau d'identités Identités réparties sur plusieurs fournisseurs Difficulté de gérer plusieurs comptes

Fédération d'identités

Cercle de confiance

Le Single Sign On Utilisateurs : Gérer une seule identité Fournisseur d'identité : Gérer les identités de l'utilisateur et la communiquer aux SP Fournisseurs de Service : faire confiance à ce Fournisseur d'identité

Single Sign On Requête diffusée (du SP vers l'idp) par Redirect (taille limitée) POST Réponse (de l'idp vers le SP) POST Artifact (réponse complète échangée en SOAP)

Plusieurs cercles, indépendants

Certains services reliés

Encore plus de services reliés

Liaison par les IdP

Les metadata Fichier XML indispensable pour chaque SP et IdP Identifiant du Fournisseur Points d'entrée pour accéder à ses services Liberty Alliance Méthodes supportées par services SSO (POST, SOAP, Redirect...)

La sécurité dans Liberty Alliance Couche transport (https) Couche message (certificats signés, validation de la source) Couche application (Assertion, pas d'identification unique en circulation)

Les différents frameworks ID-FF, protocole de base ID-WSF, partage d'attributs SAML 2.0

ID-FF : plateforme de fédération d'identité Single Sign On / Single Logout Fédération / Déféderation Name registration Identity Provider Introduction

ID-WSF : plateforme de partage d'attributs Partage d'informations (attributs) concernant l'utilisateur Discovery Service DST (Data Service Template) Interaction Service

SAML 2.0 Norme OASIS Convergence Shibboleth et Liberty Alliance ID-WSF 2.0 s'appuiera sur SAML 2.0 Standrd générique

Obstacles à Liberty Pas de solutions libres Implémentation de référence par Sun mais uniquement 1.0 SourceID, accès au source mais liberté «variable» Solutions existantes Intégration difficile, très peu de flexibilité

Lasso

Développement de Lasso Prototype en Python (juillet 2003) Réimplémentation en C (février 2004)

Caractéristiques fonctionnelles Bibliothèque Pas de couche stockage Pas d'obligation de base de données, de schéma de tables particuliers, etc. Pas de couche transport Algorithmes spécifiés par Liberty Utilisation de celles de l'applicatif Pas de couche authentification Du ressort de l'applicatif

Caractéristiques techniques Bibliothèque écrite en C Rapide Compatible avec un maximum de langages Utilisation de SWIG pour ces bindings Java, Perl, PHP, Python... Seulement quelques jours pour porter vers un nouveau langage Multi-plateforme Testée sous GNU/Linux, FreeBSD, Mac OS X et Microsoft Windows

Bibliothèques S'appuie sur des bibliothèques courantes, écrites en C et libres : GLib et Gobject: portabilité, listes, dictionnaires, structures objet en C libxml2: traitement XML http://www.xmlsoft.org XMLSec: XML Signature, XML Encryption http://www.gtk.org http://www.aleksey.com/xmlsec/ OpenSSL: crypto http://www.openssl.org

Interopérabilité Certifiée par le consortium LA en mai 2005 Conformance permettant de tester réellement l'interopérabilité

Licence Licence GNU GPL Copyright exclusif Entr'ouvert Donc: Utilisation possible dans les applications ayant une licence compatible avec la GPL Utilisation possible dès lors que l'application n'est pas distribuée Autre cas? licence payante, nous consulter

Performances (1) 93% du temps passé dans OpenSSL Énormes gains possibles avec processeurs dédiés mais un petit Opteron (1,6GHz) assure déjà 170 requêtes/secondes

Performances (2)

Contrôle qualité http://lasso.entrouvert.org/buildbox

Développement Public Liste : lasso-devel@lists.labs.libre-entreprise.org Bug tracking : http://labs.libre-entreprise.org/projects/lasso

IdP basé sur Lasso : Authentic Compatibilité Liberty Alliance : support des protocoles ID-FF 1.2, ID-WSF et SAML 2.0 (en cours). Support de bases d'utilisateurs variées : LDAP V3 (Active Directory), Postgresql, MySQL. Proxy Partage d'attributs Génération et échange de metadata Performant Interface graphique soignée

Authentic http://authentic.labs.libre-entreprise.org

Fournisseur d'attributs : Candle Partage d'attributs ID-WSF 1.0 Édition de ses informations personnelles Activation et désactivation du partage Application de test http://deb.entrouvert.org

Fournisseur de service : Unwind Récupère les attributs depuis Candle et les affiche Demande le consentement de l'utilisateur pour certaines données. Application de test rudimentaire http://deb.entrouvert.org

Larpe Liberty Alliance Reverse-Proxy Entr'ouvert Permet l'intégration en quelques heures d'un fournisseur de service sans avoir à modifier le site libertysé Intégration plus rapide mais plus superficielle Version 0.1 http://larpe.labs.libre-entreprise.org/

Applications Adeline, pour une interconnexion sans couture des services d'e-administration locaux et nationaux Services de vie quotidienne, bouquet de services à destinations des communes et des collectivités locales (formulaires, consultations, télépaiement)

Futur Compatibilité SAML 2.0 et ID-WSF 2.0 Développement d'authentic Intégration dans un maximum d'applications libres SPIP, WordPress, webcalendar, mailman, sympa, etc. Compatibilité Shibboleth (universités), WS-*?

Configuration, compilation et installation

Récupération des sources Sources http://labs.libre-entreprise.org/projects/lasso/ CVS http://labs.libre-entreprise.org/plugins/ scmcvs/cvsweb.php/lasso/?cvsroot=lasso

Dépendances GLib, diverses structures de données, libxml2, XML et XPath, http://www.openssl.org xmlsec, xml-dsig, signature numérique W3C, http://www.xmlsoft.org OpenSSL, (dé-)chiffrement, http://www.gtk.org http://www.aleksey.com/xmlsec/ swig, interfaçage vers autres langages, http://www.swig.org

Configuration./configure Bindings activés automatiquement mais : Java : --disable-java Python : --disable-python PHP : --disable-php Perl : --disable-perl ID-WSF : --enable-wsf

Compilation, installation make make install

Version CVS dépendances supplémentaires automake (1.8) autoconf libtool export CVSROOT=:pserver:anonymous@cvs. labs.libre-entreprise.org:/cvsroot/lasso cvs login cvs checkout lasso

Patchs Un fichier : patch fichier-source < fichier.diff Une arborescence : patch -p1 -s -N -E -d lasso < fichier.diff

Tests Tests unitaires Tests en C disponibles dans toutes les versions Tests Java disponibles dans la version CVS Dépendance sur le package JUnit Application de test : souk utilisée pour l'événement «conformance» Liberty ID-FF 1.2 http://lasso.entrouvert.org/souk/

Documentation et interface Java java/ Documentation sur l'api C dans les sources : docs/reference/html/index.html http://lasso.entrouvert.org/documentation/apireference/ Convention de nommage sur les attributs C: ProviderID, NameIdentifier Java, Python, etc: providerid, nameidentifier swig/lasso.i Prérequis : connaissance de Swig

Applications Liberty/Lasso existantes Souk Fournisseurs d'identités : Authentic http://authentic.labs.libre-entreprise.org Fournisseurs de services : propres : wcs, candle, unwind, etc. adaptés : egroupware, dotclear, spip, etc.

Configuration serveur Liberty Configuration Web : SSL SSLCertificateFile certificate.pem SSLCertificateKeyFile private-key.pem SSLCACertificateFile ca-certificates-chain.pem Configuration Liberty metadata Fichier XML clés publiques, clés privées, certificats

Metadata Schéma disponible dans les spécifications liberty-metadata-v1.0.xsd Description du serveur Description fournisseur de service <SPDescriptor/> Description fournisseur d'identités <IDPDescriptor/> Description de l'organisme

Développement Lasso

Nomenclature (1/5) Base en C : server = lasso_server_new( "sp-metadata.xml", "privatekey.pem", NULL, NULL); lasso_server_add_provider( server, LASSO_PROVIDER_ROLE_IDP, "idp-metadata.xml", "publickey.pem", NULL);

Nomenclature (2/5) Java : import com.entrouvert.lasso.*; server = new Server( "sp-metadata.xml", "privatekey.pem", null, null); server.addprovider( lasso.provider_role_idp, "idp-metadata.xml", "publickey.pem", null);

Nomenclature (3/5) Python : import lasso server = lasso.server( "sp-metadata.xml", "privatekey.pem", None, None); server.addprovider( lasso.provider_role_idp, "idp-metadata.xml", "publickey.pem", None);

Nomenclature (4/5) PHP : lasso_init(); $server = new LassoServer( "sp-metadata.xml", "privatekey.pem", NULL, NULL); $server->addprovider( LASSO_PROVIDER_ROLE_IDP, "idp-metadata.xml", "publickey.pem", NULL);

Nomenclature (5/5) Perl : use lasso; $server = lasso::server->new( "sp-metadata.xml", "privatekey.pem", undef, undef); $server->addprovider( $lasso::provider_role_idp, "idp-metadata.xml", "publickey.pem", undef);

Objets de base (1/6) Provider, un fournisseur Liberty (SP comme IdP) Server, le fournisseur développé Attributs : providerid metadata_filename Server : providers addprovider(...)

Objets de base (2/6) Profile, les différents profils Liberty Login, pour le SSO Logout, pour la déconnexion Defederation, pour la terminaison de fédération NameRegistration, pour le changement de Name Identifier NameIdentifierMapping, pour la correspondance entre Name Identifiers Lecp, pour les clients Liberty

Objets de base (3/6) Attributs communs : msgurl, msgbody, msgrelaystate session, issessiondirty identity, isidentitydirty request response nameidentifier

Objets de base (4/6) Identity is_dirty providerids[]

Objets de base (5/6) Session is_dirty providerids[] assertions[]

Objets de base (6/6) Objets de bas niveau requêtes et réponses SAML et Liberty Généralement accédés via profile.getrequest() Exemple : LibAuthnRequest authnrequest; authnrequest = (LibAuthnRequest)login.getRequest(); authnrequest.setprotocolprofile(protocolprofile);

Sérialisation Au format XML Objets Server profils : Login, Logout, Defederation, etc. Identity Session dump et newfromdump server.dump() & Server.newFromDump("...") Enregistrement en base de données du ressort de l'application

Créer un objet Server java/server.java server = new Server("metadata.xml", "sign-private-key.pem", "private-key-password", null); String dump = server.dump(); server = lasso.server.newfromdump(dump);

Sérialisation serveur lasso server dump : <lasso:server xmlns:lasso="..." ProviderID="https://idp/metadata" ProviderDumpVersion="2" ServerDumpVersion="2" SignatureMethod="RSA_SHA1"> <lasso:metadatafilepath>metadata.xml</lasso:metad atafilepath> <lasso:privatekeyfilepath>sp-sign-privatekey.pem</lasso:privatekeyfilepath> <lasso:certificatefilepath>sp-signcertificate.pem</lasso:certificatefilepath> </lasso:server>

Ajouter des fournisseurs server.addprovider(lasso.provider_role_idp, "idp-metadata.xml", "sign-public-key.pem", null); server.addprovider(lasso.provider_role_sp, "sp-metadata.xml", "sign-public-key.pem", null);

ID-FF Identity Federation Framework

Web SSO

Requête : AuthnRequest NameIDPolicy ForceAuthn IsPassive consent RelayState Extension <lib:authnrequest xmlns:lib="urn:liberty:id-ff:2003-08" RequestID="RPCUk2ll+GVz+t1lLURp51oFvJXk" MajorVersion="1" MinorVersion="2" consent="urn:liberty:consent:obtained" IssueInstant="2005-12-17T21:42:4Z"> <ds:signature>... </ds:signature> <lib:providerid>http://service.com</lib:providerid> <lib:nameidpolicy>federated</lib:nameidpolicy> <lib:forceauthn>false</lib:forceauthn> <lib:ispassive>false</lib:ispassive> <lib:protocolprofile> http://.../brws-post </lib:protocolprofile> <lib:requestauthncontext> <lib:authncontextclassref> http://.../password-protectedtransport </lib:authncontextclassref> <lib:authncontextcomparison>exact </lib:authncontextcomparison> </lib:requestauthncontext> <lib:relaystate>r0lgofqxds8b</lib:relaystate> </lib:authnrequest>

NameIDPolicy Les règles sur l'identifiant de fédération Liberty «One-time» Une assertion d'authentification pour la durée de la session utilisateur «Federated» Une assertion d'authentification pour la durée de la session utilisateur et un identifiant de fédération. Nécessite le consentement de l'utilisateur attestant bien qu'il a été informé de la fédération à établir et qu'il a accepté.

ForceAuthn Authentification forcée Le fournisseur de service demande à forcer la réauthentification de l'utilisateur Interaction utilisateur si nécessaire Exemple : niveau d'authentification plus élevé

IsPassive Mode d'authentification passif Demande l'authentification utilisateur sans interaction avec l'idp Récupère une assertion

AuthnContext Contexte d'authentification Le fournisseur de service impose des règles a propos de la méthode d'authentification à utiliser

Réponse : AuthnResponse Status Assertion SAML en autorise plusieurs mais Liberty n'en utilise jamais qu'une RelayState Extension

Bindings possibles POST Artifact GET POST

Cas du SSO initié par l'idp pas de AuthnRequest envoyé par un SP structure néanmoins présente pour le paramétrage généralement pas d'authentification à demander à l'utilisateur vu qu'il doit être identifié pour que l'option lui soit proposée pareil pour le consentement donc pas de login.dump()

Sérialisations nécessaires sur l'idp Identité et session à restaurer au début de la procédure à stocker en cas de fédération après l'appel à buildartifactmsg ou après l'appelà buildauthnresponsemsg Artifact stocké après l'appel à buildartifactmsg

Contenu des tables Identités : informations diverses dump identity lasso Sessions : dump session lasso éventuellement, liste de name identifiers Artifacts : valeur de l'artifact pointeur vers la session ProviderID

Sérialisations nécessaires sur le SP Identité : à stocker ou restaurer après acceptsso() indexée sur le nameidentifier Session : à stocker après l'acceptsso à restaurer dans les autres profils

Contenu des tables Identités : dump identity lasso éventuellement liste de name identifiers Sessions : dump session lasso éventuellement liste de name identifiers

Implémentation (1/4) Le fournisseur de service initie le SSO : Login login = new Login(spServer); login.initauthnrequest(remoteproviderid, httpmethod); LibAuthnRequest authnrequest; authnrequest = (LibAuthnRequest)login.getRequest(); authnrequest.setprotocolprofile(protocolprofile); authnrequest.setnameidpolicy(nameidpolicy); authnrequest.setconsent(consent); login.buildauthnrequestmsg();

Implémentation (2/4) Le fournisseur d'identités traite la requête SSO : Login login = new Login(idpServer); login.processauthnrequestmsg(message); login.mustauthenticate(isalreadyathenticated); login.setsession(idpsession); login.setidentity(idpidentity); login.validaterequestmsg(isauthenticated, consentobtained); login.buildartifactmsg(httpmethod);

Implémentation (3/4) Le fournisseur de service demande l'assertion par SOAP : login = new Login(spServer); login.initrequest(artifact); login.buildrequestmsg(); // Envoi et réception de la requête SOAP soapresponsemsg =...; login.processresponsemsg(soapresponsemessage);

Implémentation (4/4) Le fournisseur d'identités traite la demande SOAP : lasso.getrequesttypefromsoapmsg(soaprequestmsg); // == lasso.request_type_login login = new Login(idpLassoServer); login.processrequestmsg(soaprequestmsg); login.setsession(idpsession); login.buildresponsemsg(idpremoteproviderid);

POST

SSO par POST Assertion retournée dans la réponse Liberty Réponse envoyée dans un formulaire AuthnResponse encodée en base64 <html> <body onload="document.forms[0].submit()"> <form action="https://...>" method="post"> <input type="hidden" name="lares" value="xxx..." > </form> </body> </html>

Déconnexion Liberty (SLO)

Requête : LogoutRequest ProviderID NameIdentifier SessionIndex RelayState consent NotOnOrAfter

Réponse : LogoutResponse Extension ProviderID Status RelayState

Bindings possibles HTTP-Redirect HTTP-GET Dangereux, facile à perdre uniquement côté IdP SOAP

Sérialisations nécessaires Identité : à restaurer au début de la procédure Session : à restaurer au début de la procédure à supprimer : SOAP : avant les appels aux SP Redirect : dans le SingleLogoutReturn

Implémentation (1/6) SLO initié depuis un fournisseur de service : Logout logout = new Logout(server); logout.setidentity(spidentity); logout.setsession(spsession); logout.initrequest(remoteproviderid, httpmethod); logout.builtrequestmsg();

Implémentation (2/6) Le fournisseur d'identités traite la requête : Logout idplogout = new Logout(idpLassoServer); idplogout.processrequestmsg(message); String nameidentifier = idplogout.getnameidentifier().getcontent(); idplogout.setidentity(idpidentity); idplogout.setsession(idpsession); String remoteproviderid = idplogout.getnextproviderid(); idplogout.validaterequest(); idplogout.buildresponsemsg();

Implémentation (3/6) Le fournisseur de service traite la réponse : logout.processresponsemsg(message);

Implémentation (4/6) SLO initié depuis un fournisseur d'identités : Logout logout = new Logout(idpLassoServer); logout.setidentity(idpidentity); logout.setsession(idpsession); String nextproviderid = idplogout.getnextproviderid(); logout.initrequest(nextproviderid, httpmethod); logout.buildrequestmsg();

Implémentation (5/6) Le fournisseur de service traite la requête : Logout logout = new Logout(idpServer); logout.processrequestmsg(requestmessage); String nameidentifier = logout.getnameidentifier().getcontent(); logout.setidentity(spidentity); logout.setsession(spsession); logout.validaterequest(); spidentity = logout.getidentity(); spsession = logout.getsession(); logout.buildresponsemsg();

Implémentation (6/6) Le fournisseur d'identités traite la réponse : logout = new Logout(idpServer); logout.processresponsemsg(responsemessage);

Terminaison de fédération Liberty (FedTerm)

Notification : Federation TerminationNotification ProviderID NameIdentifier consent RelayState Extension

Bindings possibles HTTP-Redirect SOAP Juste une notification Code HTTP de retour : 204, pas 200

Sérialisations nécessaires Identité et session à restaurer au début de la procédure à stocker après l'appel à validatenotification Attention, l'identité peut être nulle

Implémentation (1/4) FedTerm initié depuis un fournisseur de service : Defederation fedterm = new Defederation(server); fedterm.setidentityfromdump(identitydump); fedterm.initnotification(remoteproviderid, httpmethod); fedterm.buildnotificationmsg();

Implémentation (2/4) Le fournisseur d'identités traite la requête : Defederation fedterm = new Defederation(server); fedterm.setidentityfromdump(identitydump); fedterm.processnotificationmsg(requestmessage);

Implémentation (3/4) FedTerm initié depuis un fournisseur d'identités : Defederation idpfedterm = new Defederation(idpServer); idpfedterm.setidentity(idpidentity); idpfedterm.initnotification(remoteproviderid, httpmethod); idpfedterm.buildnotificationmsg();

Implémentation (4/4) Le fournisseur de service traite la requête : Defederation spfedterm = new Defederation(spServer); spfedterm.setidentity(spidentity); spfedterm.processnotificationmsg(requestmessage);

Changement d'identifiant de fédération NameRegistration

Requête : Register NameIdentifierRequest ProviderID IDPProvidedNameIdentifier SPProvidedNameIdentifier OldProvidedNameIdentifier RelayState Extension

Réponse : Register NameIdentifierResponse Extension ProviderID Status RelayState

Bindings possibles HTTP-Redirect SOAP

Sérialisations nécessaires Identité à restaurer au début de la procédure à sauvegarder sur l'initiateur : après validaterequest() sur le receveur : après processresposemsg() La session n'est pas touchée car les name identifiers dans les assertions sont laissés tels quels.

Implémentation (1/6) RNI initié depuis un fournisseur de service : NameRegistration sprni = new NameRegistration(spLassoServer); sprni.setidentity(spidentity); sprni.initrequest(remoteproviderid, httpmethod); sprni.buildrequestmsg();

Implémentation (2/6) Le fournisseur d'identité traite la requête : NameRegistration idprni = new NameRegistration(idpLassoServer); idprni.processrequestmsg(message); String nameidentifier = idprni.getnameidentifier().getcontent(); String oldnameidentifier = idprni.getoldnameidentifier().getcontent(); idprni.setidentity(idpidentity); idprni.validaterequest(); idprni.buildresponsemsg();

Implémentation (3/6) Le fournisseur de service traite la réponse : sprni.processresponsemsg(message);

Implémentation (4/6) RNI initié depuis un fournisseur d'identité : NameRegistration idprni = new NameRegistration(idpLassoServer); idprni.setidentity(idpidentity); idprni.initrequest(remoteproviderid, httpmethod); idprni.buildrequestmsg();

Implémentation (5/6) Le fournisseur de service traite la requête : NameRegistration sprni = new NameRegistration(spServer); sprni.processrequestmsg(message); String nameidentifier = sprni.getnameidentifier().getcontent(); String oldnameidentifier = sprni.getoldnameidentifier().getcontent(); sprni.setidentity(spidentity); sprni.validaterequest(); sprni.buildresponsemsg();

Implémentation (6/6) Le fournisseur d'identités traite la réponse : idprni.processresponsemsg(message);

Identity Provider Introduction spécification pour un cas particulier IdP et SP ans un sous-domain commun cookie _liberty_idp positionné par l'idp obtenu par le SP

Name Identifier Mapping Profil Liberty optionnel

Requête : NameIdentifier MappingRequest ProviderID NameIdentifier TargetNamespace consent Extension

Réponse : NameIdentifier MappingResponse ProviderID Status NameIdentifier Extension

Binding possible SOAP

ID-WSF Identity Web Services Framework

Support dans Lasso API/ABI non considérées stables mais inchangées depuis longtemps pas compilé par défaut --enable-wsf

Différents services Discovery Service Data Service (Template) Personal Profile Employee Profile + (contexte mobile) Authentication Service Interaction Service

Différents services

Discovery Service Permet d'annoncer les services L'adresse du discovery service est mentionnée dans l'assertion Les serveurs proposant des services s'y annoncent

Sérialisations nécesaires Identité : un resource_id idéalement pas l'identifiant local un entry_id

Implémentation (1/4) Création d'un objet DiscoServiceInstance instance = lasso.discoserviceinstance( lasso.pp_href, providerid, lasso.discodescription_... newwithbriefsoaphttpdescription( lasso.security_mech_null, soapendpoint))

Implémentation (2/4) Création d'un objet DiscoResourceOffering resource_offering = lasso.discoresourceoffering(instance) resource_offering.resourceid = \ lasso.discoresourceid(user_resource_id) resource_offering.abstract = "Personal details about the user"

Implémentation (3/4) Annoncer la disponibilité à l'idp disco = lasso.discovery(server) disco.initinsert(resource_offering) disco.buildrequestmsg() // envoi SOAP disco.processmodifyresponsemsg(response) user.entry_id = disco.response.newentryids

Implémentation (4/4) Supprimer une annonce disco = lasso.discovery(server) disco.setidentityfromdump(...) disco.setsessionfromdump(...) disco.initremove(user.entry_id) disco.buildrequestmsg() // envoi SOAP disco.processmodifyresponsemsg(response)

Data Service Définition d'un squelette pour le partage d'attributs Implémenté dans deux services spécifiés : ID-SIS PP ID-SIS EP principalement la définition d'un schéma de donnée

Personal Profile Noms, prénoms, adresses, informations de contact, etc. /pp:pp/pp:informalname /pp:pp/pp:addresscard/pp:address/pp:postalc ode...

Employee Profile Informations relatives à la place de l'employé dans l'entreprise (+ diverses infos sur l'enterprise même) /ep:ep/ep:employeeid /ep:ep/ep:manageremployeeid /ep:ep/ep:corplegalentity/ep:vat/ep:idvalue

Implémentation (1/3) Recherche du service disco = lasso.discovery(server) disco.setsessionfromdump(...) disco.initquery(none) disco.addrequestedservicetype(lasso.pp_href, None) disco.buildrequestmsg() # soap call disco.processresponsemsg(response) service = disco.getservice()

Implémentation (2/3) Demande de l'information service.initquery('/pp:pp/pp:informalname', 'name', None) # des service.addqueryitem(...) service.buildrequestmsg() # soap call service.processqueryresponsemsg(response) #!! lasso.soap_fault_redirect_response name = service.getanswer('/pp:pp/pp:informalname') # -> name: <InformalName>...</InformalName>

Implémentation (3/3) Cas du redirect redirect_url = service.getredirectrequesturl() return_url = 'XXX' redirect( redirect_url + '?ReturnURL=' % ( urllib.quote(return_url)))

Implémentation (1/1) Traitement côté fournisseur d'attributs service = lasso.dataservice(server) service.processrequestmsg(message) # récup identité sur base de service.resourceid service.resourcedata =... service.buildresponsemsg()