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



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

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

Formation SSO / Fédération

ASIP Santé DST des interfaces MSSanté des Clients de messagerie v /02/ / 95

Direction de la Sécurité Sociale

Processus 2D-Doc. Version : 1.1 Date : 16/11/2012 Pôle Convergence AGENCE NATIONALE DES TITRES SECURISÉS. Processus 2D-Doc.

Guide d'intégration de l'application IAM

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

Sécurité. Objectifs Gestion de PKI Signature Cryptage Web Service Security

! " # $%& )* + ) %*,%* $-.* %% / *6- % 3445 ) + ) % %7* * )+ %) % # * 7 % ). " %%+ 7 ) 2 * ) 879%: 0!'* *';< $: ();<

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

Classification : public 1/59

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

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

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

Date : 16 novembre 2011 Version : 1. 2 Nombre de pages : 13

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

Définition des Webservices Ordre de paiement par . Version 1.0

Plateforme PAYZEN. Définition de Web-services

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

Du 03 au 07 Février 2014 Tunis (Tunisie)

Spécifications techniques et fonctionnelles du multi-années pour les noms de domaine en.fr

FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE

CONVENTION INDIVIDUELLE D HABILITATION. «Expert en automobile indépendant» (convention complète)

SAML et services hors web

Autorisation et gestion de accréditations

CONVENTION INDIVIDUELLE D HABILITATION. «société d assurance indépendante» (Convention complète)

Web Services : Beyond the peer-to-peer architecture

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

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

Plateforme Systempay. Correspondance entre SP PLUS et SYSTEMPAY Paiement Simple et en plusieurs fois

Les technologies de gestion de l identité

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

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

Mémoire de fin d'études

RÉFÉRENTIEL GÉNÉRAL DE SÉCURITÉ

ENVOLE 1.5. Calendrier Envole

Volet Synchrone pour Client Lourd

GUIDE UTILISATEUR APD

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

Solutions technologiques d authentification électronique Architecture et spécifications de l interface Version 2.0 : Profil de mise en place

Tour d horizon des différents SSO disponibles

Les solutions aux problèmes pour sécuriser XML

Attaques sur les Web Services. Renaud Bidou

La sécurité des processus métiers et des transactions. Stéphane Marcassin Bull Services Sécurité

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

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs

Sécurisation des architectures traditionnelles et des SOA

Introduction. aux architectures web. de Single Sign-On

Guide d implémentation. Réussir l intégration de Systempay

Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance

L impact du programme de relance sur le projet régional 19/05/2009 COPIL AMOA 1

Convention d adhésion à la fédération d identités marocaine pour l éducation et la recherche (EduIDM)

Cadre de Référence de la Sécurité des Systèmes d Information

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

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

Projet de Conception N 1 Automatisation d'un processus de paiement. Livrable: Spécification du système de compensation

DESCRIPTION DU COMPOSANT

4. SERVICES WEB REST 46

La sécurité des Réseaux Partie 7 PKI

Dématérialisation des factures du Secteur Public

Politique de Référencement Intersectorielle de Sécurité (PRIS)

Autorité de Certification OTU

TrustedBird, un client de messagerie de confiance

Cours 14. Crypto. 2004, Marc-André Léger

Politique de Certification

Gestion documentaire (Extraits du CCI version 1.2)

RECOMMANDATIONS POUR LA GESTION DE

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

Comité sectoriel de la sécurité sociale et de la santé Section «Sécurité sociale»

Sécurité des réseaux IPSec

POLITIQUE DE CERTIFICATION DE L'AC KEYNECTIS SSL RGS * (authentification serveur) Date : 12/08/2011

La sécurité dans les grilles

Groupe Eyrolles, 2004 ISBN :

Cours Base de données relationnelles. M. Boughanem, IUP STRI

LEGALBOX SA. - Politique de Certification -

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

EDESS. 1 Démarche générale principes 2

Politique de Certification et Déclaration des pratiques de certifications de l autorité Tunisian Server Certificate Authority PTC BR

Présentation. LogMeIn Rescue. Architecture de LogMeIn Rescue

