Configuration de la session SAML 2.0 avec STS-PEP

Structure de la session entre le navigateur web et le STS-PEP

SP initiated Web SSO - Introduction
Lors du traitement de la première requête dans l'application, l'application ne sait pas encore de quel utilisateur il s'agit, car aucun contexte de sécurité n'est encore établi. Il incombe donc à l'application de décider si un contexte de sécurité doit être établi pour l'accès choisi.

Si l'application décide qu'une authentification et une autorisation doivent être effectuées pour la demande, elle peut les initier au moyen du scénario "SP initiated Web SSO". Ce scénario est également appelé SAML "SP-First" dans le langage courant.

Avantages de SP initiated Web SSO
Le scénario SP initiated Web SSO a été choisi pour la connexion d'applications à eIAM, car il offre quelques avantages de poids par rapport à d'autres procédures (par ex. FI initiated Web SSO).

• La procédure est supportée par toutes les implémentations SAML 2.0 courantes et est bien documentée pour ces produits.
• La procédure permet à l'application de décider elle-même si un contexte de sécurité est nécessaire pour l'accès à la ressource, sans que l'enforcement de la politique sur le PEP STS (ne laisser passer que les demandes authentifiées et autorisées sur l'application) ne soit violé. Cette logique ne doit donc pas être implémentée de manière statique sur le PEP. Ainsi, en cas de modification de l'application, aucune modification n'est nécessaire sur le PEP STS.
• En cas de perte du contexte de sécurité sur l'application, par exemple en raison d'un time-out de session dans l'application ou d'un redémarrage de l'application, l'application peut, si nécessaire, demander à tout moment une nouvelle assertion SAML au PEP STS.
• Suppose qu'il n'y ait pas de connexion backchannel entre le fournisseur de services et le fournisseur d'identité, car la communication complète se fait via le navigateur de l'utilisateur. Ceci est particulièrement important pour les applications qui sont hébergées en dehors des réseaux de l'administration fédérale.

Mise en place de la session entre les applications et le STS-PEP

Déroulement
Le déroulement de l'établissement des sessions entre le navigateur web de l'utilisateur, le STS-PEP et les applications hébergées en dehors des réseaux de l'administration fédérale est décrit ci-dessous.

Session Mise en place d'applications en dehors des réseaux de l'administration fédérale

1. Le navigateur web de l'utilisateur appelle l'application.
2. L'application constate qu'une autorisation est nécessaire pour accéder à la ressource et vérifie s'il existe déjà une session avec l'utilisateur.
3. Comme il n'y a pas encore de session, l'application émet une requête SAML AuthnRequest signée par elle à l'attention du STS-PEP et l'intègre dans un formulaire HTML auto-transmis. De plus, l'URL demandée par l'utilisateur dans la requête initiale à l'étape 1 est indiquée dans le paramètre "RelayState", afin que le navigateur de l'utilisateur puisse être redirigé vers cette URL une fois l'authentification terminée.
4. Le navigateur Web envoie l'AuthnRequest par HTTP POST à l'URL SSO du STS-PEP.
   
5. Le STS-PEP vérifie la validité de la requête SAML AuthnRequest et si la requête provient d'une application qui lui est familière. Si c'est le cas, le STS-PEP vérifie s'il existe déjà une session avec le navigateur web de l'utilisateur.
6. Si le STS-PEP n'a pas encore de session avec le navigateur web de l'utilisateur, le STS-PEP émet de son côté une SAML AuthnRequest signée par ses soins à l'intention de l'eIAM Trustbroker. Celle-ci est intégrée dans un formulaire HTML à transmission automatique et transmise au navigateur web de l'utilisateur sous forme de réponse HTTP.
7. Le navigateur de l'utilisateur envoie la SAML AuthnRequest du STS-PEP par HTTP POST au eIAM-Trust Broker.
8. L'eIAM Trustbroker vérifie la validité de la requête SAML Authn et si elle provient d'un STS-PEP familier. Si c'est le cas, l'eIAM Trustbroker démarre ce que l'on appelle la "Home Realm Discovery". Il génère une liste des fournisseurs d'identité disponibles pour l'authentification de l'utilisateur. Cette liste peut être définie différemment pour les utilisateurs du réseau de l'administration fédérale et pour les utilisateurs en dehors des réseaux de l'administration fédérale.
9. Si plusieurs possibilités d'authentification sont disponibles dans la même zone de réseau, un choix s'affiche pour l'utilisateur.
10. L'utilisateur envoie le choix du fournisseur d'identité à utiliser au courtier eIAM-Trust par HTTP POST.
11. Le Trustbroker eIAM crée une demande d'authentification SAML signée par l'utilisateur à l'attention de l'FI choisi par ce dernier. Celle-ci est intégrée dans un formulaire HTML auto-transmis et transmise au navigateur web de l'utilisateur sous forme de réponse HTTP.
12. Le navigateur web de l'utilisateur envoie la requête SAML Authn du Trustbroker eIAM au fournisseur d'identité par HTTP POST.
    
