AD FS 2.0, une plateforme ouverte et interopérable pour l’authentification unique Web et la fédération des identités

Version 1.03

Publication : octobre 2009

Auteur : Philippe Beraud (Microsoft France)

Contributeur : Pierre Couzy (Microsoft France)

Copyright

© 2009 Microsoft Corporation. Tous droits réservés.

Résumé

Ce livre banc introduit une nouvelle approche en termes d’authentification et de contrôle d’accès visant à faciliter les décisions de contrôle d’accès entre applications, services et système indépendamment de l’emplacement au sein du SI, des espaces de confiance au-delà du SI, de l’architecture, de l’environnement technique, de la technologie, etc. de façon à rendre possible la simplification de la gestion des identités et des accès et une collaboration sécurisée au sein d’une entreprise désormais étendue.

Ce document illustre comment les technologies de la plateforme “Geneva”, en particulier AD FS 2.0 mais également WIF et Windows CardSpace 2.0, font de cette approche une réalité opérationnelle pour l’authentification unique Web (Web Single Sign-on en anglais ou Web SSO en abrégé) et la fédération des identités dans des environnements hétérogènes.

La fédération des identités est non seulement envisagée sous l’angle « Front-Channel », en l’occurrence le Web SSO fédéré à destination des portails et sites Web, mais également sous l’angle « Back-Channel » dans un contexte de services Web.

© 2009 Microsoft Corporation. Tous droits réservés.

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les sujets traités à la date de publication. Etant donné que Microsoft doit

s’adapter aux conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de Microsoft, et Microsoft n’est pas en mesure de

garantir l’exactitude de toute information présentée après la date de publication.

MICROSOFT NE DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE

DOCUMENT.

Les autres noms de produits ou de sociétés cités dans ce document peuvent être des marques

de leurs propriétaires respectifs.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • Etats-Unis

1 En guise d’introduction

La complexité de mise en œuvre et de gestion de l’authentification et du contrôle d’accès aux applications et aux autres ressources d’une organisation rend difficile la tâche des développeurs et des professionnels de l’informatique pour satisfaire aux besoins de leur organisation.

La plupart des applications, quels que soient la plateforme logicielle et l’environnement technique, s’appuient sur des identités. Une identité numérique est, d’une façon générale, un ensemble d’informations à propos d’une entité, telle qu’un utilisateur. Les informations d’identité influencent le comportement des applications - elles déterminent ce qu’un utilisateur est autorisé à faire, contrôlent la façon dont l’application interagit avec l’utilisateur, par exemple.

La notion d'identité est essentielle, mais travailler avec les identités est devenu difficile : en fonction de la situation et du contexte d’accès à mettre à disposition, de très nombreux choix de technologies (et de standards) en matière d’identité sont possibles, avec à la clé de multiples représentations (et protocoles), ainsi qu’une diversité de modèles de programmation fonction des éléments précédents et/ou des environnements techniques.

Cette multiplicité de technologies d’identité, de protocoles et de formats de jetons de sécurité induit une complexité et un coût d’implémentation notable dans un contexte donné, sans pour autant parvenir à satisfaire l’ensemble des scénarios d’accès souhaités avec les exigences associées en termes de sécurité.

Il n’est donc pas rare de voir une solution tactique bloquer une interopérabilité future : les applications deviennent dépendantes d’une technologie…ET bornées par les contraintes de la technologie choisie.

S’ajoute à cela la difficulté à interopérer avec des applications et des systèmes hétérogènes et à adapter ces mêmes applications à de nouveaux scénarios émergents comme les services hébergés, etc. ; la tendance des architectures orientées service (Service Oriented Architecture en anglais ou SOA en abrégé) amplifiant les défis ainsi posés.

Dès lors, face à un tel constat en termes de difficulté d’interconnexion au travers des frontières des applications, des technologies, et des organisations, et de façon à simplifier :

la gestion des identités et des accès et une collaboration sécurisée au sein d’une entreprise désormais étendue,

et la vie des développeurs d’applications et des RSSI,

une nouvelle approche s’impose !

« Stop hard-coding security into applications and stop creating operating system (OS)-level accounts on servers. Consume these as services external to the application. »

Neil MacDonald 13 April 2006

Gartner Group: Achieving agility: building blocks for a policy-

driven, agile security services infrastructure

Fondée sur les services d'annuaire Active Directory et destinée aussi bien aux développeurs qu'aux professionnels de l’information, la plateforme Microsoft “Geneva” propose une nouvelle approche de l’identité et de l’authentification unique (Single Sign-On en anglais ou SSO en abrégé) qui aide à simplifier l’accès aux applications, aux services Web, et à d’autres systèmes :

Au sein de l’entreprise,

entre organisations,

