Guide d'intégration de l'application IAM

Transcription

1 Guide d'intégration de l'application IAM Date 7/05/2012 Version 2.0

2 TABLE DES MATIÈRES 1 Perspective «Business» Objectifs de l'iam fédéral Le rôle du programme IAM de Fedict dans la fourniture de services d'authentification et de publication des attributs Perspective «Informations» Diagramme fonctionnel de couplage Catégories d'informations Attributs échangés Enseignements tirés : pièges Application : informations dans un couplage sans informations sur les rôles Perspective «Architecture» Aperçu des composantes en fonction de l'architecture de référence Application : Fedlet Intégration FAS dans une perspective «Architecture» Perspective «Technique» Support des scénarios d'intégration Migration des implémentations FAS1 standard vers le FAS+ via le Fedlet Aperçu de la configuration et de l'intégration de l'openam Fedlet Application : exemple de code et messages Annexe : liens utiles Spécifications Intégration du Fedlet Outils Kit d'intégration FAS

3 1 PERSPECTIVE «BUSINESS» 1.1 Objectifs de l'iam fédéral Dans le paysage actuel de l'e-government, diverses parties fournissent des services et des applications dans une administration informatisée. Comme illustré ci-dessous à la Figure 1, chacune d'entre elles est, dans son domaine, responsable de tâches similaires au niveau des services d'identification et d'authentification, du contrôle d'accès, des applications d'e-government offertes, des services de publication des attributs et privilèges, et de l'identity Management. Le système IAM de Fedict répond à cinq objectifs stratégiques dans ce cadre de l'e-government : Offrir aux utilisateurs un accès transparent aux applications et sources d'informations de l'administration (fédérale) belge, en tenant compte de leur caractère extrêmement hétérogène et distribué. Contrôler et réduire les risques d'accès illicite aux applications, et en garantir l'intégrité. Accroître l'efficience et l'efficacité opérationnelle de la gestion quotidienne des identités et des rôles. Mettre en place une architecture technique qui garantit un fonctionnement et une interopérabilité optimaux pour le système global, en tenant compte de l'autonomie des parties prenantes tant au plan technique qu'opérationnel. Mettre en place une structure de gouvernance qui garantit un fonctionnement et une interopérabilité optimaux pour le système global, en tenant compte de l'autonomie des parties prenantes tant au plan technique qu'opérationnel. Figure 1 : Paysage de l'e-government 3

