Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
federation:technique:sirtfi [2018/04/25 14:14] – [3. Déclarer la conformité SIRTFI d'une entité SAML : guide étape-par-étape] herve.bourgault@renater.fr | federation:technique:sirtfi [2020/12/01 15:06] (Version actuelle) – geoffroy.arnoud@renater.fr | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | [[:federation:en:sirtfi|Click here for the English version]] | + | Cette page a été déplacée ici [[federation: |
- | + | ||
- | ====== SIRTFI : Un cadre de sécurité pour les fédérations ====== | + | |
- | + | ||
- | ===== 1. Pourquoi SIRTFI ===== | + | |
- | + | ||
- | Le développement et l’inter-connexion des fédérations via eduGain a créé un nouveau vecteur d’attaque. Un compte compromis peut aujourd’hui potentiellement donner accès à une multitude de services au sein de la communauté. | + | |
- | + | ||
- | Ce nouveau vecteur d' | + | |
- | + | ||
- | Le framework SIRTFI (//Security Incident Response Trust Framework for Federated Identity//) se veut une réponse à ce problème. Il vise à fournir un cadre permettant d’une part, d’identifier les participants de confiance de la fédération et d’autre part, de garantir une collaboration efficace entre les entités lors d’une réponse à un incident de sécurité lié à la fédération. | + | |
- | + | ||
- | SIRTFI est une initiative du groupe REFEDS (//Research and Education FEDerations group// | + | |
- | \\ \\ | + | |
- | + | ||
- | ===== 2. Le framework SIRTFI en bref ===== | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Le framework SIRTFI définit un ensemble de règles et bonnes pratiques sécurité articulées autour des quatre domaines suivants : sécurité opérationnelle, | + | |
- | + | ||
- | Le tableau suivant dresse une description synthétique du contenu de chacune des thématiques: | + | |
- | + | ||
- | ^ Domaine | + | |
- | | **Sécurité Opérationnelle [OS]** | + | |
- | | **Réponse sur incident [IR]** | + | |
- | | **Traçabilité [TR]** | + | |
- | | **Responsabilité des Participants [PR]** | + | |
- | + | ||
- | \\ \\ | + | |
- | + | ||
- | + | ||
- | ===== 3. Déclarer la conformité SIRTFI d'une entité SAML : guide étape-par-étape ===== | + | |
- | + | ||
- | Le chapitre qui suit décrit les étapes à suivre par une organisation afin de pouvoir déclarer une entité SAML conforme à SIRTFI | + | |
- | + | ||
- | === Etape 1 - Auto-évaluation de l' | + | |
- | + | ||
- | La première étape pour une organisation consiste à s' | + | |
- | + | ||
- | <note important> | + | |
- | + | ||
- | Dans le cas où l' | + | |
- | + | ||
- | === Etape 2 - Déclaration de conformité SIRTFI d'une entité SAML (Guichet de la fédération) === | + | |
- | + | ||
- | La déclaration de conformité SIRTFI pour une ressource (IdP ou SP) s' | + | |
- | + | ||
- | Au niveau de l' | + | |
- | + | ||
- | <note warning> | + | |
- | + | ||
- | Après avoir coché la case, il est alors obligatoire de renseigner un contact sécurité pour cette ressource (les champs nom et adresse email du contact sécurité, grisés jusqu' | + | |
- | + | ||
- | + | ||
- | === Etape 3 - Choix d'un contact Sécurité pour l' | + | |
- | + | ||
- | Le contact sécurité d'une ressource sera le point de contact de référence dans le cas d’un incident de sécurité lié à la fédération impliquant cette ressource. | + | |
- | + | ||
- | En tant qu’organisation appartenant à la Fédération Education-recherche, | + | |
- | * **Option 1 :** RENATER fournissant déjà un support centralisé pour les incidents de sécurité touchant la Fédération Education-Recherche, | + | |
- | + | ||
- | * **Option 2 :** Si votre organisation possède déjà une équipe ou un service sécurité sensibilisé aux problématiques liées à la fédération, | + | |
- | + | ||
- | <note important> | + | |
- | </ | + | |
- | + | ||
- | === Etape 4 - Soumission des modifications (Guichet de la fédération) === | + | |
- | + | ||
- | La soumission de ces modifications (attestation conformité + contact sécurité) sur le guichet entraîne l’ajout de deux balises spécifiques SIRTFI (//SIRTFI entity attribute// et //Security Contact//) dans les méta-données associées à la ressource. | + | |
- | + | ||
- | Un exemple de ces deux balises est présenté en annexe au chapitre 6. | + | |
- | + | ||
- | \\ | + | |
- | + | ||
- | ===== 4. SIRTFI en utilisation courante ===== | + | |
- | + | ||
- | Pour une organisation conforme, l’utilisation de SIRTFI au quotidien pourra prendre les formes suivantes : | + | |
- | + | ||
- | 1. Une collaboration au processus de réponse sur incident lié à la fédération : | + | |
- | * Si vous constatez un incident de sécurité impliquant une ressource de la fédération, | + | |
- | * Inversement, | + | |
- | + | ||
- | 2. La possibilité pour un gestionnaire de SP de restreindre l’authentification uniquement aux IdPs attestant également d’une conformité SIRTFI, via la mise en œuvre d’un filtrage spécifique (voir chapitre 5 ci-dessous pour plus de détails). | + | |
- | + | ||
- | \\ | + | |
- | + | ||
- | ===== 5. Mise en œuvre d’un filtrage SIRTFI côté SP ===== | + | |
- | + | ||
- | Côté Service Provider, il est possible de mettre en place un filtrage des utilisateurs basé sur SIRTFI. L’idée ici est de restreindre l’accès à une ressource uniquement aux utilisateurs authentifiés auprès d’un IdP conforme SIRTFI. | + | |
- | + | ||
- | D’un point de vue technique, ce filtrage pourra être réalisé de deux manières différentes : | + | |
- | - Soit par l’application directement (en utilisant la logique de contrôle d’accès de l’application) ; | + | |
- | - Soit via l’utilisation de la fonctionnalité de filtre offerte par le SP Shibboleth | + | |
- | + | ||
- | Dans les deux cas, il faudra au préalable récupérer // | + | |
- | + | ||
- | === Récupération de l’Entity Attribute SIRTFI côté SP === | + | |
- | + | ||
- | Les attributs de type « //Entity Attribute// » sont listés dans les métadonnées de la fédération. | + | |
- | Ils peuvent être mappés au niveau du SP de manière identique à ce qu’il est possible de faire pour les attributs utilisateur délivrés par un IdP. | + | |
- | + | ||
- | Pour pouvoir utiliser les attributs présents dans les métadonnées, | + | |
- | + | ||
- | <code xml shibboleth2.xml> | + | |
- | < | + | |
- | metadataAttributePrefix=" | + | |
- | </ | + | |
- | + | ||
- | Supposons qu’un //entity attribute// SIRTFI soit renseigné pour un IdP dans les métadonnées : | + | |
- | <code xml> | + | |
- | < | + | |
- | < | + | |
- | NameFormat=" | + | |
- | Name=" | + | |
- | < | + | |
- | </ | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | Il est alors possible de définir un mapping de cet attribut au niveau du SP, dans le fichier// attribute-map.xml//, | + | |
- | + | ||
- | <code xml attribute-map.xml> | + | |
- | < | + | |
- | </ | + | |
- | + | ||
- | Ce qui permet à la valeur de l’attribut défini ci-dessus d’être disponible au travers de la variable **md_sirtfi**. | + | |
- | \\ \\ | + | |
- | + | ||
- | === Contrôle d’accès réalisé directement par l’application === | + | |
- | + | ||
- | Une fois la variable **md_sirtfi** récupérée au niveau du SP, la valeur associée peut être passée à l’application. | + | |
- | + | ||
- | Si vous avez la possibilité de modifier le code source | + | |
- | \\ \\ | + | |
- | + | ||
- | === Contrôle d’accès basé sur l’utilisation de la fonctionnalité de filtre du SP Shibboleth | + | |
- | + | ||
- | Comme solution alternative, | + | |
- | + | ||
- | Au niveau d’Apache, cela requiert de définir un élément directory (/ | + | |
- | + | ||
- | < | + | |
- | < | + | |
- | AuthType shibboleth | + | |
- | ShibRequestSetting requireSession 1 | + | |
- | ShibAccessControl / | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | La configuration du filtre du SP Shibboleth est défini au travers du fichier / | + | |
- | + | ||
- | __Exemple de filtre simple vérifiant que l’utilisateur est un étudiant authentifié sur un IdP Sirtfi :__ | + | |
- | + | ||
- | < | + | |
- | < | + | |
- | < | + | |
- | <Rule require=" | + | |
- | < | + | |
- | </ | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | L’exemple ci-dessus reste assez basique mais il est possible d’implémenter des règles de contrôle d’accès plus complexes. Plus de détails dans la documentation Shibboleth: \\ https:// | + | |
- | + | ||
- | \\ | + | |
- | + | ||
- | ===== 6. Annexe : Balises SIRTFI ===== | + | |
- | + | ||
- | === 6.1 SIRTFI Entity Attribute === | + | |
- | + | ||
- | La conformité SIRTFI est exprimée via l’utilisation de l’// | + | |
- | + | ||
- | < | + | |
- | < | + | |
- | < | + | |
- | < | + | |
- | < | + | |
- | NameFormat=" | + | |
- | Name=" | + | |
- | < | + | |
- | </ | + | |
- | </ | + | |
- | </ | + | |
- | ... | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | === 6.2 SIRTFI Security Contact === | + | |
- | + | ||
- | Un contact de sécurité est ajouté pour chaque entité attestant d’une conformité SIRTFI, comme illustré ci-dessous : | + | |
- | + | ||
- | < | + | |
- | < | + | |
- | contactType=" | + | |
- | remd: | + | |
- | xmlns: | + | |
- | < | + | |
- | < | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | + |