Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
federation:technique:cadre-technique [2019/02/26 14:26]
ludovic.auxepaules@renater.fr [7. Automatisation de la diffusion des attributs utilisateurs] Correction des liens des filtres d'attributs et des métadonnées
— (Version actuelle)
Ligne 1: Ligne 1:
-[[:​federation:​en:​technical-framework|Click here for the English version]] 
- 
-====== Cadre technique de la fédération Éducation-Recherche ====== 
- 
-**Version 1.6.1 (juillet 2018)** ([[cadre-technique-modifications|Historique des modifications]]) 
- 
-Ce document définit le cadre technique de la fédération Éducation-Recherche auquel doivent se conformer les participants à la fédération Éducation-Recherche. Ce cadre permet d'​assurer l'​interopérabilité entre les briques techniques communicant dans la fédération. Il définit également les modalités techniques mises en œuvre pour traduire techniquement leurs relations de confiance. 
- 
-Les recommandations et obligations stipulées dans ce document pourront être régulièrement modifiées par l'​opérateur de la fédération. Ces modifications peuvent être motivées notamment par des problèmes de sécurité, de nouveaux besoins fonctionnels,​ l'​apparition ou l'​évolution d'une norme ou d'un produit utilisé dans la fédération. Elles seront préalablement,​ et le plus tôt possible, annoncées par courrier électronique aux participants de la fédération. 
- 
-===== - Terminologie ===== 
- 
-**entité** : fait référence à une entité produisant ou consommant des assertions SAML, à savoir un fournisseur d'​identités ou une ressource (associé à un fournisseur de services). 
- 
-**guichet de la fédération** : interface web de gestion, mis en œuvre par l’opérateur de la fédération,​ permettant aux organismes d'​enregistrer des entités auprès de la fédération,​ et d'​effectuer la mise à jour des informations techniques de ces entités. 
- 
-===== - Normes utilisées dans la fédération ===== 
- 
-La norme SAML 2.0 est la norme de référence pour toute entité de la fédération,​ la version précédente SAML 1.1 n’étant utilisée qu’à des fins de rétro-compatibilité. Lorsque l’entité supporte les deux versions, elle **doit** utiliser SAML 2.0 par défaut. 
- 
-Toute entité enregistrée dans la fédération **doit** fournir au minimum les points d’accès SAML 2.0 suivant : 
-  * profil //Web Browser SSO// en utilisant le binding //HTTP POST// et en mode //attribute push// [SAMLv2] 
-  * profil //Web Browser SSO// en utilisant le binding //HTTP Redirect// [SAMLv2] 
- 
-Toute entité enregistrée dans la fédération **peut** fournir les points d’accès suivants : 
-  * profil Shibboleth //​Authentication Request// [ShibArch] 
-  * profil SAML 1.1 //​browser/​POST//​ en mode //attribute push// [SAMLv1.1] 
- 
-<note important>​ 
-Les profils nécessitant des échanges SOAP directs entre les briques techniques de la fédération (par exemple les profils //​Artifact//​) ne sont pas obligatoires et donc aucune garantie de leur bons fonctionnement ne peut être exigée. Il est donc fortement déconseillé d'​utiliser ces profils. 
-</​note>​ 
- 
-===== - Logiciels utilisables dans la fédération ===== 
- 
-L'​utilisation des logiciels suivants est recommandée,​ car ils bénéficient de [[:​federation:​docs:​shibboleth|documentations]] sur ce site et du [[:​federation:​contacts-support:​index|support technique]] par l'​opérateur de la fédération:​ 
-  * Shibboleth Service Provider 3.x [ShibSPv3]: fournisseur de services ; 
-  * Shibboleth Identity Provider 3.x [ShibIdPv3]:​ fournisseur d'​identités 
- 
-L'​utilisation des versions majeures précédentes de ces logiciels (2.x), bien que non recommandée,​ reste techniquement possible, mais avec un support limité de la part de l'​opérateur de la fédération,​ et aucun de la part de l'​éditeur,​ en particulier pour tout problème de sécurité. Les versions antérieures (1.x) ne doivent quand à elles plus êtres utilisées. 
- 
-Sous réserve d'​acceptation par l'​opérateur de la fédération,​ d'​autres logiciels de fédération pourront être utilisés, respectant notamment les critères suivants : 
-  * le logiciel doit implémenter les normes retenues dans la fédération (voir ci-dessus) et être utilisable en respectant les autres points définis dans le cadre technique (voir ci-dessous) ; 
-  * il ne doit pas induire des contraintes excessives pour l'​opérateur de la fédération (à son appréciation) ; 
-  * il ne doit pas induire des contraintes excessives dans la configuration et l'​administration des logiciels utilisés par les autres participants de la fédération (à l'​appréciation de l'​opérateur de la fédération) ; 
-  * Les tests d'​interopérabilité avec les logiciels de référence sont à la charge exclusive de l'​établissement qui introduit ces autres implémentations. 
- 
-Aucun support ni documentation n'est fourni pour ces autres logiciels. Un tel logiciel peut être interdit à postériori dans la fédération s'il empêche des évolutions du cadre technique, par exemple l'​acceptation d'une nouvelle norme ou d'une nouvelle version d'un logiciel supporté. 
- 
-===== - Liste d'​attributs officiels de la fédération ===== 
- 
-Une liste d'​attributs officiels de la fédération est publiée sur [[:​federation:​technique:​attributs|cette page]]. Cette liste d'​attributs,​ reconnue par l'​ensemble des organismes membres fournisseurs d'​identités,​ s'​appuie sur la norme SupAnn [SupAnn]. Les administrateurs de ressources sont invités à consulter cette liste pour vérifier si les attributs requis par son système y sont listés. Si c'est le cas un administrateur de ressource peut y faire référence pour indiquer aux fournisseurs d'​identités les attributs dont sa ressource a besoin. 
- 
-Si les attributs dont la ressource a besoin ne sont pas présents dans la liste d'​attributs officiels de la fédération,​ il y a deux possibilités :  
-  - soit ces attributs sont spécifiques à cette ressource ou à un sous-ensemble limité de participants de la fédération. Dans ce cas l'​administrateur de la ressource est libre de demander ces attributs, en accord avec les fournisseurs d'​identités concernés ; charge à lui de documenter le nommage, la sémantique et les nomenclatures associées de ces attributs. 
-  - soit ces attributs peuvent avoir un intérêt plus général pour d'​autres membres de la fédération. Dans ce cas l'​administrateur de la ressource est invité à prendre contact avec [[mailto:​support@renater.fr|les opérateurs de la fédération]] pour lui proposer l'​inclusion de ces attributs dans la liste d'​attributs officiels de la fédération. 
- 
-Un fournisseur d'​identités peut être inscrit dans la fédération sans implémenter l'​ensemble des attributs définis. Cependant si un attribut officiel est implémenté par un fournisseur d'​identités,​ il doit l'​être en se conformant au nommage, à la nomenclature et à la sémantique tels que défini dans les recommandations supAnn 2009. 
- 
- 
-===== - Gestion de la confiance au niveau technique ===== 
- 
-Les assertions SAML échangées dans la fédération sont signées et potentiellement chiffrées avec des certificats X.509. 
- 
-Le certificat utilisé par une entité SAML est publié dans les méta-données de la fédération. La confiance dans ce certificat vient du fait que cette publication est contrôlée par l’opérateur,​ qui joue de facto le rôle de tiers de confiance pour les échanges SAML au sein de cette fédération. Il n’y a donc pas de liste d'​autorités de certification reconnues, ni de liste de révocation. Toutes les opérations de déclaration et de renouvellement des certificats sont réalisées en mettant à jour les informations sur cette entité via le guichet ​ de la fédération. 
-  
-Il est déconseillé d'​utiliser des certificats émis par des autorités de certification à cause de leur durée de vie limitée, mais d'​utiliser plutôt des certificats auto-signés à longue durée de vie((entre 5 et 10 ans)), comme en génèrent beaucoup de logiciels SAML lors de l’installation. 
- 
-L'​intégrité du fichier des méta-données est assurée par une signature électronique,​ et le certificat permettant de vérifier celle-ci est disponible sur [[:​federation:​en:​metadata|cette page]]. Son authenticité est assurée par un accès exclusif sur une URL HTTPS. 
- 
-Merci de lire **[[certificats|ces obligations et recommandations]]** quant à la gestion des certificats dans le cadre de la fédération d'​identités ​ 
- 
-===== - Nommage des fournisseurs d'​identités et des ressources ===== 
- 
-Du fait de son appartenance à une autre fédération,​ si un fournisseur d'​identités ou une ressource possède déjà un identifiant,​ elle peut conserver cet identifiant pour son enregistrement dans la fédération Éducation-Recherche. 
- 
-Sinon les fournisseurs d'​identités et les ressources de la fédération doivent utiliser une URL comme identifiant (notion de //​entityID//​ dans SAML2). 
- 
-Exemples d'//​entityID//​ : 
-  * ''​https://​identites.univ-test.fr/​idp''​ 
-  * ''​https://​wiki.univ-test.fr/​sp''​ 
- 
-<​note>​ 
-L'​utilisation d'un entityID sous forme d'un URN (exemple : //​urn:​mace:​cru.fr:​federation:​univ-x.fr//​) est uniquement permise pour les organismes qui étaient préalablement membres de la fédération du CRU.</​note>​ 
- 
-Pour améliorer la pérennité de l'​identifiant,​ il faut si possible choisir comme nom de domaine le nom du service plutôt que le nom du serveur physique l'​hébergeant ou le nom du logiciel utilisé ; évitez de mentionnez le logiciel Shibboleth dans l'URL ou un numéro de version de logiciel. 
- 
-Si plusieurs entités sont hébergés sur le même domaine (par exemple ''​https://​example.org/​cours-en-ligne''​ et ''​https://​example.org/​wiki''​),​ il faut suffixer le chemin d'​accès à la ressource : ''​https://​example.org/​cours-ligne/​sp/''​ et ''​https://​example.org/​wiki/​sp/''​. 
- 
-===== - Automatisation de la diffusion des attributs utilisateurs ===== 
- 
-L'​opérateur de la fédération propose une classification des fournisseurs de services par portée (locale, nationale, ...) et par type (documentation en ligne, accès wifi, ...). Cette classification permet aux administrateurs des fournisseurs d'​identités de définir des politiques de diffusion des attributs utilisateurs par catégories de services, en se basant sur la présence de valeurs standardisées,​ nommées [[:​federation:​docs:​fiches:​entitycategories|Entity categories]],​ dans les méta-données SAML de la fédération. 
- 
-**Dans le but de garantir le bon fonctionnement des services nationaux, tout fournisseur d'​identités doit automatiser la diffusion des attributs utilisateurs requis par ces services (catégorie https://​federation.renater.fr/​scope/​national) par [[:​federation:​docs:​fiches:​filtres-attributs#​automatisation|une règle autorisant tous les attributs demandés]],​ ou à défaut utiliser les [[:​federation:​docs:​fiches:​filtres-attributs#​automatisation|filtres automatiques d'​attributs]] proposés par RENATER.** 
- 
-<​note>​Afin de simplifier la configuration de son fournisseur d'​identités,​ un organisme peut bien sûr automatiser la diffusion des attributs utilisateurs pour les autres catégories de services.</​note>​ 
- 
-===== - Autres fédérations ===== 
-En plus de la fédération Education-Recherche,​ l’opérateur propose plusieurs autres fédérations complémentaires. 
- 
-Afin d’effectuer des tests préalables à la mise en production, et d’une façon plus générale n’importe quelle expérimentation,​ il existe une **fédération de test**, dont l’accès n’est soumis à aucune condition préalable. L’inscription dans cette fédération est supposée être transitoire,​ et il n’est pas souhaitable qu’une entité soit inscrite simultanément dans cette fédération et dans une autre fédération de production. 
- 
-La **fédération eduGAIN** est une inter-federation,​ regroupant plusieurs fédération nationales comme la notre. La fédération Education Recherche applique une politique d’inscription de ses propres entités différentes en fonction de leur type : 
-  * les fournisseurs d’identités sont inscrit par défaut, sauf choix explicite (politique de type opt-out) 
-  * les fournisseurs de service ne sont pas inscrites par défaut, sauf choix explicite (politique de type opt-in) 
- 
-Enfin, les **fédérations locales** sont des fédérations privées, dont la visibilité peut d’ailleurs être restreinte, destinées à offrir des services à une population plus restreinte que l’ensemble de la communauté Education-Recherche. 
- 
-===== - Recommandations et obligations ===== 
- 
-Afin de fiabiliser les interactions entre des briques techniques hétérogènes,​ les entités inscrites dans les différentes fédération mentionnées précédemment doivent respecter un certain nombre de contraintes,​ détaillées ici. Ces contraintes sont notamment vérifiées lors de la déclaration ou de la modification des informations liées à cette entité via le guichet de la fédération,​ mais peuvent également l’être lors de revues périodiques. 
- 
-==== - Fédération de test ==== 
- 
-Les obligations suivantes s’appliquent à tout type d’entité :​ 
-  * l'​entité doit avoir un intitulé en français 
-  * l'​entité doit avoir une description en français 
-  * l'​entité doit avoir un certificat valide pour la couche SAML, avec une clé associée d’une longueur d’au moins 2048 bits 
-  * l'​entité doit avoir au moins un contact technique individuel 
-  * si l'​entité est conforme SIRTFI, elle doit avoir un contact dédié 
-  * si l'​entité est conforme CoC, elle doit avoir une politique de confidentialité accessible en ligne 
-  * les points d’accès SAML définis doivent correspondre au minimum à ceux cités au paragraphe 1.0 
-  * les points d’accès SAML définis doivent être sécurisé par l’utilisation de TLS, avec un certificat valide, délivré par une autorité de certification reconnue 
-  * s'il est défini, le logo doit être au format PNG ou GIF, et de taille raisonnable (maximum 5120Ko) 
-  * l'​entité doit charger les métadonnées de la fédération de test 
- 
-Les obligations supplémentaires suivantes s’appliquent à tout fournisseur de services : 
-  * tous les attributs utilisateurs requis doivent être justifiés par une description succincte de l’usage qui en est fait (authentification,​ affichage, etc.) 
- 
-Les obligations supplémentaires suivantes s’appliquent à tout fournisseur d’identités :​ 
-  * la page d’authentification doit être sécurisée par l'​utilisation de TLS, avec un certificat valide, délivré par une autorité de certification reconnue 
-  * les dimensions d'un éventuel logo sont fixées à 16x16 pixels 
- 
-==== - Fédération Éducation-Recherche ==== 
-Les obligations supplémentaires suivantes s’appliquent à tout type d’entité:​ 
-  * l'​entité doit être rattachée à un organisme membre ou partenaire 
-  * l'​entité ne doit pas être inscrite dans la fédération de test 
-  * l'​entité doit charger les métadonnées de la fédération Éducation-Recherche 
- 
-==== - Fédération eduGAIN ==== 
-Les obligations supplémentaires suivantes s’appliquent à tout type d’entité :​ 
-  * l'​entité doit avoir un intitulé en anglais 
-  * l'​entité doit avoir une description en anglais 
-  * l'​entité doit être inscrite dans la fédération Éducation-Recherche 
-  * l'​entité doit charger les métadonnées de la fédération eduGAIN 
- 
-===== Annexe : références ===== 
- 
-  * [SAMLv1.1]: [[http://​www.oasis-open.org/​specs/​index.php#​samlv1.1|Security Assertion Markup Language (SAML) v1.1]] 
-  * [SAMLv2]: [[http://​www.oasis-open.org/​specs/​index.php#​samlv2.0|Security Assertion Markup Language (SAML) v2.0]] 
-  * [ShibArch]: [[https://​wiki.shibboleth.net/​confluence/​display/​SHIB2/​UnderstandingShibboleth|Understanding Shibboleth]] 
-  * [ShibSPv3]: [[https://​wiki.shibboleth.net/​confluence/​display/​SP3/​Home|SP Shibboleth v3.x]] 
-  * [ShibIdPv3]:​ [[https://​wiki.shibboleth.net/​confluence/​display/​IDP30/​Home|IdP Shibboleth v3.x]] 
-  * [SupAnn]: [[:​documentation:​supann:​index]]