PROCEDURE D'APPEL DU WEBSERVICE PERMETTANT DE CONTROLER LES FICHIERS XML-SANDRE Version 4

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

Gestion des Clés Publiques (PKI)

Politique de Certification Autorité de Certification Signature Gamme «Signature simple»

Architectures PKI. Sébastien VARRETTE

Signature électronique. Romain Kolb 31/10/2008

Les infrastructures de clés publiques (PKI, IGC, ICP)

Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PUBLIÉ

Glossaire. Arborescence : structure hiérarchisée et logique qui permet d organiser les données dans un système informatique.

Politique de Certification de l'ac "ALMERYS SIGNATURE AND AUTHENTICATION CA NC" Référentiel : Sous-Référentiel : Référence : Statut :

Réponse : Liste des paramètres de retour :... 7 Simuler un envoi (POST /send/simulate)... 8 Publipostage (POST /send/lists)...

Règlement de la Consultation

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE

Gouvernance des mesures de sécurité avec DCM-Manager. Présentation du 22 mai 2014

Chapitre 7. Sécurité des réseaux. Services, attaques et mécanismes cryptographiques. Hdhili M.H. Cours Administration et sécurité des réseaux

Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références

TheGreenBow IPsec VPN Client. Guide de Déploiement Options PKI. Site web: Contact:

ROYAUME DU MAROC Politique de certification - Autorité de Certification Externe -

Transcription:

MINISTÈRE DU TRAVAIL, DE l EMPLOI ET DE LA SANTÉ MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU BUDGET, DES COMPTES PUBLICS ET DE LA RÉFORME DE L ÉTAT Standard d'interopérabilité entre organismes de la sphère sociale Réf : Standard Interops2.0_SpécificationsVI Version 2.0 du 05/04/2012

1 2 3 Référence : Standard Interops2.0_SpécificationsVI Version : 2.0 Date de dernière mise à jour : 05/04/2012 Niveau de confidentialité : PUBLIC 4 5 6 7 Table des mises à jour du document N de version 2.0 05/04/12 Date Auteur Objet de la mise à jour Groupe de travail Interops Version pour diffusion Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 2/23

8 9 SOMMAIRE 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 SOMMAIRE... 3 1. INTRODUCTION... 4 1.1 Objet du document... 4 1.2 Relation avec d autres documents... 4 1.3 Organisation et structure du document... 4 1.4 Notations... 4 1.5 Références... 5 1.5.1 Références internes... 5 1.5.2 Références externes... 5 2. ELEMENTS DU VECTEUR D IDENTIFICATION... 6 2.1 Présentation... 6 2.2 Format du vecteur d identification... 7 2.2.1 Format d une assertion SAML 1.1... 7 2.2.2 Format d une assertion SAML 2.0... 8 2.2.3 Format d une réponse SAML 2.0... 10 2.3 Description des éléments d un Jeton SAML... 12 2.3.1 Eléments communs... 13 2.3.2 Eléments propres à SAML 1.1... 14 2.3.3 Eléments propres à SAML 2.0... 15 2.3.4 Description des éléments d une réponse SAML... 16 2.4 Utilisation du Vecteur d Identification pour le mode application à application... 17 2.5 Utilisation du Vecteur d Identification pour le mode portail à portail... 17 3. ANNEXES... 19 3.1 Exemple d assertion SAML 1.1 pour le mode application à application... 19 3.2 Exemple d assertion SAML 2.0 pour le mode application à application... 20 3.3 Exemple de réponse SAML 2.0 pour le mode portail à portail... 22 37 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 3/23

38 1. INTRODUCTION 39 40 41 1.1 Objet du document Ce document présente les spécifications détaillées du Vecteur d Identification du Standard d Interopérabilité des Organismes de la Sphère Sociale [R1]. 42 43 1.2 Relation avec d autres documents Ce document complète le Standard [R1]. 44 45 46 47 48 49 1.3 Organisation et structure du document La structure du présent document est, en sus de la présente introduction, organisé comme suit : Le chapitre 2 «Eléments du Vecteur d identification» regroupe une description succincte des éléments du Vecteur d identification, son format et un exemple Le chapitre 3 «Annexes» rassemble les annexes, les références et un exemple de Vecteur d identification 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 1.4 Notations Les namespaces suivants seront utilisés : ds Représente le namespace XML-DSig http://www.w3.org/2000/09/xmldsig# saml Représente le namespace SAML Assertions V1.1 urn:oasis:names:tc:saml:1.0:assertion saml2 Représente le namespace SAML Assertions V2.0 urn:oasis:names:tc:saml:2.0:assertion xs Représente le namespace spécifiant le schéma XML http://www.w3.org/2001/xmlschema Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 4/23

65 66 1.5 Références 1.5.1 Références internes [R1] Référence Titre Auteur Ver. Date Standard Interops2.0_SpecificationsFonc tionnelles Spécifications fonctionnelles Groupe de travail Interops 2.0 05/04/ 2012 67 1.5.2 Références externes [RFC4122] Titre Auteur Date A Universally Unique IDentifier (UUID) URN Namespace [RGS] Référentiel Général de Sécurité version 1.0 [RGS_A_14] Référentiel Général de Sécurité version 1.0 Annexe A14 : Profils de Certificats / LCR / OCSP et Algorithmes Cryptographiques [RGS_B_1] Référentiel Général de Sécurité version 1.0 [SAMLCore] [SAML2Core] [SAML2Authn Cxt] Annexe B1 : Mécanismes cryptographiques Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1 Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0 Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0 P. Leach, M. Mealling, R. Salz 07/2005 ANSSI/DGME 06/05/2010 ANSSI/DGME 11/02/2010 ANSSI/DGME 26/01/2010 Eve Maler, Prateek Mishra, Rob Philpott Cantor, Scott, Kemp, John, Philpott, Rob, Maler, Eve 02/09/2003 15/03/2005 J. Kemp et al 15/03/2005 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 5/23

68 2. ELEMENTS DU VECTEUR D IDENTIFICATION 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 2.1 Présentation Le Vecteur d Identification doit contenir a minima les éléments du tableau suivant : N Elément du vecteur d identification 1 Numéro de version pour le format du vecteur d'identification 2 Identifiant de vecteur unique pour tous les organismes 3 Identifiant de l Organisme Client 4 Identifiant de l utilisateur ou de l application cliente, éventuellement dépersonnalisé. Il est fortement recommandé d utiliser un identifiant persistent (cf. paragraphe 2.3 «Description des éléments d un Jeton SAML»). 5 Date de création 6 Durée de vie de l habilitation 7 Identifiant de l Organisme Fournisseur de service 8 Service visé (sous forme d URI sans partie locale) 9 Liste des PAGM valides pour l utilisateur ou l application cliente 10 Attributs Optionnels facultatifs concernant l identification de l utilisateur ou de l application cliente (indication géographique, localisation, niveau de sécurité, ). Ces attributs ne doivent pas contenir de données applicatives. 11 Niveau d authentification initiale (moyen ou niveau de moyen avec lequel l authentification initiale de l utilisateur ou de l application cliente est réalisée) 12 Signature numérique délivrée par l organisme de départ SAML 1.1 ou 2.0 est utilisé pour transmettre les informations du vecteur d identification. La signature par l organisme client permet à tout instant de vérifier l origine du vecteur d identification et d en assurer l intégrité des informations contenues, telles que les PAGM, la durée de validité, etc. Le vecteur d identification peut être conservé tel quel pour archivage Certains des éléments du vecteur d identification sont conventionnels : Le numéro de version pour le format du vecteur d'identification L identifiant de l Organisme Client L identifiant de l Organisme Fournisseur de service Le service visé (sous forme d URI sans partie locale) La durée de vie de l habilitation Les certificats de signature Les PAGM possibles pour le service visé Dans le cas où les échanges devront être sécurisés en utilisant des mécanismes conformes au Référentiel Général de Sécurité, les moyens cryptographiques utilisés devront suivre les préconisations contenues dans le [RGS]. En particulier, les tailles de clés et algorithmes utilisés devront Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 6/23

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 respecter [RGS_B_1] et les profils de certificats devront s appuyer sur [RGS_A_14]. C est particulièrement effectif dans le cas de la signature du VI puisqu on utilise ici la fonction de sécurité «cachet serveur» D autres éléments sont définis à la génération du vecteur d identification à partir du contexte de sécurité de l organisme client : L identifiant de vecteur unique pour tous les organismes L identifiant de l utilisateur ou de l application cliente, éventuellement dépersonnalisé La Date de création Les Attributs Optionnels La liste des PAGM valides pour l utilisateur ou l application cliente Le niveau d authentification initiale NB : Par convention et sauf précision contraire, dans ce document et dans les autres documents spécifiant le standard Interops, le terme VI désignera l élément signé. C'est-àdire : L assertion SAML 1.1 ou 2.0 dans Interops-A La réponse SAML 2.0 dans Interops-P 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 2.2 Format du vecteur d identification Le vecteur d identification peut être formaté à l aide du standard SAML 1.1 ou 2.0. La correspondance entre les informations du vecteur d identification et d une assertion SAML, en fonction de la version de SAML utilisée, est définie dans les paragraphes 2.2.1 et 2.2.2. 2.2.1 Format d une assertion SAML 1.1 Le format d une assertion SAML 1.1 est décrit ci-dessous. Chaque mot écrit entre crochets en gras rouge (ex : [ID]) est une variable paramétrée dont la valeur est définie dans le 2.3 p12. <?xml version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Issuer="[Issuer]" AssertionID="[ID]" MajorVersion="1" MinorVersion="1" IssueInstant=" [IssueInstant]"> <Conditions NotBefore="[NotOnBefore]" NotOnOrAfter="[NotOnOrAfter]"> <AudienceRestrictionCondition> <Audience>[Audience]</Audience> </AudienceRestrictionCondition> </Conditions> <AuthenticationStatement AuthenticationInstant="[AuthnInstant]" AuthenticationMethod="[MethodAuthn]"> <Subject> <NameIdentifier Format="[SubjectFormat]"> uid=[subjectid] Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 7/23