4 Pour la mise à disposition/l'échange d'informations, les autorités sont tenues d'opérer via un environnement de gestion des accès (distribué) robuste. Cet environnement se compose de : services d'identification/authentification auxiliaires (par exemple, carte d'identité électronique, carte REAL, Stork, etc.) faisant en sorte que l'environnement de contrôle d'accès puisse identifier l'utilisateur de manière univoque ; services de contrôle d'accès (décision/administration) y afférents ou Policy Decision/Administration Points qui, sur la base de «rules», décident si un accès/échange peut avoir lieu ; services de contrôle d'accès (mise en application) effectifs ou Policy Enforcement Points qui assurent la surveillance de l'accès aux données/l'échange de données. L'environnement de contrôle d'accès précité doit pouvoir faire appel à des sources d'attributs/de rôles/de mandats (Policy Information Points) pour être en mesure d'évaluer si l'utilisateur satisfait aux règles d'accès en vigueur pour l'accès/l'échange. Un environnement de gestion des utilisateurs (distribué) robuste est nécessaire à cette fin. Celui-ci se compose de : sources authentiques (authentic sources) dans lesquelles se trouvent les données relatives aux identités et aux attributs/rôles/mandats ; services de publication/vérification permettant de demander les informations relatives aux identités et aux attributs/rôles/mandats ; services de gestion/d'enregistrement permettant de gérer les identités et les attributs/rôles/mandats (y compris la gestion des méta-informations, catalogue de rôles, etc.). 1.2 Le rôle du programme IAM de Fedict dans la fourniture de services d'authentification et de publication des attributs Le rôle de l'iam de Fedict dans le cadre de l'e-government se situe dans deux domaines. Un premier domaine est le plan stratégique, à savoir la conclusion d'accords appropriés au niveau des services et des interfaces ainsi qu'au niveau des modèles d'information utilisés (identités, rôles, mandats, etc.). Le deuxième domaine est le plan tactique/opérationnel, à savoir l'application de ces accords/normes/standards aux composantes que Fedict fournit pour offrir des services d'authentification et de publication des attributs. Fedict assure le développement et le soutien d'une stratégie commune, s'agissant de l'iam fédéral, par le biais de : Gouvernance au plan stratégique : IAM Framework (cf. besoins, encadrement, prioritisation) Gouvernance au plan tactique : IAM Enterprise Architecture, Information Model, etc. Gouvernance au plan opérationnel : IAM Service (Level) Management, Security, etc. En qualité de tiers de confiance (Trusted Third Party), le programme IAM de Fedict dispense des conseils en matière d'iam aux plans stratégique, tactique et opérationnel à d'autres services publics ou organisations ayant une fonction publique qui font appel à l'iam de Fedict : 4

5 Élaboration des normes concrètes, standards et architectures de base nécessaires pour réaliser des services IAM robustes et suivi de leur respect moyennant la validation des composantes fédérales au regard de l'iam Framework/IAM Enterprise Architecture fédéral(e). Accompagnement des services publics fédéraux dans l'implémentation de leurs composantes/services respectifs dans le cadre susmentionné (sous la forme d'une assistance architecturale ou d'une mise à disposition de composantes réutilisables et de services liés à l'iam). Élaboration de projets et services sous la forme de composantes réutilisables et de services liés à l'iam qui sont mis à la disposition des services publics fédéraux intéressés. Ce document vise surtout l'accompagnement des services publics fédéraux dans l'implémentation du couplage de leurs systèmes avec l'iam de Fedict, dans le contexte de laquelle, en tant que parties utilisatrices (Relying Parties), les services publics font appel à l'iam de Fedict en qualité de tiers de confiance (Trusted Third Party) pour constituer ainsi un cercle de confiance (Circle of Trust). Le Federal Authentication Service (FAS) constitue l'une des principales modalités de couplage avec le système IAM de Fedict. Les parties utilisatrices peuvent en faire usage pour identifier et authentifier les utilisateurs finaux. Le système fournit en outre des attributs et rôles pertinents qui permettent à la partie utilisatrice de prendre une décision d'autorisation avisée. 5

6 2 PERSPECTIVE «INFORMATIONS» Les parties prenantes au cercle de confiance doivent procéder à un échange d'informations pour réaliser la fédération d'identité. Ce chapitre offre un aperçu des différents types d'informations et de la manière dont l'iam de Fedict les traite. La première section de ce chapitre dresse un aperçu fonctionnel du SAML 2.0 HTTP Post binding et illustre la manière dont se déroule la communication entre l'utilisateur et les composantes principales, l'application et le FAS. Cette section sert d'exemple pratique à l'appui de la section suivante. La deuxième section offre un aperçu des différentes catégories d'informations et situe leur importance dans le couplage avec l'iam de Fedict. La dernière section, enfin, donne un aperçu des attributs qui sont échangés entre l'iam de Fedict et la partie utilisatrice et les pièges typiques que recèlent ces attributs. Relying Party 2.1 Diagramme fonctionnel de couplage FAS+ Fedlet Service Provider (Applicatie) 1 La Figure 2 présente un aperçu fonctionnel d'un SAML 2.0 HTTP Post binding entre un Service Provider et un Identity Provider (FAS) : 1) L'utilisateur demande une application. 2) Le Fedlet présent dans l'application dirige l'utilisateur vers l'écran d'identification du FAS chez Fedict. 3) L'utilisateur s'authentifie sur un écran de Fedict. 4) Le FAS redirige l'utilisateur vers l'application avec : Circle of Trust le résultat de la connexion ; des attributs à utiliser par l'application dès lors que la connexion est réussie. Figure 2 : Diagramme fonctionnel dans le cercle de confiance 2.2 Catégories d'informations En tant que partie utilisatrice, le client de Fedict fait confiance aux informations que l'iam de Fedict fournit sur les identités et leurs sessions. Les informations échangées se répartissent en quatre catégories : 1. Les informations personnelles permettent d'établir l'identité réelle de l'utilisateur et d'identifier celui-ci de manière univoque. Des exemples d'informations personnelles sont le prénom et le nom, le numéro de Registre national, les données de contact personnelles, etc. 2. Les informations de contact contiennent les données de contact et l'adresse liées au contexte professionnel de l'utilisateur. 3. Les informations d'identification externes contiennent une combinaison d'informations personnelles et de contact provenant d'une source externe comme la BCE, la BCSS, le Registre national, etc. 6

7 4. Les informations sur les privilèges décrivent les rôles avec leurs paramètres qui sont attribués à une identité. 5. Les méta-informations décrivent les propriétés de la session, des messages SAML proprement dits, etc. Ces catégories apparaissent en différents points du diagramme fonctionnel : Les méta-informations sont échangées aussi bien dans la demande que la réponse. Les informations de contact, les informations d'identification externes et les informations sur les privilèges ne peuvent être communiquées que par Fedict à la partie utilisatrice. Les informations personnelles peuvent être utilisées dans le cadre des demandes d'attributs (attribute queries) et servent donc aussi bien pour les demandes que pour les réponses. Dans certains cas, l'enregistrement est nécessaire ou l'iam de Fedict doit consulter une source externe pour pouvoir retourner des informations dans la réponse : Les informations personnelles se trouvent partiellement sur la carte d'identité électronique et peuvent être fournies sans enregistrement (NRN, nom, prénom). L'adresse personnelle ne figure pas sur la carte d'identité électronique et n'est disponible qu'après l'enregistrement dans l'iam de Fedict. Les informations de contact exigent dans tous les cas un enregistrement dans l'iam de Fedict : l'utilisateur doit exister au sein d'une organisation pour disposer par exemple d'une adresse e- mail professionnelle. Les informations d'identification externes réclament par définition une recherche par l'iam de Fedict. L'enregistrement n'est cependant pas nécessaire. Les informations sur les privilèges peuvent être retournées sur la base d'attributions de rôles explicites effectuées via la gestion des rôles dans l'iam de Fedict ou à partir de la consultation de sources externes au sein de la BCE, un représentant légal peut par exemple se voir attribuer implicitement un rôle déterminé pour un numéro BCE, sans que l'identité ne doive pour autant être enregistrée dans l'iam de Fedict. 2.3 Attributs échangés Cette section décrit les différents attributs qui peuvent être échangés via l'iam de Fedict. La colonne «Attribut» donne le nom de l'attribut et l'expression XPath de l'attribut dans la structure XML des messages SAML 2.0. La colonne «Description» fournit plus d'informations sur l'attribut et son utilisation possible. Les attributs ne peuvent pas être complétés autrement que sous la forme décrite ici. Il est par exemple impossible de fournir un code d'organisation dans un autre champ. Voir la section 2.5 ci-après pour un exemple d'une réponse SAML 2.0 dans laquelle apparaissent certains de ces attributs. 7

8 2.3.1 Informations personnelles Définies à l'étape 4) de la section Error! Reference source not found. ci-dessus. Attribut Code d'identité (/Response/Assertion/Subject/NameID) Description Code NameID qui est communiqué lors de l'authentification. Lors d'un couplage avec persistent NameID, il s'agit d'une valeur synchronisée entre l'environnement de la partie utilisatrice et de Fedict. Cette valeur synchronisée n'est pas le UserID dans l'iam de Fedict (attribut egovuserid) ou l'application de la partie utilisatrice, mais un identifiant qui est échangé entre Fedict et la partie utilisatrice et qui peut établir l'identité des deux côtés. Nom d'utilisateur (/Response/Assertion/AttributeStatement/A /AttributeValue) Numéro de Registre national (/Response/Assertion/AttributeStatement/A /AttributeValue) Prénoms (/Response/Assertion/AttributeStatement/A /AttributeValue) Nom de famille (/Response/Assertion/AttributeStatement/A /AttributeValue) Lors d'un couplage avec un transient NameID, il s'agit d'une valeur variable. Nom d'utilisateur sous lequel l'utilisateur est enregistré dans l'iam de Fedict. Dans le cas d'un couplage avec persistent Identity, ce n'est pas le NameID, mais le UserID spécifique avec lequel une personne peut se connecter avec nom d'utilisateur/mot de passe dans l'iam de Fedict. Numéro de Registre national dans l'iam de Fedict. Au moment de l'enregistrement, il est contrôlé à l'aide de la source authentique. Cet attribut peut être fourni directement à partir de la carte d'identité électronique en cas de connexion avec une carte eid. Les prénoms de l'identité. Cet attribut peut être fourni directement à partir de la carte d'identité électronique en cas de connexion avec une carte eid. Le nom de famille de l'identité. Cet attribut peut être fourni directement à partir de la carte d'identité électronique en cas de connexion avec une carte eid. 8

9 Adresse personnelle (/Response/Assertion/AttributeStatement/A /AttributeValue) Langue préférentielle (/Response/Assertion/AttributeStatement/A /AttributeValue) L'adresse personnelle qui a été enregistrée dans l'iam de Fedict pour l'identité (! = adresse e- mail professionnelle). Langue dans laquelle l'utilisateur souhaite travailler Informations de contact Définies à l'étape 4) de la section Error! Reference source not found. ci-dessus. Une identité enregistrée est toujours nécessaire pour pouvoir retourner des informations de contact, voir section Error! Reference source not found.. Attribut Agence (/Response/Assertion/AttributeStatement/A ttribute/@name="egovagency" /AttributeValue) Département (/Response/Assertion/AttributeStatement/A ttribute/@name="egovdepartment" /AttributeValue) Adresse professionnelle (/Response/Assertion/AttributeStatement/A ttribute/@name="egovprof " /AttributeValue) Numéro de téléphone professionnel (/Response/Assertion/AttributeStatement/A ttribute/@name="egovphone" /AttributeValue) Statut (/Response/Assertion/AttributeStatement/A ttribute/@name="egovcsstatute" /AttributeValue) Titre (/Response/Assertion/AttributeStatement/A Description L'agence dans laquelle travaille un fonctionnaire. Uniquement d'application pour les fonctionnaires. Le département de l'agence dans lequel travaille un fonctionnaire. Uniquement d'application pour les fonctionnaires. L'adresse professionnelle de l'identité en sa qualité au sein d'une agence et d'un département de celle-ci. Le numéro de téléphone professionnel de l'identité en sa qualité au sein d'une agence et d'un département de celle-ci. Le statut de fonctionnaire de l'identité, TRUE ou FALSE avec TRUE=identité connue en tant que fonctionnaire dans l'iam de Fedict. Le titre professionnel de l'identité en sa qualité au sein de l'agence et du département. 9

10 /AttributeValue) Informations d'identification externes Définies à l'étape 4) de la section Error! Reference source not found. ci-dessus. Une recherche dans une source authentique est toujours nécessaire pour pouvoir retourner des informations d'identification externes, voir section Error! Reference source not found.. Attribut État civil (/Response/Assertion/AttributeStatement/A tevalue) Sexe (/Response/Assertion/AttributeStatement/A /AttributeValue) Description L'état civil de l'identité. Cet attribut est lu dans le Registre national. Le sexe de l'identité. Cet attribut est lu dans le Registre national Informations sur les privilèges Définies à l'étape 4) de la section Error! Reference source not found. ci-dessus. Une identité enregistrée avec attribution de rôle explicite ou une recherche dans des sources authentiques avec attributions de rôles implicites est toujours nécessaire pour pouvoir retourner des informations sur les privilèges, voir section Error! Reference source not found.. Attribut Rôle attribué (/Response/Assertion/AttributeStatement/ Attribute/Name=<appCode>/AttributeValue) RoleParameter (/Response/Assertion/AttributeStatement/ Description Le nom du rôle attribué, composé d'un code pour l'application et le rôle. Le nom de l'attribut peut varier selon l'application dans les exemples de ce guide, l'attribut est appelé «roles». Un ou plusieurs paramètres associés à l'attribution de rôle. Peut par exemple contenir la portée du rôle : la partie de l'organisation pour laquelle l'attribution de rôle est d'application. 10

11 2.3.5 Méta-informations Méta-informations dans la demande d'authentification Définies à l'étape 2) de la section Error! Reference source not found. ci-dessus. Attribut Méthode d'authentification demandée (/AuthnRequest/RequestedAuthnContext/ AuthContextClassRef) Description Indication du moyen d'authentification demandé. Cela permet aux applications d'offrir des fonctionnalités en fonction du moyen d'authentification utilisé, par exemple droits de lecture avec utilisation d'un token citoyen et droits d'écriture uniquement si authentification par carte d'identité électronique. Comparaison authentification Il est possible que des AuthContextClasses spécifiques soient nécessaires pour l'application, voir plus loin, section 2.4 Enseignements tirés : pièges. Valeurs autorisées : exacte ou minimum. Moyen d'authentification demandé de manière «exacte» ou «au minimum». Fedict a établi une hiérarchie dans les moyens d'authentification par exemple, la carte d'identité électronique est plus forte que le token citoyen et le token citoyen est plus fort que la combinaison nom d'utilisateur/mot de passe. Renouvellement authentification exigé? (/AuthnRequest/@ForceAuthn) Si par exemple, le token citoyen est demandé au minimum par l'application, une carte d'identité électronique conduira également à une authentification réussie. En revanche, ce ne sera pas le cas si le token citoyen est demandé de manière exacte. Un Service Provider peut demander l'exécution d'une nouvelle authentification pour chaque utilisateur, même si cet utilisateur a déjà une session active avec un moyen d'authentification suffisamment fort sur le FAS+. 11

