Autres exigences SAML 2.0

L'intégration d'une application compatible SAML 2.0 dans le service eIAM requiert une connaissance approfondie du protocole SAML 2.0 et de l'application à intégrer. L'application doit être adaptée au service eIAM. eIAM sera configuré en fonction du dossier. Les adaptations personnalisées de l'eIAM pour l'utilisation unique d'une application sont hors de portée.

Profils SAML, bindings, subject confirmation type supportés

Tout ce qui n'est pas explicitement défini comme supporté ci-dessous n'est PAS supporté par le Service eIAM.

Profils SAML 2.0 pris en charge par eIAM-Web PEP
Le tableau ci-dessous présente les profils SAML 2.0 à utiliser par les acteurs du service eIAM.


Acteur Web Browser SSO Profile Single Logout Profile
Application utilisant RP-PEP DOIT DOIT
Application utilisant l'intégration standard (STS-PEP) DOIT PEUT

Bindings SAML 2.0 supportés par eIAM PEP
Du point de vue de l'application, eIAM supporte les bindings SAML 2.0 suivants:

  • HTTP POST Binding pour SAML AuthnRequests et SAML Responses
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Type de confirmation de sujet supporté par eIAM PEP
Du point de vue de l'application, eIAM prend en charge les types de confirmation de sujet suivants:
  • Bearer
    • urn:oasis:names:tc:SAML:2.0:cm:bearer

Signatures et cryptages

Le tableau suivant donne un aperçu des exigences en matière de signatures numériques et de cryptage au niveau des messages. Indépendamment de cela, les déclarations ne peuvent généralement être transmises qu'avec un cryptage au niveau de la couche de transport (HTTPS).

Communication Profil SAML Signature numérique                                        Cryptage au niveau du message            
Application → eIAM SAML Endpoint Web-SSO Profile (Login)AuthnRequest : non obligatoire (1) AuthnRequest : NE DOIT PAS
eIAM SAML Endpoint → Application Web-SSO Profile (Login)Réponse : OBLIGATOIR
Assertion : non obligatoire (2) 		Réponse : NE DOIT PAS
Assertion : NE DOIT PAS
Single Logout ProfileLogoutRequest : OBLIGATOIR
LogoutResponse : non obligatoire 		LogoutRequest : NE DOIT PAS
LogoutResponse : NE DOIT PAS
Single Logout ProfileLogoutRequest : OBLIGATOIR
LogoutResponse : non obligatoire (3) 		LogoutRequest : NE DOIT PAS
LogoutResponse : NE DOIT PAS
(1) La signature de l'AuthnRequest est facultative, mais recommandée. Elle permet d'éviter les CSRF (Cross Site Request Forgery). En effet, la signature garantit que l'eIAM n'accepte que les AuthnRequests qui ont été réellement émises par l'application.
(2) Ce n'est pas obligatoire, mais eIAM signe également les assertions.
(3) eIAM signe les LogoutResponses dans tous les cas.

x509 Keymaterial pour la signature des messages SAML

Pour signer les messages SAML, le projet doit fournir un certificat.
Les exigences suivantes s'appliquent:
  • Chaque environnement (REF, ABN, PROD) DOIT avoir un certificat dédié
  • Longueur de clé : DOIT être d'au moins 2048 bits
  • La période de validité du certificat DOIT être comprise entre 1 et 3 ans
  • Les certificats émis DOIVENT avoir un "Key Usage" pour la signature
  • Pour les applications au sein de l'administration fédérale, les certificats DOIVENT être délivrés par la Swiss Government PKI (SG-PKI) et être de type "Class-C" ou "Class-E"
  • Pour toutes les autres applications, les certificats DEVRAIENT utiliser des certificats SG-PKI, mais d'autres sont également autorisés
Il est recommandé de les commander à un stade précoce du projet.

Matériel clé nécessaire et son utilisation
Matériel clé nécessaire et son utilisation


Exigences en matière de KeyInfo

Selon la spécification SAML 2.0, il existe différentes possibilités pour identifier la clé publique à utiliser pour la vérification de la signature des structures SAML.

eIAM utilise l'élément KeyInfo, qui DOIT être présent dans chaque message SAML signé. KeyInfo DOIT contenir le certificat X.509 de la paire de clés avec laquelle le message SAML a été signé.


Configuration SAML 2.0 (métadonnées)

Remplacement du matériel de la clé x509

L'échange des clés publiques (certificats) a lieu pour la première fois lors de l'intégration de l'application. Habituellement, l'application et l'eIAM fournissent leur fichier de métadonnées au système homologue. Pour plus de détails, veuillez consulter

Configuration SAML 2.0 (métadonnées)
.
Échange réciproque de certificats Signer pour la vérification de la signature
Échange réciproque de certificats Signer pour la vérification de la signature


  • eIAM met à disposition de l'application la clé publique (certificat) du eIAM-Web PEP Signer dans son rôle de fournisseur d'identité, afin que celui-ci puisse vérifier la signature des messages SAML qu'il émet.
  • L'application met à disposition du PEP eIAM-Web la clé publique (certificat) de l'Application Signer dans son rôle de fournisseur de services, afin que celui-ci puisse vérifier la signature des messages SAML qu'elle émet.

Renouvellement du matériel clé

Le matériel clé DOIT être renouvelé aussi bien par l'application que par le PEP en fonction de la durée de validité des certificats. eIAM est conçu de manière à ce qu'une exploitation parallèle puisse fonctionner avec plusieurs clés publiques (l'ancienne et la nouvelle) pour la vérification de la signature de l'application. De même, l'application DOIT être techniquement capable de détenir plusieurs certificats pour la vérification des signatures de l'eIAM. CCela permet de renouveler les certificats pour la vérification de la signature sans qu'il y ait de défaillance des applications et sans que les certificats et les clés privées des parties adverses doivent être renouvelés exactement au même moment.

L'exploitant de l'application et l'exploitant de l'eIAM DOIVENT s'informer mutuellement à temps du renouvellement du matériel de clé. Les processus d'exploitation concernant l'information du site distant et l'échange des clés DOIVENT être réglés par le projet (client) avant la mise en production de l'application.