131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 </NameIdentifier> <SubjectConfirmation> <ConfirmationMethod> urn:oasis:names:tc:saml:1.0:cm:bearer </ConfirmationMethod> </SubjectConfirmation> </Subject> </AuthenticationStatement> <AttributeStatement> <Subject> <NameIdentifier Format="[SubjectFormat]"> uid=[subjectid] </NameIdentifier> </Subject> <Attribute AttributeNamespace="urn:iops:attributs:pagm" AttributeName="PAGM"> <AttributeValue>[PAGM]</AttributeValue> </Attribute> </AttributeStatement> <ds:signature> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:reference URI="#[ID]"> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:digestvalue>...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>...</ds:signaturevalue> </ds:signature> </Assertion> 165 166 167 168 169 170 2.2.2 Format d une assertion SAML 2.0 Le format d une assertion SAML 2.0 est décrit ci-dessous. Chaque mot écrit entre crochets en gras rouge (ex : [ID]) est une variable paramétrée dont la valeur est définie dans le 2.3 p12. <?xml version="1.0" encoding="utf-8"?> Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 8/23

171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 <saml2:assertion Version="2.0" IssueInstant="[IssueInstant]" ID="[ID]" xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:oasis:names:tc:saml:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion- 2.0.xsd"> <saml2:issuer>[issuer]</saml2:issuer> <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:reference URI="#[ID]"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:digestvalue>...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>...</ds:signaturevalue> </ds:signature> <saml2:subject> <saml2:nameid Format="[SubjectFormat2]"> [SubjectId2]</saml2:NameID> <saml2:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:subjectconfirmationdata NotOnOrAfter="[NotOnOrAfter]" Recipient="[Recipient]"/> </saml2:subjectconfirmation> </saml2:subject> <saml2:conditions NotOnOrAfter="[NotOnOrAfter]" NotBefore="[NotOnBefore]"> <saml2:audiencerestriction> <saml2:audience>[audience]</saml2:audience> </saml2:audiencerestriction> </saml2:conditions> <saml2:authnstatement AuthnInstant="[AuthnInstant]" SessionIndex="[ID]"> <saml2:authncontext> Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 9/23