12 Type d'identification des utilisateurs Cet attribut contrôle donc le comportement Single Sign On du FAS+ sur différents Service Providers au sein du cercle de confiance avec Fedict. Valeurs autorisées : (/AuthnRequest/NameIDPolicy/@Format) urn:oasis:names:tc:saml:2.0:nameidformat:transient urn:oasis:names:tc:saml:2.0:nameidformat:persistent Code de la demande d'authentification (/AuthnRequest/@ID) Provenant du Service Provider (/AuthnRequest/Issuer) Spécifie si des transient NameID ou des persistent NameID doivent être utilisés dans le couplage. Voir plus loin, section 2.4 Enseignements tirés : pièges. Identification unique de la demande d'authentification. L'identifiant unique du Service Provider dans le système IAM de Fedict Méta-informations dans la réponse d'authentification Définies à l'étape 4) de la section Error! Reference source not found. ci-dessus. Attribut Méthode d'authentification (/Response/Assertion/AttributeStatement/ Attribute/@Name=<appCodeScopeCode>/ AttributeValue) Résultat de l'authentification (/Response/Status/StatusCode/@Value) Temps écoulé depuis le début de la session (/Response/AuthnStatement/@AuthnInstant) Service Provider cible (/Response/Conditions/AudienceRestriction /Audience) Description Indication du moyen d'authentification utilisé. Cela permet aux applications d'offrir des fonctionnalités en fonction du moyen d'authentification utilisé, par exemple droits de lecture avec utilisation d'un token citoyen et droits d'écriture uniquement si authentification par carte d'identité électronique. Le résultat de l'identification. En cas d'échec de l'authentification, Fedict adressera aussi une réponse à la partie utilisatrice. Moment de l'authentification. Détermine pour quel Service Provider (= partie utilisatrice) la réponse est valable. 12

13 Référence au code de la demande d'authentification (/Response/Subject/SubjectConfirmation/ SessionID Indication de la demande d'authentification de la partie utilisatrice à laquelle Fedict réagit. Cet attribut évite qu'une réponse de Fedict ne soit réutilisée, potentiellement sans une demande d'authentification valable de la partie utilisatrice. L'identifiant unique de la session utilisateur dans le système IAM de Fedict. 2.4 Enseignements tirés : pièges Méthode d'authentification Le Service Provider doit demander une méthode d'authentification spécifique dans la demande d'authentification SAML 2.0 via un attribut AuthenticationContext SAML 2.0. Dans certains cas, par exemple l'utilisation de rôles ou des recherches spécifiques dans des sources authentiques ou fiables, on déroge à l'authenticationcontext standard. Il importe dans tous les cas que le Service Provider demande l'urn correct de l'authenticationcontext correct auprès du FAS+ IdP, au risque de ne pas recevoir les attributs, rôles ou méthode d'authentification exacts, ou même que certaines méthodes d'authentification ne soient pas proposées comme écran d'identification. La méthode d'authentification peut être complétée en précisant le moyen d'authentification demandé de manière exacte ou au minimum Persistent et transient NameID Afin d'éviter des problèmes avec les autorisations de la Commission de la protection de la vie privée, il est possible de ne pas faire retourner d'attributs sensibles concernant les identités par l'iam de Fedict. Dans certains cas, il suffit, au sein d'une application, d'accorder un accès utilisateur à celle-ci sur la base d'un transient NameID et d'un rôle. Fedict envisage à l'avenir un service qui assurera un audit trail. Ce service permettra, dans les situations qui le justifient, d'associer alors le transient ID avec une identité, sans que le Service Provider ne reçoive pour autant des informations sensibles au niveau de la vie privée. Pour le moment, Fedict n'offre pas encore ce service. Dans certains cas, il existe des comptes d'utilisateurs locaux qui peuvent être enrichis dans l'identity Store du Service Provider avec un Persistent Identifier généré par Fedict. Lors de l'authentification, l'iam de Fedict peut alors retourner le Persistent Identifier, sur la base duquel l'utilisateur peut être identifié localement chez le Service Provider. Ce faisant, de nouveau, Fedict ne retourne pas d'informations sensibles, ce qui facilite le processus d'autorisation. 13

14 2.4.3 Structure des informations sur les privilèges L'IAM de Fedict retourne des informations sur les privilèges sous deux formes différentes : au format string et au format HTML encoded XML. Dans les deux cas, les informations sont contenues dans les attributs «informations sur les privilèges» du message SAML. Les formats string sont convenus avec chaque Service Provider consommateur. Les champs de données sont séparés les uns des autres par des signes typographiques comme ':', '_', ',', etc., la forme la plus utilisée étant : <application>_<rôle>:<orgcode1>,<orgcode2> <application>_<rôle2>:<orgcode3>,<orgcode4> Le format XML suit un schéma pour transmettre ces informations sur les rôles avec comme attribut fixe le «role name» et, le cas échéant, un ou plusieurs paramètres, par exemple : <rôle:roleresult xmlns:rôle=" <rôle:role name="<application_rôle>" xmlns:rôle=" <rôle:roleattribute name="companyid"> </rôle:roleattribute> <rôle:roleattribute name="fedictdomain">somedomain</rôle:roleattribute> </rôle:role> </rôle:roleresult> 2.5 Application : informations dans un couplage sans informations sur les rôles Dans le scénario le plus simple, le Service Provider demande une AuthenticationClass déterminée pour la session d'un utilisateur et le FAS+ retourne au Service Provider un certain nombre d'attributs d'identité et pas d'informations sur les privilèges. Une demande typique se présente comme suit, avec les attributs principaux du point de vue informations indiqués en gras : ForceAuthn, Issuer, NameIDPolicy et RequestedAuthnContext. <samlp:authnrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="s f77b ef3c1c3ad7038ec635ab9a" Version="2.0" IssueInstant=" T19:00:14Z" Destination=" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL=" <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">fedlettest1</saml:issuer> <ds:signature xmlns:ds=" <! - signature informations removed of readability --> </ds:signature> <samlp:nameidpolicy xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="FedletTest1" AllowCreate="true"></samlp:NameIDPolicy> <samlp:requestedauthncontext xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Comparison="minimum"> 14