sur le Web et dans les nuages comme la plateforme Windows Azure (http://www.windowsazure.com/).

Cette approche vise à :

1. Définir l’identité numérique comme un ensemble de revendications (claims en anglais) qui caractérise un utilisateur (ou entité) dans le monde numérique ;

2. Externaliser de l’application l’authentification (voire également le contrôle d’accès).

Schématiquement, un fournisseur d’identités (Identity Provider en anglais ou IP en abrégé) - typiquement l’employeur pour une entreprise donnée - constitue une autorité qui fait des revendications au sujet d’une entité. Ces revendications sont physiquement transportées dans ce que nous allons appeler des jetons (d’authentification et/ou d’autorisations).

Pour cela, le fournisseur d’identités implémente un service de distribution de jetons (Security Token Service en anglais ou STS en abrégé) qui émet les jetons. Les demandes (authentifiées) de jetons sont effectuées à l’aide de protocoles standards.

Les jetons sont utilisés par des applications, sites Web ou services Web (relying party en anglais ou RP en abrégé) qui font confiance au STS.

Aujourd’hui, une application récupère typiquement une seule information d’identité simple telle qu’un nom d’utilisateur. Pour avoir davantage d’informations, l’application doit interroger un référentiel distant tel qu’un service d’annuaire et/ou une base de données locale.

Avec une identité fondée sur des revendications, chaque application peut demander exactement les revendications dont elle a besoin ; un STS les place dans le jeton qu’il crée. Dans la pratique, une revendication peut :

Identifier un utilisateur,

Véhiculer l’appartenance à un groupe ou à un rôle,

Transporter des informations de personnalisation comme le nom à afficher pour un utilisateur,

Donner ou dénier le droit de faire quelque chose comme l’accès à une information particulière ou l’invocation de méthodes spécifiques,

Limiter le droit de faire quelque chose comme un montant de délégation,

Etc.

L’objectif de la plateforme “Geneva” est de rendre concrète la notion d’identité fondée sur des revendications et de proposer pour cela des technologies ouvertes et interopérables.

Cette plateforme d’authentification ouverte primée dans la catégorie « Meilleure innovation » à l’occasion de la conférence EIC (European Identity Conference) 2009 est constituée des trois technologies suivantes disponibles aujourd’hui en Bêta 2 et en version finale d’ici à la fin de l’année 2009.

Il s’agit de composants de la plateforme Windows (Server) et, à ce titre, leur droit d’utilisation est inclus dans le coût des licences associées.

Ces technologies sont les suivantes :

1. Active Directory Federation Services (AD FS en abrégé) 2.0, anciennement connu sous

le nom de code “Geneva” Server - AD FS 2.0 constitue un STS à destination des services d’annuaires Active Directory, en l’occurrence Active Directory Domain Services (AD DS en abrégé) ou Active Directory Lightweight Directory Services (AD LDS en abrégé), et d’autres référentiels.

AD FS offre aux utilisateurs finaux une expérience d’authentification unique (Web mais pas uniquement) entre applications, plateformes et organisations et simplifie dans ce contexte la gestion des identités aux professionnels de l’information en réduisant les comptes en double ;

2. Windows Identity Foundation (WIF en abrégé), anciennement connu sous le nom de

code “Geneva” Framework - WIF constitue un ensemble d'API à destination des

développeurs ASP.NET et Windows Communication Foundation (WCF en abrégé) pour la conception d’applications à même de consommer directement des revendications (dites claims aware en anglais) et à même d’établir un cadre de confiance dans un contexte de fédération.

Il constitue également, dans le cadre de cette nouvelle approche, un socle d’accueil pour des applications existantes nécessitant un contexte de sécurité donné comme Kerberos. Pour cela, WIF permet d’utiliser les revendications obtenues pour constituer un tel contexte et le transmettre à l’application considérée.

WIF constitue également une fondation pour l’écriture de STS personnalisés.

3. Windows CardSpace 2.0, anciennement connu sous le nom de code Windows

CardSpace “Geneva” - CardSpace permet aux utilisateurs finaux d'avoir un meilleur contrôle de leur(s) identité(s) et permet aux administrateurs de décliner et de rationaliser les accès aux applications et services dans un contexte d’authentification un ique.

Les différentes ressources relatives à la plateforme “Geneva” sont accessibles depuis l’adresse http://www.microsoft.com/geneva. Nous conseillons la lecture du livre blanc "GENEVA" CLAIMS

BASED ACCESS PLATFORM1 qui permet de disposer d’une bonne compréhension des principaux

concepts qui sous-tendent cette plateforme au-delà de ce qui précède.

Les technologies “Geneva” font partie des technologies plateforme des solutions Forefront d’identité et de sécurité2 de Microsoft au cœur de la stratégie Business Ready Security3 de Microsoft. Ces dernières sont conçue autour de 6 scénarios principaux : messagerie sécurisée, collaboration sécurisée, hôte sécurisé, sécurité intégrée et gestion des identités et des accès.

Pour ce faire, la gamme Microsoft Forefront propose une ligne complète de technologies et produits d’identité et sécurité pour vous aider à développer votre entreprise en toute sécurité, et réduire vos coûts. Par leur intégration dans votre infrastructure informatique existante et par leur déploiement et leur administration simples à réaliser, ces technologies et produits assurent une plus grande protection, permettent une plus grande productivité en facilitant les accès sécurisés et un meilleur contrôle de votre entreprise grâce à leurs capacités de gestion.

1 Livre blanc "GENEVA" CLAIMS BASED ACCESS PLATFORM : http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-

418a-addd-95ee9b046994/Introducing_Geneva_Beta1_Whitepaper.pdf 2 Solutions Forefront d’identité et de sécurité de Microsoft : http://www.microsoft.com/forefront

3 Microsoft Business Ready Security : http://www.microsoft.com/forefront/en/us/business-ready-security.aspx

Forefront fournit une protection qui prend en compte l’ensemble des systèmes et données de votre entreprise, tout en permettant l’accès de vos employés, en tout lieu, sur la base de leur identité. Côté gestion, Forefront sait également tirer parti des investissements existants sur la gamme de produits de gestion Microsoft System Center.

Enfin, Microsoft a une capacité à intervenir sur tous les maillons du système d’information de l’entreprise et de proposer des solutions soit hébergées en interne, soit dans le nuage, soit avec une combinaison des deux :

« Microsoft is one of the few vendors that can truly go end-to-end (cloud-edge-server-client) to make businesses more secure. »

Enterprise Strategy Group Eric Ogren, June 15, 2006 AT THE FOREFRONT OF MICROSOFT SECURITY, InternetNews.com

L’objet de ce document consiste à illustrer comment :

L’approche précédemment présentée succinctement s’applique à toutes les situations qui se présentent dans le contexte de l’entreprise étendue,

Les technologies “Geneva” précédentes et en particulier AD FS 2.0 font de cette approche une réalité opérationnelle dans un environnement hétérogène notamment grâce aux orientations technologiques retenues en termes de standards par exemple.

Avant d’aborder plus précisément trois situations/scénarios dans les sections suivantes, nous vous proposons de revenir rapidement sur la version 1.0 d’AD FS disponible depuis Windows Server 2003 R2.

2 AD FS 1.x, une première déclinaison de l’approche

Active Directory Federation Services (AD FS) est le service d’authentification unique Web (Web Single Sign-On en anglais ou Web SSO en abrégé) Intranet, Extranet et fédéré de la plateforme Windows.

La version 1.0 correspond au service (et éléments constituants associés) proposé par Windows Server 2003 R2 alors que la version 1.1 correspond au rôle serveur AD FS de Windows Server 2008 (R2).

Au-delà de la version de Microsoft Internet Information Server (IIS), AD FS de Windows Server 2008 offre quelques évolutions fonctionnelles par rapport à la solution initialement introduite avec Windows Server 2003 R2, comme en témoigne l’article WHAT’S NEW IN AD FS IN WINDOWS SERVER

20084. Cependant, nombre d’éléments techniques restent communs entre ces deux versions ; c’est pourquoi la suite de cette section fait simplement référence à AD FS 1.x.

Avant d’illustrer les situations, il nous parait important de souligner que le service AD FS et ses différents constituants ainsi que la plateforme Windows sous-jacente ont fait et font, selon les versions considérées, l’objet d’une évaluation Critères Communs.

Ainsi, le service AD FS 1.0, l’une des cibles d’évaluation de Windows Server 2003 R2 (SP2), est tout comme Windows Server 2003 R2 (SP2

lui-même certifié CC EAL (Evaluation Assurance Level) 4+: EAL 4 Augmented with ALC_FLR.3 (Systematic Flaw Remediation) and AVA.VLA.4 (Highly Resistant Vulnerability Analysis). Le rapport d’évaluation Critères Communs correspondant est disponible à l’adresse http://www.niap-ccevs.org/cc-scheme/st/vid10184/.

A son tour, Windows Server 2008 vient de recevoir sa certification CC EAL4+ le 23 septembre dernier. Les détails officiels sur le certificat, la cible de sécurité ainsi que le rapport d’évaluation complet devraient être très prochainement publiés sur le portail http://www.commoncriteriaportal.org.

2.1 Utiliser AD FS 1.x dans l’entreprise pour de l’authentification unique Web

Au sein de l’entreprise, AD FS s’intègre nativement avec les services d’annuaires Active Directory, en l’occurrence Active Directory Domain Services (AD DS en abrégé) ou Active Directory Lightweight Directory Services (AD LDS en abrégé).

(La notion de module de transformation décrite dans le Kit de développement AD FS permet la prise en compte de tout type de référentiel d’identité et permet d’assurer/d’opérer comme son nom l’indique des transformations de revendications, au-delà des transformations multiples supportées nativement. Le Kit de développement AD FS est disponible à l’adresse http://msdn2.microsoft.com/en-us/library/bb267808.aspx.)

Sur cette base, AD FS propose un service assimilable à un STS (tel qu’envisagé en introduction) qui permet l’émission de jetons de sécurité à destination d’applications Web internes (dans le contexte de cette section). L’authentification Kerberos est utilisée par défaut dans le contexte au niveau AD FS.

Le jeton de sécurité signé transmis est un jeton SAML (Security Assertion Markup Language) tel que décrit dans la spécification Assertions et Protocol du standard OASIS SAML v1.15 au niveau de la partie relative aux assertions et schéma XML associé.

4 Article WHAT’S NEW IN AD FS IN WINDOWS SERVER 2008 :

http://technet2.microsoft.com/windowsserver2008/en/library/e11a3e58-bdeb-47e3-b4e2-69bc026f16251033.mspx 5 Spécification ASSERTIONS ET PROTOCOL du standard OASIS SAML v1.1 : http://www.oasis-open.org/specs/#samlv1.1

Les revendications véhiculées par le jeton SAML 1.1 correspondent à des informations issues des référentiels précédents auxquelles ont été appliquées le cas échéant des transformations.

2.1.1 Prendre en compte les applications Web en environnement Windows

AD FS 1.x dispose en standard d’agents Web SSO à destination des environnements IIS : 6.0, 7.0 et 7.5 selon la version considérée de Windows Server.

Deux types d’agent offrant deux modes de fonctionnement sont ainsi proposés ; ce qui permet d’embrasser, à priori, la diversité de la notion (de preuve) d’identité au niveau des applications et des décisions d’autorisation qui sont (potentiellement) à prendre sur cette base :

1. Applications Web nécessitant une identité (Windows) Kerberos sous forme d’un compte

utilisateur

L’agent correspondant est essentiellement implémenté sous la forme d’une extension ISAPI et d’un service Windows d’authentification mettant en œuvre la transition de protocole et la délégation contrainte pour une machine appartenant à une forêt Windows 2003 et ultérieure.

La transition de protocole également appelé S4U (Service for User) confère la possibilité d’authentifier un utilisateur selon un protocole/mécanisme non Kerberos (ici la confiance portée dans le jeton SAML 1.1 signé par AD FS) et d’obtenir sur cette base une identité Kerberos pour accéder à des ressources locales ou distantes. Ce mécanisme introduit par Windows Server 2003 est décrit dans le livre blanc KERBEROS PROTOCOL TRANSITION AND

CONSTRAINED DELEGATION6. Ce mécanisme est souvent référencé par l’acronyme KCD pour

Kerberos Constraint Delegation en anglais.

2. Applications Web fondées sur les revendications, c’est à dire à même de consommer

directement des revendications partir du jeton SAML 1.1 fourni par AD FS.

Ce mode suppose ASP.NET sur la base des version 2.0 et 3.0 du Framework.NET. En effet, l’agent correspondant est implémenté sous forme d’un module HTTP .NET.

La conception d’une application Web en architecture ASP.NET fondée sur les revendications est décrite dans le Kit de développement AD FS dans la section CLAIMS-AWARE

APPLICATIONS7, la documentation sur les différentes classes étant disponibles à l’adresse

http://msdn.microsoft.com/en-us/library/aa964241(VS.85).aspx.

Une application comme Outlook Web Access (OWA) 2007 est prise en charge au travers du premier type d’agent. L’article HOW TO USE ACTIVE DIRECTORY FEDERATION SERVICES WITH OUTLOOK

WEB ACCESS FOR EXCHANGE 20078 décrit la mise en œuvre associée. Il convient de noter qu’OWA ne peut être utilisé que pour accéder à des boîtes à lettre (BAL en abrégé) Exchange 2007. AD FS ne supporte pas l’accès OWA à des BAL Exchange 2000 ou des BAL Exchange 2003 et ce même lorsque la connexion à la BAL est réalisé au travers un serveur Exchange 2007 Client Access.

Il en est de même pour une application type Windows SharePoint Services (WSS) 2.0 ou SharePoint Portal Server (SPS) 2003. Le guide STEP-BY-STEP GUIDE FOR ACTIVE DIRECTORY

FEDERATION SERVICES9 illustre à ce titre la prise en charge d’une ressource de ce type. Il convient

de noter qu’un filtre ISAPI additionnel est utilisé de façon à sauvegarder l’URL accédée dans un entête avant que celle-ci ne soit altérée par le filtre SharePoint.

Une application type WSS 3.0 ou Microsoft Office SharePoint Server (MOSS) 2007 peut s’appuyer sur le même agent, ou bien reposer sur le second type d’agent proposé par AD FS. Le billet INSTALLING MOSS AS A CLAIMS AWARE APPLICATION IN AD FS10 illustre la prise en charge sous cette forme ; ce qui offre, dans le cas présent, une meilleure granularité pour le contrôle d’accès.

6 Livre blanc KERBEROS PROTOCOL TRANSITION AND CONSTRAINED DELEGATION :

http://technet2.microsoft.com/windowsserver/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx 7 Section CLAIMS-AWARE APPLICATIONS du Kit de développement AD FS :

http://technet2.microsoft.com/windowsserver/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx 8 Article HOW TO USE ACTIVE DIRECTORY FEDERATION SERVICES WITH OUTLOOK WEB ACCESS FOR EXCHANGE 2007 :

http://technet.microsoft.com/en-us/library/bb691348.aspx 9 Guide STEP-BY-STEP GUIDE FOR ACTIVE DIRECTORY FEDERATION SERVICES :

http://www.microsoft.com/downloads/details.aspx?familyid=062F7382-A82F-4428-9BBD-A103B9F27654&displaylang=en 10

Billet INSTALLING MOSS AS A CLAIMS AWARE APPLICATION IN AD FS :

http://blogs.technet.com/adfs/archive/2007/02/14/installing-moss-as-a-claims-aware-application-in-adfs.aspx

Comme son nom, l’indique, le billet A SCRIPT TO CONFIGURE SHAREPOINT TO USE ADFS FOR

AUTHENTICATION11 propose un script pour automatiser la configuration des fichiers de configuration

web.config des zones SharePoint impactées.

Par ailleurs, suite à la publication du SP2 d’Office 2007 client, l’intégration avec les clients Office 2007 est désormais supportée. L’article FORMS AUTHENTICATION IN SHAREPOINT PRODUCTS AND

TECHNOLOGIES (PART 3): FORMS AUTHENTICATION VS. WINDOWS AUTHENTICATION12 a été amendé en

conséquence et décrit les principes de fonctionnement associés. Il fait référence à un module HTTP .NET complémentaire dont le code source est publié au travers du billet OFFICE INTEGRATION

WITH MOSS AND ADFS13.

Au sujet de MOSS 2007, il convient également de mentionner l’intégration native entre AD FS et AD RMS (Active Directory Right Management Services), qui permet d’appliquer des droits d’usage aux documents. Une bibliothèque MOSS 2007 peut directement appliquer de tels droits aux documents consultés. Ceci revêt un sens particulier dans un contexte de fédération. L’intégration avec AD FS permet d’échanger des informations avec droits d’usage applicables au-delà du périmètre de confiance vis-à-vis de partenaires qui ne disposent du service AD RMS. L’intégration correspondante est décrite dans le livre blanc USING IDENTITY FEDERATION WITH ACTIVE DIRECTORY

RIGHTS MANAGEMENT SERVICES STEP-BY-STEP GUIDE14.

Nous souhaitons enfin mentionner que Citrix XenApp (nouveau nom de Citrix Presentation Server) depuis la version 4.5 est nativement interopérable avec AD FS. (Pour la version 4.0, il convient de déployer le hotfix PSE400R01W2K3051 et Web Interface 4.0 disponible à l’adresse http://www.mycitrix.com.)

Pour de plus amples informations, nous vous invitons à consulter la présentation à l’adresse http://www.jaytomlin.com/blog/adfs/Citrix_ADFS_JT.ppt ainsi que la vidéo associée disponible à l’adresse http://www.jaytomlin.com/blog/adfs/ADFS_and_WI_12-8-2006.wmv pour la vidéo correspondante. Ces liens et d'autres ressources sont disponibles sur la page de l'auteur à l'adresse http://www.jaytomlin.com/blog/2006/12/technical_video_citrix_and_adf_1.html.

2.1.2 Prendre en compte des applications Web en environnement non

Windows

Au-delà des deux types d’agents Web SSO proposés en standard par AD FS 1.x et à destination d’IIS, des agents additionnels pour d’autres plateformes et/ou serveurs applicatifs sont disponibles au travers d’une offre tierce.

Nous pouvons ainsi notamment mentionner les solutions suivantes :

Centrify DirectControl for Web Applications

(http://www.centrify.com/directcontrol/directcontrol_for_web_apps.asp)

Cette offre propose des agents AD FS à destination des serveurs Web Apache et des principaux serveurs applicatifs Java EE (Java Platform, Enterprise Edition), comprenant notamment Apache Tomcat, BEA WebLogic, IBM WebSphere et JBoss. L’intégration avec AD FS est décrite à l’adresse Internet http://www.centrify.com/directcontrol/AD FS.asp.

En complément, une session AD FS - AUTHENTIFICATION POUR APACHE 2.0 AVEC CENTRIFY

DIRECT CONTROL15 sous forme de Webcast et livre blanc illustre les éléments de mise en

œuvre associés ;

11

Billet A SCRIPT TO CONFIGURE SHAREPOINT TO USE ADFS FOR AUTHENTICATION : http://blogs.msdn.com/sharepoint/archive/2007/10/11/a-script-to-configure-sharepoint-to-use-adfs-for-authentication.aspx 12

Article FORMS AUTHENTICATION IN SHAREPOINT PRODUCTS AND TECHNOLOGIES (PART 3): FORMS AUTHENTICATION VS.

WINDOWS AUTHENTICATION : http://msdn.microsoft.com/en-us/library/bb977430.aspx 13

Billet OFFICE INTEGRATION WITH MOSS AND ADFS : http://blogs.technet.com/adfs/archive/2009/06/16/office-integration-

with-moss-and-adfs.aspx 14

Livre blanc USING IDENTITY FEDERATION WITH ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES STEP-BY-STEP GUIDE : http://technet2.microsoft.com/windowsserver2008/en/library/703206ee-638c-40c9-beb5-d474602b02af1033.mspx 15

Webcast AD FS - AUTHENTIFICATION POUR APACHE 2.0 AVEC CENTRIFY DIRECT CONTROL :

http://www.microsoft.com/france/vision/Technet-tv/Webcast.aspx?EID=5c2427d6-2039-4705-bbcc-9d93446736dd

Quest Single Sign-On for Java (http://www.quest.com/Single-Sign-On-for-Java)

Cette offre propose des agents AD FS à destination des serveurs Web Apache et des principaux serveurs applicatifs Java EE comme Tomcat et JBoss, BEA WebLogic, IBM WebSphere et Oracle AS (9i et 10g) sur notamment de très nombreuses plateformes Linux et Unix.

Une session AD FS - AUTHENTIFICATION POUR LES APPLICATIONS JAVA AVEC VINTELA SSO FOR

JAVA16 sous forme de Webcast et livre blanc illustre les éléments de mise en œuvre associés ;

SourceID (PingIdentity) WS-Federation for Apache 2.0 Toolkit

(http://www.sourceid.org/download)

Ce kit de développement sous licence de logiciel libre propose un agent AD FS à destination des serveurs Web Apache.

Une session AD FS - AUTHENTIFICATION POUR APACHE 2.0 AVEC SOURCEID WSFEDAUTH17 sous

forme de Webcast et livre blanc illustre les éléments de mise en œuvre associés.

De telles solutions complémentaires couvrent le Web SSO lorsque la plateforme applicative accédée est en environnement Linux ou Unix.

2.2 Utiliser AD FS 1.x en Extranet pour des partenaires ou depuis l’Internet pour des collaborateurs mobiles

AD FS 1.x propose dans cette situation un service proxy supportant, par défaut, deux mécanismes d’authentification, à savoir utilisateur/mot de passe et TLS avec certificat client.

Le support d’autres mécanismes comme un mécanisme de type OTP (One Time Password en anglais) peut être introduit compte tenu des choix de conception initiaux et de l’architecture du proxy et de l’extensibilité ainsi offerte comme décrit dans le Kit de développement AD FS.

Une autre alternative serait d’utiliser, en lieu et place du proxy AD FS 1.x, une solution comme Microsoft Internet Security and Acceleration (ISA) Server 200618 ou Microsoft Internet Application Gateway (IAG) 200719 et de faire de la transition de protocole (KCD) vers le service AD FS 1.x. Ainsi, par exemple, après une authentification en OTP via ISA Server 2006/IAG 2007, l’identité de l’utilisateur est transmise au service AD FS 1.x sous forme d’un ticket Kerberos. Dans une approche de ce type, il convient de noter que l’implémentation de KCD dans Microsoft Internet Application Gateway (IAG) 2007 est plus souple que celle d’ISA Server 2006.

Dans cette situation, IAG 2007 apporte, par ailleurs, une sécurité applicative au sens large :

Pare-feu interne permettant l’usage d’expressions régulières (regex) sur le protocole HTTP ;

Analyse du port et de la conformité (également extensible) - il convient de noter que la conformité se décrit par application, et par sous fonction de l’application considérée. Ceci autorise une approche du type Analyse du risque, définition des contremesures sur cette base et enfin mise en œuvre/traduction dans IAG avec, à l’arrivée, par exemple, l’interdiction de télécharger un document depuis une bibliothèque de documents SharePoint du site XX si le poste de travail partenaire ne répond pas à certains critères ;

Réécriture de flux (entête HTTP, HTML, JavaScript, etc.) – ceci permet de rendre une application compatible avec une approche de type « reverse proxy », approche qui permet ainsi de fournir de nombreuses briques de sécurité (par opposition à une approche de type « réseau/tunneling » rendant aveugle les équipements).

16

Webcast AD FS - AUTHENTIFICATION POUR LES APPLICATIONS JAVA AVEC VINTELA SSO FOR

JAVA : http://www.microsoft.com/france/vision/Technet-tv/Webcast.aspx?EID=4e77c5f9-785c-4309-a072-e837a9ada48b 17

Webcast AD FS - AUTHENTIFICATION POUR APACHE 2.0 AVEC SOURCEID WSFEDAUTH :

http://www.microsoft.com/france/vision/Technet-tv/Webcast.aspx?EID=15f6d8d5-642d-42c9-8623-b7f8bcb69f41 18

Microsoft Internet Security and Acceleration (ISA) Server 2006 : http://www.microsoft.com/forefront/edgesecurity/isaserver/en/us/default.aspx 19

Microsoft Internet Application Gateway (IAG) 2007 :

http://www.microsoft.com/forefront/edgesecurity/iag/en/us/default.aspx

2.3 Mettre en place une fédération entre organisations avec AD FS 1.x

AD FS 1.x repose sur le protocole WS-Federation Passive Requestor Profile (WS-Fed PRP en abrégé) développé à l’origine par IBM, BEA Systems, Microsoft, VeriSign, et RSA Security.

Ce protocole souvent appelé WS-Fed Passive est documenté dans le cadre des protocoles de la plateforme Windows (Windows Server Protocols ou WSPP en abrégé, http://msdn.microsoft.com/en-us/library/cc197979.aspx) au travers des spécifications ;

[MS-MWBF] MICROSOFT WEB BROWSER FEDERATED SIGN-ON PROTOCOL SPECIFICATION20,

[MS-MWBE] MICROSOFT WEB BROWSER FEDERATED SIGN-ON PROTOCOL SPECIFICATION21.

Il est repris, comme dérivé simplifié (profil à destination des navigateurs), à la section § 13 WEB

(PASSIVE) REQUESTORS du standard OASIS WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.222 issu du comité technique OASIS Web Services Federation (WSFED)23.

Ce protocole a démontré son large potentiel d’interopérabilité sur le volet de la fédération d’identités depuis 2004 avec l’atelier WS-Fed Protocol workshop (Microsoft, IBM, RSA, Oracle (Oblix), BMC (OpenNetwork), CA (Netegrity), Ping Identity) et permet d’offrir à AD FS 1.x sur cette base une interopérabilité avec les solutions majeures d’identités du marché comme :

BMC Universal Identity Federator ;

CA eTrust SiteMinder Federation Security Services (6 SP5) ;

La mise en œuvre conjointe de cette solution avec ADFS 1.x est décrite dans le livre blanc AD FS STEP-BY-STEP GUIDE: FEDERATION WITH CA SITEMINDER FEDERATION SECURITY

SERVICES24 ;

IBM Tivoli Federated Identity Manager ;

La mise en œuvre conjointe de cette solution avec ADFS 1.x est décrite dans le livre blanc

AD FS STEP-BY-STEP GUIDE: FEDERATION WITH IBM TIVOLI FEDERATED IDENTITY MANAGER25 ;

Internet2 Shibboleth System (1.3) ;

Novell Access Manager ;

Oracle Identity Federation ;

La mise en œuvre conjointe de cette solution avec ADFS 1.x est décrite dans le livre blanc AD FS STEP-BY-STEP GUIDE: FEDERATION WITH ORACLE IDENTITY FEDERATION

26 ;

Ping Identity PingFederate Server ;

RSA Federated Identity Manager (4) ;

Sun OpenSSO ;

symLABS Federated Identity Suite ;

20

Spécification M ICROSOFT WEB BROWSER FEDERATED SIGN-ON PROTOCOL SPECIFICATION [MS-MWBF] : http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-MWBF%5D.pdf 21

Spécification M ICROSOFT WEB BROWSER FEDERATED SIGN-ON PROTOCOL EXTENSIONS [MS-MWBE] :

http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-MWBE%5D.pdf 22

Spécification WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2 : http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf 23

Comité technique OASIS Web Services Federation (WSFED) : http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=wsfed 24

Livre blanc AD FS STEP-BY-STEP GUIDE: FEDERATION WITH CA SITEMINDER FEDERATION SECURITY SERVICES :

http://www.microsoft.com/downloads/details.aspx?FamilyID=921379ca-bbb0-4e9a-a0d4-495d620832f6&DisplayLang=en 25

Livre blanc AD FS STEP-BY-STEP GUIDE: FEDERATION WITH IBM TIVOLI FEDERATED IDENTITY MANAGER : http://www.microsoft.com/downloads/details.aspx?FamilyID=c6f6d212-5625-4922-896f-6b6a3921dfd4&displaylang=en 26

Livre blanc AD FS STEP-BY-STEP GUIDE: FEDERATION WITH ORACLE IDENTITY FEDERATION :

http://www.microsoft.com/downloads/details.aspx?FamilyID=dd59a2d2-eefc-481c-8e39-7f8242e2b44b&displaylang=en

Version3 Enhanced Authentication Edition.

Ce niveau d’interopérabilité avéré confère à toute organisation s’appuyant sur le service AD FS 1.x la capacité d’établir une fédération avec ses partenaires utilisant, le cas échéant, ces solutions pour agir, selon les cas, comme fournisseurs d’identités et/ou fournisseurs de services.

A titre d’illustration, nous souhaitons mentionner ici le cas d’usage du Hub numérique aéronautique de collaboration sécurisée Exostar entre des entreprises du secteur de l’aéronautique et de la défense et leurs sous-traitants. La sécurité des échanges dans un contexte de fédération repose sur les services AD FS 1.x et sont en cours de migration vers AD FS 2.0 de la plateforme “Geneva”.

Ce cas d’usage est décrit à l’adresse http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000003996.

3 Mettre en place une fédération des identités

numériques « Front-Channel » avec AD FS 2.0

Comme nous avons pu l’illustrer au niveau du chapitre précédent sur AD FS 1.x, la spécification WS-Federation PRP sur laquelle repose le service AD FS 1.x connait aujourd’hui une audience certaine pour le Web SSO fédéré et offre une interopérabilité avérée au niveau des solutions majeures d’identités du marché l’ayant implémentée.

Nous faisons référence au Web SSO fédéré à destination des portails et sites Web en tant que fédération des identités « Front-Channel » dans la suite de ce chapitre. Le chapitre suivant s’intéresse à la fédération des identités « Back-Channel » au-delà des portails et sites Web, à savoir la fédération à destination des échanges de messages/données entre entités fédérées et l’ensemble des « Back-End » impactés.

A l’instar de son prédécesseur, AD FS 2.0 constitue le nouveau service de Web SSO Intranet, Extranet et fédéré de la plateforme Windows. A ce titre, AD FS 2.0 reprend bien évidemment à son compte les bénéfices apportés par la version précédente notamment au travers du support de la spécification WS-Federation PRP. AD FS 2.0 propose des fonctionnalités similaires à celles décrites au chapitre précédent.

AD FS 2.0 en étend la portée avec une interopérabilité avec la plateforme Windows Azure27 via la passerelle de fédération dans le nuage Microsoft Federation Gateway (MFG en abrégé).

Pour autant, force est de constater, qu’à ce jour, il existe différentes approches technologiques de la fédération des identités « Front-Channel », voire potentiellement sous forme de différentes versions pour une même proposition. Ceci traduit au demeurant qu’aucune spécification n’est universellement adoptée à ce jour.

Le projet Liberty Alliance28 (LA en abrégé) au même titre que le projet Shibboleth29 à l’initiative de l’Internet2/MACE30 (Middleware Architecture Committee for Education) et d’une façon plus générale la communauté SAML ont profondément contribué à l’analyse et la compréhension de toute une série de cas d'utilisation et d’exigences associées, et les protocoles, formats et concepts proposés par ces groupes de travail ont été une étape importante pour tous ceux impliqués dans (la « portabilité » de) l'identité numérique.

On peut ainsi citer les versions 1.0, 1.1 et 2.0 du standard SAML issus du comité OASIS Security Services (SAML en abrégé) TC31 ainsi que les spécifications ID-FF (Identity Federation Framework en anglais) 1.x du projet Liberty Alliance et Shibboleth 1.x du projet éponyme, qui constituent des extensions des versions 1.x du standard SAML.

Wikipedia32 définit la fédération des identités comme suit:

« Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. »

Ces groupes de travail et projets doivent être remerciés pour la contribution résultante qui a fait indéniablement avancer la réflexion sur les différentes dimensions que recouvrent la définition précédente, notamment sur le plan des conditions relatives à la collaboration entre différentes entités, l’établissement d’un cadre de confiance intégrant les engagements et zones de responsabilité (juridique) de chacun, etc.

27

Plateforme Windows Azure : http://www.windowsazure.com/ 28

Projet Liberty Alliance : http://www.projectliberty.org 29

Projet Shibboleth : http://shibboleth.internet2.edu 30

Middleware Architecture Committee for Education : http://middleware.internet2.edu/MACE 31

Comité OASIS Security Services (SAML) TC : http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 32

Définition Wikipedia de la fédération : http://en.wikipedia.org/wiki/Federated_identity

Sur le plan technique, si les spécifications SAML 1.x, ID-FF 1.x, Shibboleth 1.x et SAML 2.0 reposent sur des principes similaires, ces spécifications n’en ont pas pour autant systématiquement les mêmes fonctionnalités, les mêmes périmètres en termes de profils et de liaisons (binding en anglais), loin s’en faut. Par voie de conséquence, des implémentations potentielles de ces spécifications ne sont pas forcément interopérables entre elles. Principes et fonctionnement similaires ne se traduisent pas par interopérable.

Nous souhaitons souligner, au passage, que Shibboleth, qui constitue à la fois une spécification et une implémentation, est aujourd’hui largement utilisé au sein des Universités en France dans le cadre de la fédération Education-Recherche33, un service rendu par le GIP RENATER. AD FS 2.x comme AD FS 1.x est interopérable avec Shibboleth.

Dans la pratique, la version 1.1 du standard OASIS SAML et les différentes versions de la spécification ID-FF, ont été prises en compte au même titre que d’autres contributions d’autres contributions comme les spécifications Shibboleth 1.x pour donner lieu à la version 2.0 du standard OASIS SAML.

SAML 2.0 est désormais adopté en lieu et place de ses propres propositions par le projet Liberty Alliance comme mentionné à la page http://www.projectliberty.org/liberty/strategic_initiatives/federation avec le schéma explicatif associé. Il en est de même pour le projet Shibboleth.

L’interopérabilité entre applications dans des environnements technologiques hétérogènes est une dimension essentielle de la collaboration entre organisations.

Dans ce contexte et compte tenu des éléments précédents, le support simultané des protocoles WS-Federation PRP et SAML 2.0 et la disponibilité d’une passerelle entre les deux s’impose de façon à pouvoir réunir au sein d’un même scénario des organisations ayant effectué des choix protocolaires différents.

Au-delà du support des jetons SAML 2.0 (en plus des jetons SAML 1.1), AD FS 2.0 introduit donc, au côté du protocole WS-Federation PRP supporté par la version précédente, le support effectif du protocole SAML 2.0 en tant que tel.

Ce support s’inscrit dans la suite logique de l’annonce majeure34 faite par Microsoft en février 2008 dans le but d’améliorer l’ouverture de ses produits, d’offrir une meilleure interopérabilité et de créer des opportunités pour les développeurs, les partenaires, les clients et les concurrents.

L’échange d’information entre personnes et organisations, l’interopérabilité entre applications et services sont devenus en effet des besoins essentiels. Microsoft a pris depuis déjà un certain temps des engagements concernant l’interopérabilité. Nous avons échangé avec nos clients au sujet de leurs besoins d’interopérabilité et nous les avons écoutés sur la manière dont les solutions Microsoft pourraient devenir encore plus ouvertes et interopérables.

Pour répondre à ces enjeux et ces besoins, Microsoft applique quatre principes d’interopérabilité à ses produits à large diffusion comme Windows Vista (y compris le Framework .NET), Windows Server 2008, SQL Server 2008, Exchange Server 2007, Office SharePoint Server 2007 et Office 2007, ainsi que toutes les futures versions de ces produits :

1. Garantir une connexion ouverte à ces produits ;

2. Promouvoir la portabilité des données ;

3. Améliorer le support des standards de l’industrie ;

4. Favoriser l’échange et la collaboration avec l’industrie y compris les différentes communautés Open Source autour des questions d’interopérabilité et de standards.

Ces principes s’appliquent en particulier à AD FS 2.0 compte tenu de ses objectifs.

33

Fédération Education-Recherche du GIP Renater : https://federation.renater.fr/ 34

Cf. Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability - New interoperability principles and actions will increase openness of key products :

http://www.microsoft.com/presspass/press/2008/feb08/02-21ExpandInteroperabilityPR.mspx

L’introduction de ce support est aujourd’hui saluée par les personnes qui incarnent SAML 2.0 comme en témoigne le propos suivant de Scott Cantor à l’occasion de la conférence Microsoft Professional Developer (PDC) 2008 :

« As a Shibboleth and OpenSAML project developer, and a deployer of the Shibboleth software at The Ohio State University, I’m excited and gratified that Microsoft is implementing the SAML 2.0 Web SSO profile in its upcoming products. Throughout the life of the Shibboleth project, and my work on the SAML 2.0 standard, our goal has been to leverage open standards to foster broad interoperability in federated identity within the higher education community and between it and its many commercial and non-commercial partners. Microsoft is clearly one of those critical partners, and as a key technology supplier, its support for the SAML standard reflects an understanding of our community’s needs and goals, and will expand the scope and impact of our efforts.

Our users will benefit by obtaining access to the broadest potential set of federated applications and services, and our worldwide community will benefit from the opportunity to deploy Microsoft’s identity solutions with the knowledge that they will interoperate with Shibboleth. Microsoft’s willingness to listen to our requirements and suggestions demonstrates a commitment to real-world compatibility. I look forward to continuing the dialog with Microsoft as we drive further interoperability in the use of federation metadata to scale and simplify both SAML 2.0 and WS-Federation deployments.»

AD FS 2.0 supporte plus précisément, pour les dimensions fournisseur d’identités (Identity Provider en anglais ou IdP en abrégé) et fournisseur de services (Service Provider en anglais ou SP en abrégé), les modes opérationnels « IdP Lite » et « SP lite » tels que définis dans le document OASIS CONFORMANCE REQUIREMENTS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE

(SAML) V2.035 ainsi que le profil eGovernment harmonisé Liberty Alliance (GSA) version 1.536.

La version Bêta 2 d’AD FS 2.0 disponible depuis le mois de mai 2009 a d’ores et déjà permis de démontrer une interopérabilité avec des implémentations disponibles de SAML 2.0 comme Sun OpenSSO, Novell Access Manager ou encore CA SiteMinder/CA Federation Manager comme en témoignent les trois livres-blancs suivants :

"GENEVA" AND SUN OPENSSO37,

"GENEVA" AND NOVELL ACCESS MANAGER38,

MICROSOFT AND CA – ADFS INTEROP39.

A la date de parution de ce livre-blanc, AD FS 2.0 a depuis passé avec succès les tests d’interopérabilité SAML 2.0 pour les modes opérationnels « IdP Lite » et « SP lite » et le profile GSA 1.5 tels que décrits dans le document LIBERTY INTEROPERABILITY

TESTING PROCEDURES FOR SAML 2.0 REV 3.2.240 et comme en témoignent le communiqué de presse du projet Liberty Alliance41 ainsi que la matrice de résultats42 et le rapport détaillé associé43.

35

Document OASIS Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0 : http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf 36

Liberty Alliance eGovernment profile for SAML 2.0 :

http://www.projectliberty.org/liberty/content/download/4711/32210/file/Liberty_Alliance_eGov_Profile_1.5_Final.pdf 37

Livre blanc "GENEVA" AND SUN OPENSSO :

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9eb1f3c7-84da-40eb-b9aa-44724c98e026 38

Livre blanc "GENEVA" AND NOVELL ACCESS MANAGER : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9eb1f3c7-84da-40eb-b9aa-44724c98e026 39

Livre blanc MICROSOFT AND CA – ADFS INTEROP : http://download.microsoft.com/download/C/F/D/CFD1D9C8-EBA4-

4780-B34B-DBEB5A4792BF/CA-ADFS%20Interop.pdf 40

LIBERTY INTEROPERABILITY TESTING PROCEDURES FOR SAML 2.0 VERSION 3.2.2 : http://www.projectliberty.org/liberty/content/download/4709/32204/file/Liberty_Interoperability_SAML_Test_Plan_v3.2.2%20.

pdf 41

Communiqué de presse du projet Liberty Alliance : http://www.projectliberty.org/liberty/news_events/press_releases/entrust_ibm_microsoft_novell_ping_identity_sap_and_sie

mens_pass_liberty_alliance_saml_2_0_interoperability_testing

Le billet LIBERTY ALLIANCE SAML 2.0 INTEROPERABILITY TESTING RESULTS44 peut être consulté à titre

de complément.

Par ailleurs, AD FS 2.0 est à même d’agir comme passerelle protocolaire entre les protocoles WS-Fed PRP et SAML 2.0 ; dans le contexte d’une transaction courante, et en fonction des acteurs en présence, une partie du dialogue peut s’effectuer selon l’un de ces deux protocoles, et l’autre partie selon l’autre protocole. (Le Webcast CALEB BAKER ON GENEVA SERVER AND SAML 2.0

INTEROPERABILITY45 illustre cette fonctionnalité.)

Ceci étant, les spécifications SAML 2.0 et WS-Federation PRP restreignent l’identité fédérée à des scénarios de Web SSO fédéré entre portails et sites Web. Ceci constitue certes un premier pas important mais à l’évidence aujourd’hui insuffisant.

En effet, la notion de services accessibles dans un cadre de fédération ne se limite à l’accès des pages Web (statiques ou dynamiques) situées sur des sites Web fédérés. Il y a au-delà du site lui-même, pour le service invoqué, des échanges de messages avec des services (Web) de l’entité accédée (ou d’autres entités potentiellement situées au-delà du domaine de sécurité courant).

Ne serait-ce que vu d’un client passif (navigateur), de nombreuses questions restent sans réponse ou une réponse très limitée : sous quelle identité ces pages invoquent des services Web situés dans d’autres domaines de sécurité ? Quelle information d’identité véhiculent-ils ? Est-elle intelligible et digne de confiance pour le service invoqué ? Etc.

On sort ici du cadre d’application stricte des spécifications SAML 2.0 et/ou WS-Federation PRP précédentes.

Le recours ici à une autre spécification, comme par exemple la spécification Liberty Alliance ID-SWF, induit un degré de complexité supplémentaire à ne pas négliger. Cette dernière repose en effet sur des fondements différents, introduit d’autres protocoles et n’adresse malheureusement la problématique posée que de façon très parcellaire.

En effet, que dire alors de services invocables directement sous forme de services Web depuis un client actif (client « intelligent » ou smart client en anglais) ?

Par ailleurs, la notion même de cercle de confiance statique ne répond que très partiellement à la réalité des scénarios de mise en œuvre.

Pour embrasser la diversité des scénarios (et des acteurs potentiels), il apparaît nécessaire de supporter aussi bien des schémas de confiance directe, indirecte, par courtage (brokering en anglais) ainsi que la délégation.

Dès lors, une notion de cercle de confiance statique vole en éclat au profit d’un modèle de fédération complètement dynamique basé sur les cadres de confiance établis unitairement entre les acteurs et sur l'exposition, l'échange de métadonnées (politiques) (et potentiellement différents types de jetons de sécurité, etc.).

42

Matrice de résultats : http://media.projectliberty.org/saml_2_0_test_procedure_v3_2_2_full_matrix_implementation_table_q309/ 43

Rapport détaillé associé :

http://projectliberty.org/liberty/content/download/4732/32917/file/SAML_3Q09_+IOP_Test_Event_Final_Report.pdf 44

Billet LIBERTY ALLIANCE SAML 2.0 INTEROPERABILITY TESTING RESULTS : http://self-issued.info/?p=226 45

Webcast CALEB BAKER ON GENEVA SERVER AND SAML 2.0 INTEROPERABILITY :

http://channel9.msdn.com/shows/Identity/Caleb-Baker-on-Geneva-Server-and-SAML-20-Interoperability/

La diversité des cas d’usage (scénarios) de la fédération des identités (« Front Channel » vs. « Back Channel ») impose, en conséquence, de disposer d’une approche technologique plus vaste et offrant une flexibilité accrue :

Support non seulement de clients passifs (navigateur) mais également et principalement de clients actifs à même de consommer intelligemment les métadonnées exposées par les portails, les sites et/ou les services Web ;

Consommation (et exploitation) dynamique des métadonnées (politiques de sécurité, de fédération, etc.) exposées par les portails, les sites et/ou les services Web ;

Support (émission, échange, validation, etc.) de multiples formats de jetons de sécurité (SAML évidemment mais au même titre les certificats X.509, les tickets Kerberos, etc. selon les contextes) et abstraction de ce dernier pour les sites et services Web au travers de la notion de collection de revendications (claims en anglais).

De par la consommation des métadonnées et le support (dynamique) de l’ensemble des schémas de confiance qui peuvent se présenter (confiance directe (avec ou sans nécessité de multiples jetons de sécurité émanant de multiples fournisseurs d’identités), confiance indirecte avec présence d’intermédiaire(s) médiateur de confiance, délégation d’identité avec confiance directe, délégation avec confiance indirecte), ceci permet de passer de ce que l’identité possède (ses crédentités ou informations de sécurité) à ce que la ressource fédérée accédée exige. Ceci induit une voie d’extension sans précédent pour la prise en compte de nouveaux partenaires. Par essence, les spécifications SAML 2.0 (ou WS-Federation PRP) imposent un seul et unique jeton SAML (1.x ou 2.0). Aucune voie d’extension n’est possible ;

Support de scénarios avec ou SANS liaison/mappages de comptes. Beaucoup de scénarios ne justifient pas en effet la maintenance d’un compte (et ses coût afférents) au niveau du fournisseur de services pour les ressources exposées ;

Etc.

Il s’avère donc nécessaire d’aller au-delà pour embrasser la diversité des situations à prendre en considération. C’est ce que propose AD FS 2.0 et les autres technologies de la plateforme “Geneva” au travers d’un support natif des services Web avancés, à savoir des services Web de type SOAP développé sur la base de la pile standardisée WS-* (STAR pour Secured, Transacted, Asynchronous & Reliable en anglais) constituée de recommandations du W3C ou de standards de

l’OASIS selon le périmètre fonctionnel considéré.

Ceci constitue l’objet du chapitre suivant.

Il est à noter que, dans ce contexte, AD FS 2.0 introduit par rapport à la version précédente une autre terminologie mieux à même de refléter les multiples schémas de confiance qui peuvent être pris en charge. (Le Webcast DONOVAN FOLLETTE ON MAKING THE SHIFT FROM ADFS V1 TO GENEVA

SERVER46

précise les correspondances en termes de terminologies et de concepts entre AD FS 1.0 et AD FS 2.0.)

46

Webcast DONOVAN FOLLETTE ON MAKING THE SHIFT FROM ADFS V1 TO GENEVA SERVER :

http://channel9.msdn.com/shows/Identity/Donovan-Follette-on-making-the-shift-from-ADFS-v1-to-Geneva-Server/

4 Mettre en place une fédération des identités

numériques « Back-Channel » avec AD FS 2.0 et WIF

Afin de considérer la diversité des cas d’usage, sortons à présent du cadre de fédération frontale plus directement lié aux portails et sites Web pour aborder celui esquissé au chapitre précédent de la fédération à destination des échanges de messages/données entre entités fédérées et l’ensemble des « Back-End » impactés.

La fédération des identités « Back-Channel » est tout aussi fondamentale en termes d’interopérabilité et impacte en particulier les services Web et leur sécurité en termes d’authentification et de contrôle d’accès.

4.1 Prendre en compte la sécurisation des services Web et les besoins associés

Dans le contexte de la sécurisation des service Web de type SOAP, la nature autonome des services Web met l’accent sur la gestion explicite des cadres de confiance entre les applications et services. Ceci nécessite que des processus ou des systèmes qui étaient centralisés évoluent de

facto vers un modèle fédéré.

Nous sommes intimement convaincus qu’un tel modèle fédéré implique qu’une information d’identité et/ou d’autorisation de confiance pour le service accédé soit véhiculée dans chaque message SOAP de façon sécurisée et standard. Cette information d’identité et/ou d’autorisation de confiance est véhiculée sous forme d’un ou plusieurs jetons (d’authentification et/ou

d’autorisations) exprimant des revendications.

Au-delà de la possibilité de signer/chiffrer tout ou partie d’un message SOAP, le standard OASIS WEB SERVICES SECURITY: SOAP MESSAGE SECURITY (WS-SECURITY) 1.x permet de véhiculer de façon agnostique un ou plusieurs jeton(s) de sécurité (avec le cas échéant une preuve de possession associée). c’est à notre sens, cette dimension qu’il convient de privilégier pour la sécurisation des service Web de type SOAP. Le profil BASIC SECURITY PROFILE 1.1 défini par le groupe de travail éponyme (http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity) au niveau de l’organisation WS-I constitue un socle de référence pour garantir l’interopérabilité

entre les différentes implémentations47

.

Au sein dans le corpus des standards des services Web avancés, à savoir la pile WS-* (STAR pour Secured, Transacted, Asynchronous & Reliable en anglais), le standard OASIS WEB

SERVICES TRUST LANGUAGE (WS-TRUST) issu du comité technique OASIS Web Services Secure Exchange (WS-SX)48 définit pour cela un modèle de service de jetons de sécurité (Security Token Service en anglais ou STS en abrégé) auprès duquel de tels jetons (d’authentification et/ou d’autorisations) peuvent être obtenus ainsi que le protocole pour converser avec ce service de jetons de sécurité. Un tel service est à même d’émettre, de valider et d’échanger des jetons de sécurité, d’émettre dans ce dernier cas par exemple un jeton de délégation (élément Act As). La notion d’échange induit la capacité de transformation de jetons en termes de type de confiance, de format, de sémantique et de (valeurs des) revendications véhiculées par un jeton. Il s’agit

47 En raison de la multiplicité des plates-formes et de technologies susceptibles de disposer d’implémentation des standards

des services Web (avancés), il est essentiel que les services Web soient capables de fonctionner dans un environnement

hétérogène. WS-I peut simplifier cette tâche en définissant des profils qui correspondent un groupe de spécifications

compatibles à un certain niveau de version adressant un ensemble cohérent de fonctionnalités et de recommandations d’utilisation à observer. Un profil est un ensemble de spécifications, accompagné de clarifications, interprétations et

restrictions de celles-ci de façon à promouvoir l’interopérabilité. Dans le même temps, WS-I crée des protocoles et outils de test (http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools) afin de vérifier le respect effectif de ces profils

par les différents produits et solutions du marché. Les éditeurs proposent conjointement des modèles de mise en œuvre qui se conforment aux recommandations précédentes (http://www.ws-i.org/deliverables/workinggroup.aspx?wg=sampleapps).

En ce sens, WS-I représente une sorte d’intégrateur de standards qui s’appuie et qui utilise les spécifications de différentes structures de standardisation comme W3C, OASIS ou IETF. 48

Comité technique OASIS Web Services Secure Exchange (WS-SX) : http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=ws-sx

précisément de la traduction sous forme de standard de la notion de STS évoquée en introduction

dans le cadre d’une nouvelle approche.

L'idée de transformation de jetons et de revendications introduite par ce standard constitue très certainement l'avancée technique la plus significative dans l'informatique distribuée

depuis au moins les dix dernières années.

L’impact et les réponses qui sont ainsi apportées n’ont d’ailleurs pas été complètement anticipés

au début des travaux dans ce domaine.

Compte tenu de la diversité des scénarios (et des acteurs potentiels) à prendre en considération, il apparaît nécessaire de supporter aussi bien des schémas de confiance directe, indirecte, par courtage ainsi que la délégation. Ceci exige un modèle de fédération qui ne peut être autrement

que complètement négocié dynamiquement via un pilotage par les métadonnées.

En complément du standard OASIS WS-Trust, le standard OASIS WS-Federation propose notamment une extension des métadonnées de SAML 2.0 (décrites dans la spécification METADATA FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.049) adaptée au

contexte des services Web.

La spécification WS-Federation permet, par ailleurs, le développement et le déploiement de services de fédération avancés (services d’authentification, d’autorisations, d’attributs, de pseudonymes, etc.) comme une simple variation du modèle de transformation de revendications

d’un service de jetons WS-Trust !

Dès lors, pour une transaction donnée, au travers de la chorégraphie d’invocation en cours, le cadre de confiance est dynamique et fondé sur la prise en charge de politiques de confiance (métadonnées de fédération) établies et exposées par les différentes parties impliquées et sur la transmission (et l’échange) de jetons de sécurité (d’authentification, d’autorisations, d’attributs, de pseudonymes) :

Les (intermédiaires et les) ressources fédérées comprennent des jetons (d ’authentification, d’autorisations, d’attributs, de pseudonymes) spécifiques (en termes de format et de sémantique pour les revendications ainsi véhiculées),

Les STS émettent des jetons ou bien traduisent les jetons émis par d’autres services de jetons, tiers de confiance en d’autres jetons (depuis ce que le demandeur initial possède vers ce que le service Web accédé en final exige/a besoin pour prendre (ou en déduire) ses

décisions d’autorisation).

Les jetons de sécurité résultants de cette transaction sont partagés, soit directement soit indirectement, entre les parties impliquées dans le traitement du message. En conséquence, ces jetons de sécurité sont émis par un STS, racine approuvée (de confiance) ou par un STS, nœud de

la chaîne de confiance et/ou de délégation.

Les standards OASIS WS-Security, WS-Trust et WS-Federation rendent possible pour la fédération l’émergence d’un modèle complètement distribué et dynamique piloté par l'exposition, l'échange de politiques de fédération (métadonnées de fédération) avec, à la

clé, une très large variété de schéma de confiance applicables.

La gestion, la découverte et l'accès à de tels services Web sécurisés s’en trouvent notablement simplifiés lorsque ces derniers reposent tous sur un modèle de traitement commun et parlent le même protocole.

AD FS 2.0 offre un support de l’ensemble des standards WS-Security, WS-Trust et WS-Federation de façon à rendre concrets tous ces scénarios. C’est également le cas de la technologie Windows Identity Foundation (WIF en abrégé), autre élément constituant de la plateforme “Geneva”. WIF apporte le support de ces standards au niveau de la technologie Windows Communication Foundation (WCF en abrégé), l’implémentation Microsoft de la pile standardisée WS-*. WIF facilite également la conception de STS personnalisés pour réaliser les nécessaires adaptations d’impédance dans un contexte donné ; ce qui peut se traduire, au-delà de ce qui a été souligné

auparavant, par exemple par la prise en charge d’un autre protocole comme OpenID50.

49

Spécification METADATA FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0 : http://docs.oasis-

open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf 50

OpenID Foundation : http://openid.net/

Les services Web cibles peuvent également être situés dans le nuage via plateforme Windows Azure51. Dans ce cas, un cadre de confiance doit être établi entre AD FS 20 et la passerelle de fédération dans le nuage Microsoft Federation Gateway (MFG en abrégé).

4.2 Considérations additionnelles vis-à-vis des standards OASIS WS-Federation 1.2 et SAML 2.0

La spécification WS-Federation doit être considérée comme une spécification évolutive des spécifications SAML, et non pas comme une alternative.

Le livre blanc UNDERSTANDING WS-FEDERATION52, publié conjointement par IBM et Microsoft, tous

deux membres du comité OASIS WSFED donne une appréciation du périmètre fonctionnel de la spécification.

Comme souligné en introduction de la section précédente, le travail de la communauté SAML a constitué une étape importante pour tous ceux impliqués dans (la « portabilité » de) l'identité numérique. Rien dans la spécification WS-Federation n’invalide ce travail.

Pour autant, une proposition technologique n’apporte pas forcément de façon immuable une réponse pertinente dans le temps. Si l’on se souvient un instant du moment où SAML a été introduit et positionné comme une alternative à l’« authentification » LDAP, aucun des contributeurs LDAP de l’époque n’a considéré la proposition faite comme la réponse ultime au domaine de l’identité et des attributs. Des personnes comme Mark Wahl, Bob Morgan ou encore Keith Hazelton, profondément impliquées dans Kerberos et LDAP, et vues par beaucoup comme des « gourous » LDAP, se sont alors au contraire montrées prêtes à embrasser de nouvelles technologies comme SAML en tant que réponse à de nouveaux cas d’usage.

Tout comme SAML a introduit une nouvelle fondation en son temps, WS-Federation est destinée à résoudre un certain nombre de choses que nombreux souhaitent voir mieux définies de façon à faciliter l'interopérabilité au niveau de la fédération comme, par exemple, une séparation claire entre les mécanismes de confiance, les formats de jetons de sécurité, et les protocoles pour obtenir ces jetons.

La spécification WS-Federation vient ainsi compléter des standards OASIS comme, en particulier WS-Security et WS-Trust. WS-Security permet de véhiculer de façon agnostique un ou plusieurs jeton(s) de sécurité (avec le cas échéant une preuve de possession associée). WS-Trust définit un modèle de service de jetons de sécurité ou STS.

Ces protocoles n’avaient même pas été inventés lors des évolutions de SAML.

D’ailleurs à ce titre, comment attendre de SAML une adéquation optimale avec ces considérations qui au final émergent depuis peu ? Ceci ne déprécie pas les succès passés de SAML. Ce n'est pas ainsi que l’ingénierie logicielle fonctionne.

Par ailleurs, comme mentionné précédemment, une section de la spécification WS-Federation définit les règles de codage qui permettent à de nombreuses fonctionnalités du protocole WS-Trust et des extensions WS-Federation d’être utilisées par les navigateurs et les portails et sites Web via des mécanismes standard HTTP. Cette section, initialement connue sous le nom de profil passif de WS-Federation (WS-Federation PRP) duplique la fonctionnalité définie dans la spécification SAML 2.0 abordée précédemment.

Cette superposition trouve sa fondation et justification dans les objectifs même de WS-Federation afin de fournir un protocole commun pour effectuer des opérations de fédération d’identités à destination des services Web mais également des portails et sites Web.

Un même protocole commun assure des économies par rapport au développement, aux tests, au déploiement et à la maintenance des services de fédération, et ce aussi bien pour les fournisseurs de technologies que pour les clients, consommateurs de ces technologies.

51

Plateforme Windows Azure : http://www.windowsazure.com/ 52

Livre blanc UNDERSTANDING WS-FEDERATION : http://msdn2.microsoft.com/en-us/library/bb498017.aspx

L’échec dans l'intégration des scénarios à bases de clients passifs (navigateurs) et de clients actifs multiplie non seulement les coûts mais induit également pour les clients aujourd’hui ou dans un futur proche des problématiques de migration douloureuses.

Le standard WS-Federation se distingue ainsi du standard SAML en proposant à l’industrie des bénéfices qui ne sont disponibles dans aucun autre standard existant.

Comme présenté à la section § 2.3 METTRE EN PLACE UNE FEDERATION ENTRE ORGANISATIONS AVEC

AD FS 1.X, cette « déclinaison » de WS-Federation est aujourd’hui implémentée par de nombreux fournisseurs de solutions de gestion d’identités numériques. Certaines de ces solutions d’identités, à l’instar d’AD FS 2.0, sont plus généralement multi-piles (SAML 2.0 et WS-Federation PRP) comme aucune de ces deux spécifications n’est à ce jour universellement adoptée. Elles offrent de facto une passerelle entre ces piles.

5 Vers un écosystème de confiance

Le succès des situations précédentes dépend grandement de l’adhésion des utilisateurs d’un système fédéré et par là même de la confiance que ces derniers portent dans le système pris dans son ensemble.

Pourquoi irais-je donner mes identifiants ? Que va-t-il en être fait ? Sont autant de questions que l’usager est amené à se poser et ce dernier ne comprend pas pourquoi il doit faire tout cela. La confiance ne se décrète pas, elle se mérite !

Pour autant, le besoin de mécanismes d’authentification forte et de dispositif anti-hameçonnage/vol d’identité est croissant. Les statistiques proposées sur le site de l’Anti-Phishing Working Group53 sont, à ce titre, édifiantes. Les fournisseurs de services, consommateurs d’identités, sont aujourd’hui beaucoup plus intéressés par ce genre de choses qu’il y a encore 2 ou 3 ans.

Kim Cameron, architecte en chef de l’identité numérique chez Microsoft, lançait, il y a maintenant plus de deux ans au travers de son blog http://www.identityblog.com, une large initiative visant à améliorer la sécurité et l’interopérabilité des identités en ligne.

Suite à l’expérience Microsoft Passport (devenu Windows Live) qui est un succès en termes de fournisseur d’identités pour des sites Microsoft comme MSN (avec plus de 520 millions d’utilisateurs et de l’ordre un milliard d’ouvertures de session/jour) mais également un échec comme fournisseur d’identités pour l’Internet, cette initiative s’est d’abord concentrée sur le développement et le partage d’une compréhension formelle des dynamiques amenant des systèmes d’identités numériques en ligne à rencontrer le succès ou, au contraire à échouer et ce, dans différents contextes. Les larges discussions qui s’en sont suivi avec l’industrie, les associations de défense des libertés individuelles, etc. ont conduit à établir un consensus autour de 7 lois de l’identité qui sont discutées dans le livre blanc THE LAWS OF IDENTITY

54.

Prises dans leur ensemble, ces lois définissent un « méta-système d’identités unifié » qui offre à l’Internet la couche Identité qui, de façon évidente, lui fait défaut. La résolution d’un tel problème offre la possibilité de créer des solutions d’identités Web interopérables très sécurisées à même d’offrir à leur tour au grand public plus de choix, de flexibilité et de sécurité dans leur utilisation d’Internet au quotidien. Elle est donc bénéfique à tous.

Un méta-système d’identités (système de systèmes d’identités) constitue une architecture interopérable pour l’identité numérique qui présume que les personnes disposent de plusieurs identités numériques basées sur de multiples technologies/protocoles, implémentations et fournisseurs sous-jacents.

Une telle approche permet non seulement aux personnes d’être en contrôle, au travers de la notion de « sélecteur d’identités », de leurs identités (manipulées sous forme de cartes d’informations) et de l’usage qui en est fait, mais également aux organisations de pouvoir continuer à utiliser et bénéficier de leur investissements existants en termes d’infrastructure d’identités, de choisir la technologie d’identité qui leur est la mieux appropriée, et de plus facilement migrer d’anciennes technologies vers de nouvelles technologies sans pour autant sacrifier l’interopérabilité avec les autres.

Les organisations recherchent l’interopérabilité pour pouvoir utiliser la mosaïque de technologies la plus proche de leurs besoins. L’interopérabilité (de la gestion) des identités entre plateformes et le Web (sites Web et services Web) est particulièrement importante pour l’amélioration de la valeur des technologies pour les entreprises et le grand public.

Le livre blanc THE IDENTITY METASYSTEM55 présente, en partant des conclusions et du large

consensus des lois de l’identité, une architecture ouverte et interopérable pour construire un tel méta-système et décrit comment participer à ce méta-système d’identités qui par nature n’appartient à et n’est contrôlé par personne. Ce méta-système s’inscrit dans la droite ligne de la nouvelle approche proposée en introduction.

53

Anti-Phishing Working Group : http://www.antiphishing.org 54

Livre blanc THE LAWS OF IDENTITY : http://www.identityblog.com/?p=354 55

Livre blanc THE IDENTITY METASYSTEM : http://www.identityblog.com/?p=355

Le livre blanc DESIGN RATIONALE BEHIND THE IDENTITY METASYSTEM ARCHITECTURE56 aborde plus en

détail les décisions de conception et leur rôle au sein d’un méta-système d’identités.

D’un point de vue technique, l’architecture des services Web avancés fournit au méta-système d’identités une pile protocolaire standard WS-* et l’enveloppe. Le méta-système d’identités n’est dans la pratique qu’un simple profil de ces spécifications/protocoles. La très large adoption des standards de la pile WS-* (recommandations du W3C ou standards de l’OASIS selon le périmètre fonctionnel) fait qu’il est très facile de participer au méta-système d’identités quel que soit la plateforme ou la technologie utilisée.

C’est cette même raison qui a conduit la DGME (Direction Générale de la Modernisation de l’Etat) à reposer sur ces standards pour le protocole PRESTO (PRotocole d’Echanges Standard et Ouvert)57, protocole d’échange pour les besoins de l’administration électronique.

Le livre blanc PRESTO UN PROTOCOLE D'ECHANGE POUR LES BESOINS DE L'ADMINISTRATION

ELECTRONIQUE58 revient sur les défis architecturaux et les orientations et axes d’architecture retenus

dans ce cadre. La volonté des concepteurs de PRESTO était non seulement de définir ce protocole, mais également de démontrer que la dite spécification pouvait être implémentée sur des environnements et langages divers et que les implémentations résultantes tenaient les promesses d’interopérabilité des orientations retenues.

PRESTO et les services Web avancés WS-* font des émules. Le colloque eGovINTEROP’0759 qui s’est tenu à Paris en fin d’année 2007 a montré que l’Allemagne avec la version 2.0 de son protocole OSCI est en cours de définition d’un protocole proche de PRESTO. D’autres pays comme la Suède, le Danemark et l’Estonie lui emboîtent le pas. Le protocole européen eLink ayant été abandonné, la commission européenne, dans le cadre du programme IDABC (Interoperable Delivery of Pan-European eGovernment Services to Public Administrations, Business and Citizens en anglais), assiste aujourd’hui ces pays dans la définition d’un profil commun s’appuyant sur PRESTO, mais basé sur des profils d’interopérabilité internationaux.

Comme nous l’avons vu dans le chapitre précédent § 4 METTRE EN PLACE UNE FEDERATION DES

IDENTITES NUMERIQUES « BACK-CHANNEL », le standard OASIS WS-Security permet de véhiculer un jeton de sécurité. Un tel jeton peut être obtenu auprès d’un service de jetons de sécurité (STS en abrégé pour Security Token Service en anglais) à travers le standard OASIS WS-Trust.

Dans l’usage fait des identités et le contrôle associé, une composante essentielle d’un tel méta-système est le sélecteur d’identités en tant que tel. Le sélecteur d’identités contient les cartes d’informations relatives aux différentes identités de l’utilisateur.

Wikipedia appelle les cartes d’informations (Information Card en anglais) ou i-cards60, et les définit comme telles :

« A rectangular icon displayed in the user interface of an identity agent that represents a digital identity--a set of claims about a digital subject. »

En d’autres termes, une carte d’informations constitue un artefact permettant d’obtenir auprès d’un fournisseur d’identités, après identification/authentification, une preuve d’identité sous forme de revendications (claims en anglais).

Le sélecteur d’identités permet à l’utilisateur, dans le cadre d’une fédération centrée sur lui-même :

De s’assurer de l’identité du fournisseur de services accédé,

De sélectionner dans le contexte courant de la transaction son identité (via la sélection d’une carte d’informations), et par la même le fournisseur d’identités de son choix,

56

Livre blanc DESIGN RATIONALE BEHIND THE IDENTITY METASYSTEM ARCHITECTURE : http://www.identityblog.com/wp-

content/resources/design_rationale.pdf 57

Protocole PRESTO : http://www.synergies-publiques.fr/rubrique.php?id_rubrique=165 58

Livre blanc PRESTO UN PROTOCOLE D'ECHANGE POUR LES BESOINS DE L'ADMINISTRATION ELECTRONIQUE:

http://download.microsoft.com/download/4/7/2/4729870a-44f4-4e60-abcc-

14d9d6f37fe4/PRESTO%20un%20protocole%20d'échange%20pour%20les%20besoins%20de%20l'administration%20électronique%20v1%200.pdf 59

Colloque eGovINTEROP’07 : http://egovinterop.eu/public/page.tpl?rub=9600 60

Définition Wikipedia de l’i-card : http://en.wikipedia.org/wiki/I-Card

De la communiquer après son consentement explicite au fournisseur de services accédé ou consommateur d’identités (relying party en anglais).

Le méta-système d’identités :

Repositionne les identités numériques d’un sujet sous son contrôle direct et explicite,

Offre une expérience utilisateur prévisible, cohérente et reconductible quels que soient les fournisseurs d’identités et de services impliqués dans le contexte de la transaction courante,

Élimine les coûteuses intégrations pas toujours des plus ergonomiques et cohérentes tant au niveau fournisseur d’identités que fournisseur de services.

L’ensemble des problématiques adressées par le sélecteur d’identités (au sein d’un écosystème de confiance), en permettant aux utilisateurs de gérer leurs propres identités (quelles soient omni ou mon directionnelles), et les problèmes que rencontre la fédération des identités sont dans l’ensemble orthogonaux.

Le méta-système d’identités n’est donc pas positionné contre tel ou tel protocole de fédération, mais au contraire supprime les frictions qui peuvent exister et résout des problématiques connexes et complémentaires. Il s’agit donc d’une approche orthogonale. Il convient de noter à ce titre le profil SAML 2.0 suivant en cours d’élaboration : SAML V2.0 INFORMATION CARD TOKEN PROFILE

61.

La large collaboration de l'industrie qui a émergé autour du méta-système d’identités et des cartes d'information (et leur métaphore visuelle associée) prend aujourd’hui une dimension nouvelle avec la constitution de l’« Information Card Foundation62 » (ICF en abrégé) en juin 2008 et le communiqué de presse63 associé. Parmi son comité directeur, on trouve Google, Microsoft, Novell, Oracle et PayPal.

Comme mentionné précédemment, les cartes d’information sont orthogonales aux technologies de fédération et le projet Liberty Alliance, membre associé, salue cette initiative de sécurité et d’interopérabilité que traduit la constitution de l’ICF. Brett McDowell, executive director, du projet Liberty Alliance s’est exprimé dans les termes suivants :

« Our shared goal is to deliver a ubiquitous, interoperable, privacy-respecting federated identity layer as a means to seamless, secure online transactions over network infrastructure. We look forward to exploring with ICF the expansion of the Liberty Alliance Interoperable(tm) testing program to include Information Card interoperability as well as utilization of the Identity Assurance Framework across Information Card deployments. »

L’autre événement significatif est la publication en juin 2009 de la version 1.0 du standard OASIS IDENTITY METASYSTEM INTEROPERABILITY (IMI) par le comité technique éponyme64, standard fondé sur les standards OASIS et recommandations W3C de la pile WS-*, notamment WS-Security, WS-SecurityPolicy, WS-Trust, WS-MetadataExchange

61

SAML V2.0 INFORMATION CARD TOKEN PROFILE : http://www.oasis-open.org/committees/download.php/29019/draft-sstc-

saml2-infocard-02.pdf 62

Information Card Foundation : http://informationcard.net/ 63

Communiqué de presse de l’ICF : http://informationcard.net/files/ICFPressRelease6-24-08.pdf 64

Comité technique OASIS Identity Metasystem Interoperability (IMI) : http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=imi

Au-delà de la publication par Microsoft du profil d'interopérabilité pour le sélecteur d’identités (IDENTITY SELECTOR INTEROPERABILITY PROFILE (ISIP) 1.X65 couvert par l’Open Specification Promise66 (OSP en abrégé) de Microsoft, ceci a nécessité du temps et des investissements de tous, avec à la clé quelques étapes majeures comme :

Les workshops Berkman sur les initiatives d’identité(s) centrée(s) sur les utilisateurs en 2005 et 2006,

La constitution d’OSIS (Open-Source Identity System en anglais)67, et les workshops d’interopérabilité associé (I1, I268, I369, et I470),

La collaboration anti-hameçonnage OpenID71,

L’adoption d’une icône commune Carte d'information72 comme suit,

et, bien sûr la disponibilité effective de nombreuses solutions logicielles développées par des éditeurs, des communautés et des contributions individuelles à destination de l’ensemble des principales plateformes de développement, comprenant en autres les livrables des projets Higgins73, Bandit74 (et DigitalME75 dans ce cadre), OpenSSO, etc. et les technologies de Sun Microsystems76, CA77, IBM78 et Microsoft.

Pour autant, au-delà des difficultés, l’industrie et les acteurs de l’identité numérique ont perçu dans ces briques logicielles novatrices une innovation majeure et en ont souhaité une concrétisation par le biais d’un effort concerté et coopératif de l’ensemble des acteurs.

Microsoft France, au même titre que l’ensemble des membres de la fondation et du comité technique OASIS IMI, est convaincue que nombre des dangers, des complications, des pertes de temps, des incertitudes liées aux expériences en ligne d'aujourd'hui peuvent s’estomper rapidement. Une adoption et un déploiement étendu du méta-système d’identités possède intrinsèquement le potentiel de résoudre la plupart de ces problèmes, bénéficiant ainsi à tout le monde et accélérant la croissance à long terme de la connectivité en rendant le monde en ligne plus sûr, plus digne de confiance et plus facile à utiliser.

Le « big-bang » de l’identité fédérée est en marche.

Les technologies de la plateforme “Geneva”, en l’occurrence, AD FS 2.0, WIF et Windows CardSpace 2.0 sont conformes au standard OASIS IMI 1.0.

AD FS 2.0 permet la génération de cartes d’information à destination des identités décrites dans les services d’annuaires Active Directory, en l’occurrence Active Directory Domain Services (AD

65

IDENTITY SELECTOR INTEROPERABILITY PROFILE (ISIP) 1.X : http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en 66

Microsoft Open Specification Promise : http://www.microsoft.com/interop/osp 67

Open-Source Identity System : http://osis.idcommons.net/wiki/Main_Page 68

Workshop OSIS d’interopérabilité I2 : http://osis.idcommons.net/wiki/I2-Barcelona 69

Workshop OSIS d’interopérabilité I3 : http://osis.idcommons.net/wiki/I3_User-Centric_Identity_Interop_through_RSA_2008 70

Workshop OSIS d’interopérabilité I4 : http://osis.idcommons.net/wiki/I4_User-

Centric_Identity_Interop_through_Digital_ID_World_2008 71

Collaboration CardSpace – OpenID : http://www.identityblog.com/?p=668 72

Icône commune Carte d’information : http://self-issued.info/?p=17 73

Projet Higgins 1.0 : http://www.eclipse.org/org/press-release/20080221_higgins.php 74

Projet Bandit : http://www.bandit-project.org/ 75

Sélecteur DigitalME : http://code.bandit-project.org/trac/wiki/DigitalMe 76

Billet Lifting the curtain : http://blog.beuchelt.org/2008/03/31/Lifting+The+Curtain.aspx 77

Livre blanc CA AND M ICROSOFT SUPPORT FOR USER-CENTRIC IDENTITY AND THE IDENTITY METASYSTEM : http://www.ca.com/files/whitepapers/ca_microsoft_usercentric_identity_wp.pdf 78

IBM Expands Federated Identity Effort :

http://www.internetnews.com/infra/article.php/3748166/IBM+Expands+Federated+Identity+Effort.htm

DS en abrégé) ou Active Directory Lightweight Directory Services (AD LDS en abrégé). L’application de stratégies de groupes permet, par ailleurs, une publication (et le cas échéant un renouvellement) automatisé des cartes d’information ainsi que la définition par stratégies de groupe d’une politique de confiance quant aux ressources fédérées de confiance qu’il s’agisse de site Web ou de service Web.

WIF permet de concevoir des sites Web et des services Web qui participent au méta-système. Enfin, Windows CardSpace 2.0 constitue l’implémentation Microsoft de la notion de sélecteur d’identités.

6 En guise de synthèse

Ce livre banc a permis d’introduire une nouvelle approche en termes d’authentification et de contrôle d’accès, fondée sur la notion de revendications véhiculées par des jetons de sécurité émis par des services de jetons de sécurité (STS) de façon à divulguer sélectivement des informations d'identité.

Cette approche vise à faciliter les décisions de contrôle d’accès entre applications, services et système indépendamment de l’emplacement au sein du SI, des espaces de confiance, de l’architecture, de l’environnement technique, de la technologie, etc. Ceci conduite à simplifier la gestion des identités et des accès et une collaboration sécurisée au sein d’une entreprise désormais étendue.

Les technologies de la plateforme “Geneva”, en l’occurrence, AD FS 2.0, WIF et Windows CardSpace 2.0 font de cette approche une réalité opérationnelle dans des environnements hétérogènes.

Pour cela, la plateforme “Geneva” propose :

un jeu d’options riche supportant virtuellement tous types de scénarios d’identité impliquant des applications Web, des services Web ou les deux ;

une interopérabilité native intégrée à destination d’un monde hétérogène via des standards internationaux comme OASIS WS-Trust, WS-Federation, et SAML 2.0 et des revendications (agnostiques et fonction du contexte).

Elle implémente enfin la vision de méta système d’identités pour une identité ouverte et interopérable quel que soit le contexte et le cas d’usage.

La plateforme “Geneva” contribue pour les développeurs à simplifier l’accès applicatif en externalisant l’authentification et le contrôle d’accès des applications (ASP.NET, SharePoint, autres) et des services Web (WCF, autres) via les revendications et à réduire l'effort de développement induit avec une logique de sécurité préétablie.

La plateforme “Geneva” aide les professionnels de l’informatique à déployer et gérer efficacement de nouveaux services et applications en réduisant le travail d’implémentation personnalisé, en centralisant et en standardisant la gestion des accès dans l'entreprise, en rendant possible la mise en œuvre d’un modèle de sécurité cohérent et en facilitant la collaboration entre organisations.

Enfin, les utilisateurs peuvent bénéficier d’une authentification unique et d’une capacité de collaboration transparente au sein et au-delà des frontières organisationnelles de l’entreprise.

7 Pour en savoir plus…

Pour de plus amples information sur la plateforme “Geneva” et ses technologies, nous vous invitons à consulter le site dédié à l’adresse http://www.microsoft.com/geneva.

Pour de plus amples informations sur l'interopérabilité technique des produits et technologies Microsoft avec des logiciels et matériels d'autres fournisseurs, nous vous invitons à consulter le site Microsoft Interopérabilité79. Vous retrouverez notamment l’annonce majeure80 que Microsoft a faite au mois de février 2008 dans le but d’améliorer l’ouverture de ses produits, d’offrir une meilleure interopérabilité et de créer des opportunités pour les développeurs, les partenaires, les clients et les concurrents.

Pour de plus amples informations sur les standards d'interopérabilité que Microsoft soutient ou auxquels Microsoft apporte sa collaboration, nous vous invitons à consulter le site Microsoft Standards81.

79

Site Microsoft Interopérabilité : http://www.microsoft.com/france/interop 80

Communiqué de presse M ICROSOFT MAKES STRATEGIC CHANGES IN TECHNOLOGY AND BUSINESS PRACTICES TO EXPAND

INTEROPERABILITY : 81

Site Microsoft Standards : http://www.microsoft.com/france/standards