216 217 218 219 220 221 222 223 224 225 226 <saml2:authncontextclassref> [MethodAuthn2] </saml2:authncontextclassref> </saml2:authncontext> </saml2:authnstatement> <saml2:attributestatement> <saml2:attribute Name="PAGM"> <saml2:attributevalue>[pagm]</saml2:attributevalue> </saml2:attribute> </saml2:attributestatement> </saml2:assertion> 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 2.2.3 Format d une réponse SAML 2.0 Le format d une réponse SAML 2.0 est décrit ci-dessous. Chaque mot écrit entre crochets en gras rouge (ex : [ID]) est une variable paramétrée dont la valeur est définie dans le 2.3 p12. <?xml version="1.0" encoding="utf-8"?> <samlp:response Destination="[Destination]" IssueInstant="[IssueInstant]" ID="[ID]" Version="2.0" xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol"> <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">[issuer]</saml:issu er> <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:reference URI="#[ID]"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:digestvalue>...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>... Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 10/23

259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 </ds:signaturevalue> </ds:signature> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:assertion Version="2.0" IssueInstant="[IssueInstant]" ID="[ID]" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:oasis:names:tc:saml:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion- 2.0.xsd"> <saml:issuer>[issuer]</saml:issuer> <saml:subject> <saml:nameid Format="[SubjectFormat2]"> [SubjectId2]</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter="[NotOnOrAfter]" Recipient="[Recipient]"/> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotOnOrAfter="[NotOnOrAfter]" NotBefore="[NotOnBefore]"> <saml:audiencerestriction> <saml:audience>[audience]</saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant="[AuthnInstant]" SessionIndex="[ID]"> <saml:authncontext> <saml:authncontextclassref>[methodauthn2] </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute Name="PAGM"> <saml:attributevalue> [PAGM]</saml:AttributeValue> </saml:attribute> </saml:attributestatement> </saml:assertion> </samlp:response> Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 11/23

302 303 304 305 306 307 308 2.3 Description des éléments d un Jeton SAML Les variables sont décrites dans les sections ci-après. Les variables peuvent être : Communes aux formats SAML 1.1 et 2.0 Propres au format SAML 1.1 Propres au format SAML 2.0 Propre au protocole SAML 2.0 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 12/23

309 310 311 2.3.1 Eléments communs Les variables communes aux formats SAML 1.1 et 2.0 sont décrites dans le tableau ci-dessous. Nom Description Format Exemple Elément du VI ID Identifiant unique de l assertion Le format de l identifiant doit suivre les recommandations de la RFC 4122 [RFC4122] afin d assurer l unicité de l identifiant IssueInstant Instant de génération de l assertion Valeur de type type xs:datetime (type de donnée de schéma XML) et doit être exprimée en UTC, sans fuseau horaire uuid:f81d4fae-7dec-11d0- a765-00a0c91e6bf6 2003-04-17T00:46:02Z 5 2 Issuer Identification de l émetteur de l assertion, et donc de l organisme client NotOnOrAfter Date d expiration de l assertion La date d expiration est dépendante de la durée de validité de l assertion et doit prendre en compte une dérive des horloges des systèmes NotOnBefore Date de début de validité de l assertion La date de début de validité de l assertion doit prendre en compte une dérive des horloges des systèmes. La date de début de validité doit donc être légèrement avancée par rapport à la date d émission Le format de l identification est une URI. L organisme client doit être identifié par une URI contenant le numéro de version de l accord d interopérabilité Valeur de type type xs:datetime (type de donnée de schéma XML) et doit être exprimée en UTC, sans fuseau horaire Valeur de type xs:datetime (type de donnée de schéma XML) et doit être exprimée en UTC, sans fuseau horaire Audience Identifiant du service visé URI décrivant le service visé. Il est recommandé de décrire le service à l aide d une URL, comprenant le nom de domaine de l organisme fournisseur et le nom du service publics précisés dans l accord urn:interops:{siren SIRE T}:idp:{libre}:version 2003-04-17T00:46:02Z 6 2003-04-17T00:46:02Z 6 1, 3 http://rniam.cnav.fr 7, 8 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 13/23