15 <saml:authncontextclassref xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">urn:be:fedict:citizentoken</saml:authnconte xtclassref> </samlp:requestedauthncontext> </samlp:authnrequest> Une réponse typique se présente comme suit, avec pour principaux attributs : la combinaison Destination, ID et InResponseTo empêche les replay attacks et l'utilisation abusive de réponses interceptées ; le StatusCode ; l'authncontext ; le contenu de l'attribute statement (toutes les informations contenues dans les tags <saml:attributestatement>, pas en couleur). <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained" Destination=" :443/fedlet/fedletapplication" ID="idEgYuquDWiDQypa6K1U0JaSk-x8s" InResponseTo="s f77b ef3c1c3ad7038ec635ab9a" IssueInstant=" T19:00:15Z" Version="2.0"> <saml:issuer> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:assertion ID="id75HGuPQ5xcAnd13bQfs8Paheako" IssueInstant=" T08:03:38Z" Version="2.0"> <saml:issuer> <ds:signature xmlns:ds=" <! Signature informations removed for readability --> </ds:signature> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier=" SPNameQualifier="FedletTest1">zrStwEUD9k/MBXAmWwFwLVMIfSBVD3slYgdALw==</saml :NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata InResponseTo="s f77b ef3c1c3ad7038ec635ab9a" NotOnOrAfter=" T9:02:15Z" Recipient="FedletTest1"/> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore=" T08:58:38Z" NotOnOrAfter=" T09:08:38Z"> <saml:audiencerestriction> <saml:audience>fedlettest1</saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant=" T09:00:15Z" SessionIndex="id75HGuPQ5xcAnd13bQfs8Paheako"> <saml:authncontext> 15

16 <saml:authncontextclassref> urn:be:fedict:eid</saml:authncontextclassref> <saml:authncontextdeclref>urn:be:fedict:eid</saml:authncontextdeclref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd :string">lenaerts</saml:attributevalue> </saml:attribute> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="egovNRN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd:string"> </saml:attributevalue> </saml:attribute> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd:string">pieter Andreas</saml:AttributeValue> </saml:attribute> </saml:attributestatement> </saml:assertion> </samlp:response> 16

17 3 PERSPECTIVE «ARCHITECTURE» Ce chapitre entend donner un aperçu conceptuel des différentes composantes abstraites qui accomplissent une tâche dans le scénario fédératif qui associe une application et le Federal Authentication Service (FAS), et ce de manière à permettre l'adoption d'une terminologie commune pour les composantes concernées dans les couplages avec le FAS. Un cadre conceptuel clair/cohérent est nécessaire pour ce qui est des services (et surtout les implémentations spécifiques et l'interopérabilité de ces services). Cela signifie que si des concepts «simples» comme Policy Enforcement Points, Policy Decision Points, Policy Administration Points, Policy Information Points (IdP) sont utilisés de manière générale, il faut aussi que toutes les parties soient conscientes que lesdits concepts recouvrent un contenu technologique tout autre auprès des différents acteurs. Il importe donc que les intéressés se rendent compte qu'une IAM Enterprise Architecture faîtière doit exister et qu'il y a lieu de convenir d'interfaces interopérables appropriées. La première section opère une différenciation entre les composantes abstraites de l'architecture de sécurité de l'application et les composantes de l'architecture fédérative qui permet l'intégration entre l'application et le FAS. Cette section fait le lien entre les composantes abstraites et le diagramme fonctionnel vu précédemment et précise pas à pas quelle composante assume quelle tâche. La deuxième section reprend le diagramme fonctionnel de la première section et illustre les rôles des différentes composantes à partir de l'architecture de référence de l'iam de Fedict. 3.1 Aperçu des composantes en fonction de l'architecture de référence La Figure 3 ci-dessous montre quelles composantes abstraites opèrent dans et avec l'iam de Fedict. Les colonnes verticales indiquent les domaines principaux dans lesquels ces composantes opèrent, alors qu'horizontalement, on retrouve le niveau auquel elles jouent un rôle : logique business, échange d'informations ou stockage de données. Les composantes assorties d'un cadre coloré sont importantes dans le contexte de l'authentification via la fédération avec l'iam de Fedict. Les composantes pourvues d'un cadre orange sont gérées par Fedict. Les composantes encadrées en vert sont gérées par le client de Fedict. Les sous-sections suivantes clarifient le rôle général de ces composantes et l'illustrent aussi par ordre d'apparition dans le diagramme fonctionnel de la section Error! Reference source not found. ci-dessus. À la fin de cette section, la Figure 4 montre les flux d'informations entre l'utilisateur final, les différentes composantes au sein d'une organisation et entre les composantes que les organisations intègrent. 17

18 Component bij Klant Component bij Fedict Figure 3 : Architecture de référence Fedict Access Control Policy Enforcement Point Le Policy Enforcement Point (PEP) est une composante d'une application qui contrôle l'accès à l'application. De manière caractéristique, le PEP se trouve à deux endroits dans l'architecture applicative. D'une part, pour un contrôle d'accès global, un PEP sera prévu en amont de l'application web ou très tôt dans la logique qui contrôle les informations échangées durant les sessions pour donner ainsi accès ou non à une page. Concrètement, on peut utiliser à cet effet un filtre web ou un filtre d'interception, etc. D'autre part, un PEP se retrouve aussi dans la logique business où un contrôle d'accès fin a lieu au niveau des business transactions. Lorsqu'un utilisateur contacte une application web, le PEP de l'application intercepte la demande du navigateur et pose une question stratégique au Policy Decision Point. Pendant la présentation des pages et le traitement des transactions, la couche logique business posera également des questions stratégiques au Policy Decision Point. Cela se passe à l'étape 2) du diagramme fonctionnel présenté dans la section Error! Reference source not found.. Au plan conceptuel, le PEP ne prendra aucune décision quant à savoir si une demande d'accès peut ou non être exécutée. Le PEP transmet sa question au Policy Decision Point. Souvent, le PEP et le PDP se retrouvent ensemble dans une instruction conditionnelle de la logique applicative. Dans ce cas, le PEP et le PDP ne sont pas des modules logiques distincts, mais les fonctions d'un PEP et d'un PDP sont néanmoins dûment remplies. 18

19 3.1.2 Access Control Policy Decision Point Le Policy Decision Point (PDP) est une composante qui prend des décisions, s'agissant de la mise à disposition ou non de fonctionnalités, sur la base des informations concernant un utilisateur (par exemple, informations sur les privilèges, informations personnelles comme l'âge, etc.). Cette composante peut occuper une position centrale ou faire partie de la couche logique business d'une application. En concevant le PDP comme une composante logique distincte, les demandes d'autorisation peuvent par exemple être transmises à un serveur d'autorisation central qui répond centralement aux demandes de différentes applications et donc uniformément pour toute l'organisation. Le PDP base la décision sur des informations concernant l'utilisateur qui proviennent d'un Policy Information Point. Lorsque le PEP a formulé une question relative à l'octroi d'accès à une page ou transaction à la session d'un utilisateur, le PDP demande des informations sur la session au PIP Access Control Policy Information Point Le Policy Information Point (PIP) 1 est une composante d'un PDP central ou du PDP intégré à l'application qui retourne au PDP des informations concernant un utilisateur. Le Fedlet remplit ce rôle en demandant des informations sur la session et des informations sur les privilèges auprès de l'identity Provider de Fedict, le FAS Federation Service Provider Un Federation Service Provider (SP) est, dans un contexte fédératif, une composante qui fournit un service à un consommateur et s'en remet pour cela à des informations concernant ledit consommateur qui proviennent de tiers de confiance (Trusted Third Parties). Le SP obtient les informations via une demande d'authentification adressée au FAS (Identity Provider, IdP) dans un contexte fédératif. Il s'ensuit que le Fedlet fonctionne, d'une part, comme PIP dans l'architecture applicative de sécurité et, d'autre part, comme Service Provider dans l'architecture fédérative. La transmission de la demande d'authentification du SP vers l'idp correspond à l'étape 2) de la section Error! Reference source not found.. 1 Cette composante n'est pas illustrée dans la Error! Reference source not found., mais se situe sur la couche Information d'access Control & Identification. 19