13. Le fournisseur d'identité vérifie la validité de la requête SAML Authn et si elle provient d'un eIAM Trustbroker auquel il fait confiance. Si c'est le cas, l'FI procède à l'authentification de l'utilisateur.
    
14. Authentification sur l'FI. Le déroulement de l'authentification proprement dite varie d'un FI à l'autre et ne fait pas partie de cette description.
15. Après une authentification réussie de l'utilisateur, l'FI émet une réponse SAML à l'attention du Trustbroker eIAM. Cette réponse SAML contient une assertion avec des informations sur l'utilisateur et des attributs. La quantité et le type d'attributs peuvent varier d'un FI à l'autre. L'assertion dans la SAML Response est signée par l'FI. La SAML Response est intégrée dans un formulaire HTML à transmission automatique et transmise au navigateur web de l'utilisateur sous forme de réponse HTTP.
16. Le navigateur web de l'utilisateur envoie la réponse SAML au courtier eIAM-Trust par HTTP POST.
    
17. Le Trustbroker eIAM vérifie la réponse SAML et valide l'affirmation selon laquelle elle a été signée par un FI de confiance et n'a pas été modifiée ultérieurement.
    
18. Le Trustbroker eIAM recherche le sujet (utilisateur) déclaré par l'FI dans l'assertion SAML dans le super-mandant eIAM-AM à l'aide de la référence d'identité.
    
19. Si un utilisateur avec la référence d'identité correspondante a été trouvé dans le supermandant eIAM-AM, le compte de l'utilisateur est recherché dans le mandant eIAM-AM Access de l'office spécialisé qui administre les autorisations pour l'application spécialisée.
20. Le Trustbroker eIAM enrichit l'assertion SAML de l'FI avec d'autres attributs (par ex. rôles d'autorisation) provenant de la requête dans l'AM eIAM. L'eIAM Trustbroker crée une réponse SAML à l'attention du STS-PEP. La réponse contient une assertion SAML signée par le Trustbroker eIAM.
    
21. La SAML Response est intégrée dans un formulaire HTML auto-transmis et envoyée au navigateur Web de l'utilisateur sous forme de réponse HTTP.
    
22. Le navigateur Web envoie la réponse SAML au STS-PEP par HTTP POST.
    
23. Le STS-PEP vérifie la validité de la SAML Response et valide l'assertion selon laquelle elle provient d'un eIAM Trustbroker auquel il fait confiance. Il vérifie également que la signature n'a pas été modifiée après sa signature. Si la vérification est positive, le STS-PEP crée une session avec le navigateur web de l'utilisateur. Les attributs de l'utilisateur sont enregistrés dans la session sur le STS-PEP en vue d'une réutilisation ultérieure. Pour suivre cette session, un cookie de session est émis. Le STS-PEP crée une réponse SAML avec une assertion qu'il a signée. Cette assertion contient les attributs de l'utilisateur qu'il a reçus de l'FI et de l'eIAM-AM.
24. La réponse SAML est intégrée dans un formulaire HTML auto-transmis et envoyée au navigateur web de l'utilisateur sous forme de réponse HTTP.
25. Le navigateur Web envoie la réponse SAML à l'application via HTTP POST. Le paramètre "RelayState" est également transmis à cette occasion.
26. L'application vérifie la validité de la SAML Response et valide l'assertion qu'elle contient, en s'assurant qu'elle a été émise par un STS-PEP auquel elle fait confiance et qu'elle n'a pas été modifiée ultérieurement après la signature. L'application crée une session avec le navigateur web de l'utilisateur. Dans la session, elle exécute les attributs de l'utilisateur (Claims) de l'assertion SAML.
27. Avec la réponse HTTP, l'application envoie au navigateur web une redirection vers l'adresse enregistrée dans le "RelayState". Le navigateur web est ainsi renvoyé à l'URL demandée à l'étape 1. Avec cette réponse HTTP, l'application place un cookie de session pour suivre la session du navigateur Web.
    
28. Le navigateur Web appelle l'adresse de l'application vers laquelle il a été redirigé.
    
29. Puisqu'il existe une session entre le navigateur Web et l'application, et que le contrôle de l'autorisation de l'utilisateur est positif, la ressource demandée est renvoyée à l'utilisateur sous forme de réponse HTTP.
30. Cette séquence montre l'accès du même utilisateur avec le même navigateur web à une deuxième application dans le même domaine SSO (les deux applications utilisent le même STS-PEP). Les étapes sur le Trustbroker eIAM et l'FI ne sont pas nécessaires. Comme il existe déjà une session SSO sur le STS-PEP, celui-ci peut émettre directement une SAML Assertion à l'intention de l'application.