312 313 314 315 316 317 318 319 320 321 322 323 324 325 AuthnInstant Instant d authentification de l usager sur le SI. A moins de disposer de cette information, l instant d authentification peut être égal à l instant de création de l assertion Valeur de type type xs:datetime (type de donnée de schéma XML) et doit être exprimée en UTC, sans fuseau horaire PAGM Liste des PAGM L attribut listant les PAGM doit s appeler PAGM. Format des identifiants d organismes La recommandation pour les identifiants d organisme est la suivante : Une liste de PAGM peut être donnée en multipliant les éléments <AttributeValue> dans l élément <Attribute> L AttributeNamespace doit être urn:iops:attributs:pagm. urn:interops:{siren SIRET}:{idp sp}:{libre} L utilisation du SIREN ou du SIRET pour identifier l organisme répond à deux besoins : Unicité sur l ensemble des organismes Indépendance de la nomenclature par rapport aux OPS Dans le cas de l organisme client, la version de la convention doit être concaténée à l identifiant pour donner : Attributs complémentaires urn:interops:{siren SIRET}:idp:{libre}:version 2003-04-17T00:46:02Z <Attribute AttributeNamespace="urn: iops:attributs:pagm" AttributeName="PAGM"> <AttributeValue> PAGM1 </AttributeValue> <AttributeValue> PAGM2 </AttributeValue> </Attribute> D autres attributs peuvent être ajoutés au VI (élément 10). Dans ce cas, ils doivent être déclarés dans l unique élément <saml:attributestatement>. Comme pour les PAGM, un nom et des valeurs et un namespace sont donnés. Ces attributs sont spécifiques à chaque accord d interopérabilité. 2.3.2 Eléments propres à SAML 1.1 Les variables propres au format SAML 1.1 sont décrites dans le tableau ci-dessous. 9 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 14/23

326 Nom Description Format Exemple Elément du VI SubjectFormat SubjectId Identifiant du format de l identifiant de l utilisateur ou de l application cliente pour SAML 1.1 Identifiant de l utilisateur ou de l application cliente MethodAuthn Méthode d authentification de l utilisateur ou de l application cliente sur le SI de l organisme client Le format de l identifiant dépend de l accord d interopérabilité. Il est fortement recommandé d «impersonnifier» les usagers tout en garantissant l'unicité. D autres formats sont cependant disponible [SAMLCore] Dans le cas où le format urn:oasis:names:tc:saml:1.1:nameidformat:x509subjectname est pris, l identifiant, à la charge de l organisme client, peut être représenté par une chaîne X509 La méthode d authentification est une URI. Pour l ensemble des valeurs normalisées, se reporter à [SAMLCore] urn:oasis:names:tc:saml:1.1:nameidformat:x509subjectname uid=abjj1992 4 urn:oasis:names:tc:saml:1.0:am:password 11 327 328 329 2.3.3 Eléments propres à SAML 2.0 Les variables propres au format SAML 2.0 sont décrites dans le tableau ci-dessous. Nom Description Format Exemple Elément du VI SubjectFormat2 Identifiant du format de l identifiant de l utilisateur ou de l application cliente pour SAML 2.0 Le format de l identifiant dépend de l accord d interopérabilité. Il est fortement recommandé d «impersonnifier» les usagers et donc d utiliser le format urn:oasis:names:tc:saml:2.0:nameidformat:persistent. Ce format indique qu un identifiant opaque persistant est utilisé pour identifier les utilisateurs ou les applications clientes. La persistance s entend comme un identifiant unique pour un utilisateur ou une application cliente dans le cadre d une relation organisme client organisme fournisseur donnée, et ce pour une période cohérente avec la durée opérationnelle (durée de urn:oasis:names:tc:saml:2.0:nameid-format: persistent Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 15/23