20 3.1.5 Federation Identity Provider Le Federation Identity Provider fournit des informations concernant des identités à des parties qui font confiance (relying) à la réponse de l'idp. L'IdP forme ainsi un cercle de confiance (Circle of Trust) avec les parties utilisatrices (Relying Parties), dont les Federation Service Providers de la section Les informations communiquées peuvent être de différentes natures : Informations personnelles permettent d'établir l'identité de l'utilisateur, par exemple le numéro de Registre national. Informations de contact contiennent des informations de contact comme l'adresse ou la langue préférentielle. Informations sur les privilèges contiennent des informations sur les rôles attribués à l'utilisateur. L'IdP reçoit une demande d'une partie utilisatrice à l'étape 2) de la section Error! Reference source not found., mais il lui faut encore établir l'identité de l'utilisateur. Cette identification aura lieu moyennant la présentation à l'utilisateur d'un Access Control Identity Verification Point Access Control Identity Verification Point L'Access Control Identity Verification Point (IVP) a pour but d'établir l'identité d'un utilisateur. Dans le FAS, cela se fait à la demande de l'idp au niveau des écrans d'identification de Fedict, où l'utilisateur peut choisir parmi différents moyens d'authentification. L'IVP se base sur les informations justificatives d'identités qui sont stockées dans l'identity Identification Storage Point et retourne le résultat de l'identification à l'idp Identity Identification Storage Point L'Identity Identification Storage Point (ISP) est un magasin de données qui contient des informations justificatives, personnelles et de contact sur l'identité. L'ISP est sollicité par l'idp pour la communication d'attributs et par l'ivp pour la vérification de l'identité Identity Privilege Storage Point L'Identity Privilege Storage Point (PSP) est un magasin de données qui contient les informations sur les privilèges pour une identité : attributions de rôles et tous les paramètres et métadonnées de ces attributions comme les dates de validité, valeurs de paramètres, etc. Le PSP est sollicité par l'idp pour la communication d'informations sur les privilèges d'une identité. 20

21 3.2 Application : Fedlet Intégration FAS dans une perspective «Architecture» La Figure 4 ci-dessous illustre les différentes composantes abstraites de l'architecture de référence de l'iam de Fedict. Les flèches indiquent quelle composante en contacte une autre pour obtenir des informations. On remarquera qu'une composante technique peut remplir plusieurs rôles : - Dans le scénario d'intégration d'un couplage Fedlet avec le FAS, le Fedlet remplit le rôle d'access Control Policy Information Point et de Federation Service Provider. - Le Fedict edirectory fait à la fois office d'identity Identification Storage Point et d'identity Privilege Information Point. Lorsqu'on suit les différentes étapes de la section Error! Reference source not found., on rencontre les composantes de l'architecture de référence suivantes : L'utilisateur contacte l'application et est intercepté par la logique de l'application qui contrôle les sessions, sous la forme d'un PEP intervenant au niveau global pour protéger l'accès à des parties de l'application. Le PEP interroge le PDP en vue d'accorder l'accès à l'utilisateur, mais il n'y a pas encore d'informations sur l'identité de l'utilisateur ou son/ses privilèges. Le PDP contacte donc le PIP pour extraire les informations concernant l'utilisateur. L'application est associée à Fedict dans un cercle de confiance fédératif (Federation Circle of Trust) et compte sur Fedict pour l'obtention d'informations sur les utilisateurs et leurs privilèges. Le PIP contacte donc un Federation Service Provider afin que celui-ci adresse une demande d'authentification au Federation Identity Provider. L'IdP constate qu'aucune information n'est encore connue sur la session de l'utilisateur, et doit donc identifier l'utilisateur. C'est pourquoi celui-ci est aiguillé vers un Identity Verification Point où son identité est établie sur la base des informations contenues dans un Identity Identification Storage Point. Les informations sur les privilèges sont quant à elles extraites d'un Identity Privilege Storage Point, de sorte que l'idp peut ensuite retourner les informations d'identification et les informations sur les privilèges de l'utilisateur vers le Service Provider dans une réponse d'authentification. Ce Service Provider reçoit la réponse d'authentification et transmet les informations d'identification et les informations sur les privilèges au Privilege Information Point. Le PIP est maintenant à même de communiquer les informations au Policy Decision Point, qui peut décider si l'utilisateur pourra accéder à une logique déterminée. L'approbation ou le refus par le PDP est communiqué au Policy Enforcement Point, qui permet la présentation effective du contenu. 21

