Formation : Liberty Alliance pour FederIDfederid.ow2.org/xwiki/bin/download/Main/DocFormations/formation... · Compatible SAML 2.0 ... Ping Identity J2EE Licence ? Ping Federate,

Liberty Alliance pour FederID

Pierre Cros<[email protected]>

Formateurs

● Pierre Cros– [email protected]

● Frédéric Péters– [email protected]

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, WS-MetadataExchange (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– Algorithmes spécifiés par Liberty

● Pas de couche stockage– Pas d'obligation de base de données, de

schéma de tables particuliers, etc.● Pas de couche transport

– 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● Java, Perl, PHP, Python...

● Utilisation de SWIG pour ces bindings– 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● http://www.gtk.org

– libxml2: traitement XML● http://www.xmlsoft.org

– XMLSec: XML Signature, XML Encryption● 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 :

– [email protected]● 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,– http://www.gtk.org

● libxml2, XML et XPath,– http://www.xmlsoft.org

● OpenSSL, (dé-)chiffrement,– http://www.openssl.org

● xmlsec, xml-dsig, signature numérique W3C,– 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/lassocvs logincvs 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/

Documentationet interface Java

● java/● Documentation sur l'API C dans les sources :

– docs/reference/html/index.html

– http://lasso.entrouvert.org/documentation/api-reference/

● 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(...)


● 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


● Attributs communs :– msgUrl, msgBody, msgRelayState

– session, isSessionDirty

– identity, isIdentityDirty

– request

– response

– nameIdentifier


● Identity– is_dirty

– providerIds[]


● Session– is_dirty

– providerIds[]

– assertions[]


● 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:MetadataFilePath> <lasso:PrivateKeyFilePath>sp-sign-private-key.pem</lasso:PrivateKeyFilePath> <lasso:CertificateFilePath>sp-sign-certificate.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();


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


● 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 SOAPsoapResponseMsg = ...;login.processResponseMsg(soapResponseMessage);


● 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– AuthnResponse

● Réponse envoyée dans un formulaire– 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– Dangereux, facile à perdre

● HTTP-GET– 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


● SLO initié depuis un fournisseur de service :

Logout logout = new Logout(server);logout.setIdentity(spIdentity);logout.setSession(spSession);logout.initRequest(remoteProviderId, httpMethod);logout.builtRequestMsg();


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


● Le fournisseur de service traite la réponse :

logout.processResponseMsg(message);


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


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


● 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


● Identité et session– à restaurer au début de la procédure

– à stocker après l'appel à validateNotification● Attention, l'identité peut être nulle


● FedTerm initié depuis un fournisseur de service :

Defederation fedTerm = new Defederation(server);fedTerm.setIdentityFromDump(identityDump);fedTerm.initNotification(remoteProviderId,

httpMethod);fedTerm.buildNotificationMsg();


● Le fournisseur d'identités traite la requête :

Defederation fedTerm = new Defederation(server);fedTerm.setIdentityFromDump(identityDump);fedTerm.processNotificationMsg(requestMessage);


● FedTerm initié depuis un fournisseur d'identités :

Defederation idpFedTerm =new Defederation(idpServer);

idpFedTerm.setIdentity(idpIdentity);idpFedTerm.initNotification(remoteProviderId,

httpMethod);idpFedTerm.buildNotificationMsg();



Defederation spFedTerm =new Defederation(spServer);

spFedTerm.setIdentity(spIdentity);spFedTerm.processNotificationMsg(requestMessage);

Changement d'identifiant de fédération

● NameRegistration

Requête : RegisterNameIdentifierRequest

● ProviderID● IDPProvidedNameIdentifier● SPProvidedNameIdentifier● OldProvidedNameIdentifier● RelayState● Extension

Réponse : RegisterNameIdentifierResponse

● Extension● ProviderID● Status● RelayState

Bindings possibles

● HTTP-Redirect● SOAP


● 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.


● RNI initié depuis un fournisseur de service :

NameRegistration spRni =new NameRegistration(spLassoServer);

spRni.setIdentity(spIdentity);spRni.initRequest(remoteProviderId, httpMethod);spRni.buildRequestMsg();


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


● Le fournisseur de service traite la réponse :

spRni.processResponseMsg(message);


● RNI initié depuis un fournisseur d'identité :

NameRegistration idpRni =new NameRegistration(idpLassoServer);

idpRni.setIdentity(idpIdentity);idpRni.initRequest(remoteProviderId, httpMethod);idpRni.buildRequestMsg();



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


● 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 : NameIdentifierMappingRequest

● ProviderID● NameIdentifier● TargetNamespace● consent● Extension

Réponse : NameIdentifierMappingResponse

● 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


● Création d'un objet DiscoServiceInstance

instance = lasso.DiscoServiceInstance(lasso.PP_HREF,providerId,lasso.DiscoDescription_... newWithBriefSoapHttpDescription(

lasso.SECURITY_MECH_NULL,soapEndPoint))


● 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"


● Annoncer la disponibilité à l'IdP

disco = lasso.Discovery(server)disco.initInsert(resource_offering)disco.buildRequestMsg()// envoi SOAPdisco.processModifyResponseMsg(response)user.entry_id = disco.response.newEntryIds


● Supprimer une annonce

disco = lasso.Discovery(server)disco.setIdentityFromDump(...)disco.setSessionFromDump(...)disco.initRemove(user.entry_id)disco.buildRequestMsg()// envoi SOAPdisco.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:PostalCode

– ...

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


● Recherche du service

disco = lasso.Discovery(server)disco.setSessionFromDump(...)disco.initQuery(None)disco.addRequestedServiceType(lasso.PP_HREF, None)disco.buildRequestMsg()# soap calldisco.processResponseMsg(response)service = disco.getService()


● Demande de l'information

service.initQuery('/pp:PP/pp:InformalName', 'name', None)# des service.addQueryItem(...)service.buildRequestMsg()# soap callservice.processQueryResponseMsg(response)# !! lasso.SOAP_FAULT_REDIRECT_RESPONSEname = service.getAnswer('/pp:PP/pp:InformalName')# -> name: <InformalName>...</InformalName>


● Cas du redirect

redirect_url = service.getRedirectRequestUrl()return_url = 'XXX'

redirect(redirect_url + '?ReturnURL=' % (

urllib.quote(return_url)))


● Traitement côté fournisseur d'attributs

service = lasso.DataService(server)service.processRequestMsg(message)# récup identité sur base de service.resourceIdservice.resourceData = ...service.buildResponseMsg()

Documents

Formation : Liberty Alliance pour FederIDfederid.ow2.org/xwiki/bin/download/Main/DocFormations/formation... · Compatible SAML 2.0 ... Ping Identity J2EE Licence ? Ping Federate,