SubjectId2 Identifiant de l utilisateur ou de l application cliente MethodAuthn2 Méthode d authentification de l utilisateur sur le SI de l organisme client Recipient Identifiant de l organisme fournisseur vie des traces d audit, de la convention, etc.). D autres formats sont cependant disponible [SAML2Core]. On peut imaginer que pour «impersonnfier» l'utilisateur ou l application cliente, on régénère l'identifiant aléatoire (transient) Dans le cas où le format urn:oasis:names:tc:saml:2.0:nameid-format: persistent est pris, tout identifiant pseudo-aléatoire ne permettant pas d identifier un utilisateur est utilisable La méthode d authentification est une URI. Pour l ensemble des valeurs normalisées, se reporter à [SAML2AuthnCxt] URI identifiant l organisme client pouvant recevoir l assertion urn:oasis:names:tc:saml:2.0:ac:classes:password urn:interops:sp:{siren SI RET}:{libre} 4 11 330 2.3.4 Description des éléments d une réponse SAML Nom Description Format Exemple ID Identifiant unique de la réponse Le format de l identifiant doit suivre les recommandations de la RFC 4122 [RFC4122] afin d assurer l unicité de l identifiant IssueInstant Instant de génération de la réponse Valeur de type type xs:datetime (type de donnée de schéma XML) et doit être exprimée en UTC, sans fuseau horaire Issuer Destination Identification de l émetteur de la réponse, et donc de l organisme client URI identifiant l adresse du service de réception des assertions Le format de l identification est une URI. L organisme client doit être identifié par une URI, pouvant contenir le numéro de version de l accord d interopérabilité Cet identifiant est identique à l élément Issuer de l assertion Cette URL correspond à la valeur du paramètre «action» du formulaire utilisé pour soumettre la réponse SAML. L organisme fournisseur doit vérifier que la valeur de ce champ correspond bien à l adresse à laquelle elle a été reçue. f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2003-04-17T00:46:02Z urn:interops:idp:{siren S IRET}:{libre}:version https://www.exemple.com:9 031/sp/ACS.saml2 Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 16/23

Direction de la Sécurité Sociale 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 2.4 Utilisation du Vecteur d Identification pour le mode application à application Dans le mode application à application, le Vecteur d Identification est signé. Une signature (enveloppée) XML, correspondant à l élément 12 du Vecteur d Identification, est incluse dans l assertion SAML. Toutes les implémentations devront supporter le format de signature XML-DSig suivant : Algorithme de hachage Canonicalisation XML Transformation Description SHA1 Canonicalisation XML Exclusive Signature enveloppée URN http://www.w3.org/2000/09/xmldsig#sha1 http://www.w3.org/2001/10/xml-exc-c14n# http://www.w3.org/2000/09/xmldsig#envelope d-signature Signature RSAwithSHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 La signature XML-DSig doit contenir un élément ds:keyinfo indiquant quelle clé a été employée pour la signature. Toutes les implémentations devront supporter l insertion des éléments ds:x509data et ds:x509certificate. Les organismes doivent par ailleurs s échanger les chaînes de certification. La signature «cachet serveur» est une fonction de sécurité faisant appel à des mécanismes cryptographiques qui peut nécessiter d être conforme au RGS. Concernant cette conformité, se reporter à la note du paragraphe 2.1. La «méthode de confirmation» est fonction de la version de SAML utilisée : Pour SAML 1.1 : o Elle est précisée dans l élément /saml:authenticationstatement/saml:subject/saml:subjectcon firmation/ saml:confirmationmethod o Elle prend la valeur : Pour SAML 2.0 : o urn:oasis:names:tc:saml:1.0:cm:sender-vouches Elle est précisée dans l élément /saml:subject/saml:subjectconfirmation o Elle prend la valeur : urn:oasis:names:tc:saml:2.0:cm:sender-vouches On pourra se reporter aux paragraphes 3.1 et 3.2 pour des exemples de VI conformes à la spécification. 361 362 363 2.5 Utilisation du Vecteur d Identification pour le mode portail à portail Dans le mode portail à portail, le profil Web SSO Post de SAML 2.0 est utilisé : l assertion SAML jouant le rôle de Vecteur d Identification est incluse dans une réponse SAML. Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 17/23