22 Figure 4 : Composantes de référence dans le couplage Fedlet 22

23 4 PERSPECTIVE «TECHNIQUE» Ce chapitre entend donner un aperçu de trois scénarios d'implémentation technique et proposer une introduction en vue, d'une part, de configurer une solution standard librement disponible, l'openam Fedlet, en tant que Federation Service Provider dans un cercle de confiance avec l'iam de Fedict et, d'autre part, d'intégrer le Fedlet en tant que Policy Information Point pour une application web. Pour simplifier l'intégration avec le FAS+, un kit d'intégration a été développé. Ce kit d'intégration est décrit de manière détaillée à l'annexe Error! Reference source not found Support des scénarios d'intégration Trois stratégies d'implémentation importantes peuvent être utilisées pour réaliser un couplage axé sur des services d'authentification et de publication des attributs avec l'iam de Fedict. Chacune de ces stratégies comporte bien entendu des avantages et des inconvénients, surtout en termes de complexité de l'implémentation et de coût. La stratégie d'intégration la mieux soutenue est le déploiement d'une solution fédérative supportée par le fournisseur comme, notamment, ForgeRock OpenAM, Novell Access Manager, Oracle Identity Federation ou encore Microsoft ADFS 2.0. Ces produits lèvent pour une bonne part la complexité d'un scénario fédératif. Le rôle de Fedict se limite ici à soutenir la mise à disposition du cadre architectural tel que décrit ci-dessus et un support peut également être offert par le fournisseur en question. La deuxième stratégie d'intégration utilise le Fedlet, une partie du code OpenAM. Il est ici question de l'implémentation facile à réaliser, en source libre et légère d'un Federation Service Provider. Celui-ci peut être intégré avec une application web en vue de mettre celle-ci à disposition via la fédération. Dans cette stratégie, Fedict offre le présent document en guise d'aide à la configuration technique mais il incombe aux clients de Fedict de prévoir le savoir-faire requis pour l'intégration du code Fedlet avec l'application web. Il est également possible d'utiliser un Fedlet adapté. Ce kit d'intégration contient déjà quelques éléments qui sont spécifiques au système de Fedict. La dernière stratégie d'intégration est l'implémentation entièrement personnalisée d'un Federation Service Provider, à partir ou non de bibliothèques comme OpenSAML. Fedict ne peut apporter aucun support dans ce cadre. 4.2 Migration des implémentations FAS1 standard vers le FAS+ via le Fedlet Le Fedlet peut remplacer entièrement l'implémentation SAML1 que Fedict a déployée pour le FAS1 chez certains clients. Cette implémentation SAML1 a produit une page consommateur SAML1 sur laquelle pouvait se greffer une application. La stratégie d'intégration pour un Fedlet s'inscrit dans le droit fil de ce qui précède : le FAS+ appelle une page consommateur SAML2 sur laquelle vient se greffer la logique applicative du client de Fedict en vue de prendre des décisions stratégiques sur la base des informations interprétées issues de la réponse SAML2. Outre l'utilisation d'un nouveau standard (SAML2), il existe aussi quelques autres différences entre le FAS1 et le FAS+. La section suivante (4.2.1) aborde les principales d'entre elles. 23

24 4.2.1 Différences techniques entre le FAS1 et le FAS Mapping des attributs La dénomination des attributs, que le FAS1 retourne, a été modifiée dans le FAS+. Le FAS+ retourne les attributs sous un autre nom. Il y a lieu d'en tenir compte si ces informations sont nécessaires dans l'application. Le tableau (Tableau 1) précise les différences d'appellations. Nom attribut FAS1 egovuserid SurName FirstName NRN Language AgencyCode AgencyName DepartmentCode DepartmentName Prof Statute Title Category Nom attribut FAS+ uid surname givenname egovnrn PrefLanguage egovagency AgencyName egovdepartment DepartmentName egovprof egovcsstatute egovworktitle Category Tableau 1 : Mapping des attributs On observera que si l'on utilise le kit d'intégration, le mapping des attributs s'opère automatiquement. Les utilisateurs du kit d'intégration conserveront donc la dénomination propre au FAS Moyens d'authentification Le FAS+ propose les moyens d'authentification suivants : carte d'identité électronique et token citoyen. L'authentification à partir du nom d'utilisateur et d'un mot de passe ou d'un token fonctionnaire n'est plus possible que pour les clients qui migrent à partir du FAS1 (et qui y avaient aussi ces moyens d'authentification) ou après approbation explicite de Fedict. Une demande en ce sens peut être introduite via le Service Desk de Fedict Écran d'identification L'écran d'identification FAS+ (Figure 5) a été amélioré et permet désormais d'introduire directement le nom d'utilisateur et le mot de passe. Il contient aussi des informations supplémentaires et des renvois pertinents vers d'autres pages. Le cas échéant, le rectangle rouge de la Figure 5 et de la Figure 6 peut contenir le logo du client. Si un logo était configuré dans le FAS1, il sera automatiquement repris dans le FAS+. 24

25 Figure 5 : Écran d'identification FAS+ Figure 6 : Écran d'identification FAS Single Log Out Le FAS+ supporte également le Single Log Out (SLO). Le client peut adresser une demande de SLO (SLO Request) au FAS+. Le FAS+ terminera alors la session engagée avec l'utilisateur. Des certificats doivent être utilisés à cet effet Configuration Le cas échéant, Fedict peut fournir à ses clients un Fedlet préconfiguré. Fedict complète les métadonnées et informations de certification du FAS+ IdP et du Service Provider du client sur la base des informations collectées lors de la procédure d'accueil. Fedict fournit alors les fichiers de configuration Fedlet. Dans ce cas, le client n'a plus qu'à réaliser l'intégration dans les sections suivantes et à configurer le serveur d'applications. On peut également utiliser le kit d'intégration FAS+. Celui-ci est décrit en détail à l'annexe Error! Reference source not found.. Dans ce cas aussi, les fichiers de configuration fournis devront être copiés. 25