Direction de la Sécurité Sociale 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 L assertion SAML peut être signée, mais la réponse SAML doit être obligatoirement signée. La signature de la réponse joue alors le rôle de la signature XML, correspondant à l élément 12 du Vecteur d Identification. Toutes les implémentations devront supporter le format de signature XML-DSig suivant : Algorithme de hachage Canonicalisation XML Transformation Description SHA1 Canonicalisation XML Exclusive Signature enveloppée URN http://www.w3.org/2000/09/xmldsig#sha1 http://www.w3.org/2001/10/xml-exc-c14n# http://www.w3.org/2000/09/xmldsig#envelope d-signature Signature RSAwithSHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 La signature XML-DSig doit contenir un élément ds:keyinfo indiquant quelle clé a été employée pour la signature. Toutes les implémentations devront supporter l insertion des éléments ds:x509data et ds:x509certificate. Les organismes doivent par ailleurs s échanger les chaînes de certification. La signature «cachet serveur» est une fonction de sécurité faisant appel à des mécanismes cryptographiques qui peut nécessiter d être conforme au RGS. Concernant cette conformité, se reporter à la note du paragraphe 2.1. La méthode de confirmation précisée dans l élément /saml:subject/saml:subjectconfirmation prend la valeur : urn:oasis:names:tc:saml:2.0:cm:bearer On pourra se reporter au paragraphe 3.3 pour un exemple de VI conforme à la spécification. Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 18/23

Direction de la Sécurité Sociale 383 3. ANNEXES 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 3.1 Exemple d assertion SAML 1.1 pour le mode application à application Un exemple d assertion est donné ci-dessous : <saml:assertion xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:1.0:protocol" Issuer="urn:iops:saql:idp:1" AssertionID="_d7b830d0-3f39-0410-a4d0-91314a1fb6c8" MajorVersion="1" MinorVersion="1" IssueInstant="2007-09- 03T19:02:25Z"> <saml:conditions NotBefore="2007-09-03T19:02:15Z" NotOnOrAfter="2007-09-03T20: 02:35Z"> <saml:audiencerestrictioncondition> <saml:audience>http://adresse-fournisseur/</saml:audience> </saml:audiencerestrictioncondition> </saml:conditions> <saml:authenticationstatement AuthenticationInstant="2007-09- 03T17:37:27Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:subject> <saml:nameidentifier Format="urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">id-avé-accent-source</saml:NameIdentifier> <saml:subjectconfirmation> <saml:confirmationmethod>urn:oasis:names:tc:saml:1.0:cm:sendervouches</saml:confirmationmethod> </saml:subjectconfirmation> </saml:subject> </saml:authenticationstatement> <saml:attributestatement> <saml:subject> <saml:nameidentifier xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">id-avéaccent-source</saml:NameIdentifier> </saml:subject> <saml:attribute AttributeNamespace="urn:iops:attributs:pagm" AttributeName="PAGM"> <saml:attributevalue>pagm1</saml:attributevalue> </saml:attribute> <saml:attribute AttributeNamespace="urn:iops:attributs:optionnal" AttributeName="departement"> <saml:attributevalue>22</saml:attributevalue> Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 19/23

Direction de la Sécurité Sociale 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 3.2 Exemple d assertion SAML 2.0 pour le mode application à application <saml:attributevalue>44</saml:attributevalue> </saml:attribute> <saml:attribute AttributeNamespace="urn:iops:attributs:optionnal" AttributeName="ville"> <saml:attributevalue>st brieuc</saml:attributevalue> <saml:attributevalue>nantes</saml:attributevalue> </saml:attribute> </saml:attributestatement> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-excc14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <Reference URI="#_d7b830d0-3f39-0410-a4d0-91314a1fb6c8"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>YaJbbcU5f...lJdzCcE=</DigestValue> </Reference> </SignedInfo> <SignatureValue>eD5Rkt6RQC...CwkIZjWLWSsE=</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIB2DCCAUGg...1mFkJn7/Ng=</X509Certificate> <X509Certificate>MIIB4jCCAUug...GFe7QdEO</X509Certificate> <X509Certificate>MIIB3TCCAUag...pA==</X509Certificate> </X509Data> </KeyInfo> </Signature></saml:Assertion> <saml:assertion xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xsi:schemalocation="urn:oasis:names:tc:saml:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion- 2.0.xsd" ID="_86bb16eb-3f39-0410-9d53-919a2d5a47b9" Version="2.0" IssueInstant="2007-09-03T19:09:56Z"> Réf. : Standard Interops2.0_SpécificationsVI version 2.0 du 05/04/2012 20/23