26 4.3 Aperçu de la configuration et de l'intégration de l'openam Fedlet Le but n'est pas dans ce document de décrire une documentation complète du Fedlet, mais uniquement d'évoquer les grandes lignes et de donner quelques exemples. L'OpenAM Fedlet est une implémentation légère d'un Service Provider dans le contexte d'une fédération d'identité. Le Fedlet peut être intégré dans une application web pour exécuter un contrôle d'accès via une fédération avec un Identity Provider. Historiquement, le Fedlet est issu du source tree de Sun OpenSSO. OpenAM est dérivé du code OpenSSO depuis début Téléchargement du Fedlet Le Fedlet est disponible par le canal de distribution d'openam. Le code OpenAM complet peut être téléchargé à partir de Le fichier de téléchargement d'openam contient un sous-répertoire «Fedlet». Celui-ci comporte le code pour conteneurs web ASP.NET ou Java. Le présent Guide d'intégration se concentre sur le déploiement de Java Prérequis Conteneur de servlets Java Un conteneur de servlets Java doit être configuré pour la communication avec Fedict : une clé privée pour trafic https doit être chargée dans un trust store. Le certificat doit être enregistré pour le SP dans l'idp de Fedict et doit donc être communiqué à Fedict et être chargé correctement par Fedict dans l'idp Accès au FedMAN L'environnement de test et d'acceptation de Fedict n'est pas accessible au public, mais uniquement via le FedMAN. Un accès du SP au FedMAN est dès lors nécessaire Déploiement et configuration du Fedlet Le Fedlet est livré sous la forme d'un fichier WAR qui prévoit un certain nombre de fonctionnalités de base et offre des pages de test. À des fins de test, l'installation du Fedlet peut se limiter au déploiement de l'archive d'application web dans le conteneur de servlets Java pour Tomcat, par exemple, fedlet.war doit être placé dans le répertoire «webapps». Ensuite, le Fedlet est accessible sur par exemple 26

27 Le déploiement tel qu'il est décrit dans cette section permet seulement de tester le couplage d'un SAML 2.0 avec un IdP et en soi, il ne fournit aucune intégration avec une application. Pour cela, voir plus loin la section Intégration du Intégration du Fedlet dans une application. Les directives de configuration restent toutefois les mêmes lors d'une intégration dans une application existante. Fedict propose pour les environnements Java de mettre à la disposition de ses clients un Fedlet aussi largement configuré que possible. La configuration peut être entièrement préparée sur la base du document de la procédure d'accueil, indépendamment de la localisation du Keystore Java et du répertoire dédié que le Fedlet doit utiliser Répertoire dédié Fedlet Le Fedlet attend les métadonnées SP et IdP dans un même répertoire. Celui-ci doit être signalé vers Tomcat via la variable d'environnement JAVA_OPTS. L'option suivante doit être retenue dans JAVA_OPTS : -Dcom.sun.identity.Fedlet.home=<chemin_vers_répertoire_dédié_Fedlet> Adaptation des métadonnées et des modèles Circle of Trust Pour chacun des fichiers de métadonnées sp*.xml et idp*.xml, un modèle est fourni avec la distribution de l'openam Fedlet. Ces modèles contiennent des paramètres fictifs qui doivent chaque fois être remplacés par une valeur réelle spécifique pour la configuration. Les paramètres fictifs suivants doivent être remplacés dans les fichiers : Nom du fichier Fedlet.cot idp.xml idp-extended.xml sp.xml sp-extended.xml FederationConfig.properties Description Définition du Circle of Trust entre IdP et Fedlet Descripteur d'entité, certificats, URL et services de l'idp Config. d'entité, références vers COT par domaine fédératif Descripteur d'entité, URL et services du SP Config. d'entité, exigences concernant signature, mapping des attributs, etc. Configuration du Fedlet proprement dit On remarquera que dans le cadre d'une procédure d'accueil Fedict, le SP entityid doit être complété avec l'url de l'application Chargement des métadonnées SP dans l'idp de Fedict Le SP doit être enregistré dans l'idp de Fedict. Le fichier sp.xml doit dès lors être envoyé à Fedict de sorte qu'il puisse être chargé dans l'environnement de test et d'acceptation. On remarquera que le chargement des métadonnées SP ne peut se faire que dans le cadre de l'accueil d'une application dans l'iam de Fedict. Cette procédure d'accueil peut être initiée via le Service Desk de Fedict. 27

28 Si l'on effectue des tests en dehors d'une procédure d'accueil, un IdP doit alors être créé localement Test du Fedlet Avec un navigateur web, allez vers l'uri de déploiement du Fedlet. Si les métadonnées SP ont été correctement communiquées à Fedict et ont bien été chargées dans l'idp, le lien Browser Initiated HTTP Post binding devrait mener vers l'écran d'identification (IVP) de Fedict. Après authentification, les données retournées dans la réponse SAML 2.0 de l'idp de Fedict s'affichent Intégration du Fedlet dans une application L'intégration du Fedlet dans une application web Java existante est réalisée en décompressant les fichiers de fedlet.war et en les joignant aux fichiers d'application existants. Ensuite, la localisation des end points doit être fixée dans sp.xml pour les différents services et bindings et ces emplacements doivent contenir la logique nécessaire pour exploiter les informations contenues dans les réponses de l'idp Fusion du code Les contenu intégral de fedlet.war doit d'abord être décompressé dans un emplacement temporaire. Les fichiers suivants doivent être adaptés ou supprimés : 1. index.jsp index.jsp contient l'écran d'accueil pour la fonctionnalité de test du Fedlet. Les liens contenus dans le fichier index.jsp originel donnent un exemple de la manière dont les JSP SSO doivent être accédées. Le fichier index.jsp originel ne doit pas être ajouté dans l'application existante. 2. fedletsampleapp.jsp fedletsampleapp.jsp contient des exemples de la manière dont une réponse doit être traitée. fedletsampleapp.jsp ne doit pas être ajouté en l'état dans l'application existante, mais il y a lieu de l'adapter de manière à appeler la logique applicative nécessaire. 3. web.xml et sp.xml 28