Configuration de la session SAML 2.0 avec RP-PEP

1. La session entre le navigateur web de l'utilisateur et le RP-PEP.
2. La session entre le RP-PEP et l'application.

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

Service Provider initiated Web SSO - Introduction
Du point de vue de l'utilisateur, le RP-PEP forme avec l'application derrière le RP-PEP un Service Provider (SP) SAML. La requête initiale de l'utilisateur est envoyée à ce Service Provider sans que l'utilisateur ne se soit préalablement authentifié. Le RP-PEP décide, via la politique définie, si une authentification préalable de l'utilisateur est nécessaire pour le traitement et la transmission de la requête. Le RP-PEP, en tant que SP SAML, initie l'authentification si nécessaire. Nous parlons également de ce que l'on appelle un scénario Service Provider initiated ou, en bref, "SP First".

Déroulement du Service Provider initiated Web SSO
L'illustration ci-dessous montre le déroulement du contexte de sécurité (session SSO) sur le RP-PEP dans l'architecture ouverte avec les acteurs impliqués. Le RP-PEP ne gère lui-même aucune information sur l'utilisateur. Il délègue l'authentification de l'utilisateur au eIAM Trustbroker en tant que Federation Provider (FP), qui à son tour délègue l'authentification de l'utilisateur à un Identity Provider (FI) défini pour l'application appelée. Le Trustbroker eIAM a accès au Attribut Provider (AP) eIAM-AM, qui détient les rôles et autres attributs de l'utilisateur nécessaires à la gestion des accès.

L'établissement de la session entre l'application et RP-PEP est décrit ci-après sous "Établissement de la session entre l'application et RP-PEP".

Structure de la session du navigateur web PEP

1. L'utilisateur non authentifié appelle l'URL de l'application web sur RP-PEP. La requête est "interceptée" par RP-PEP.
2. Le RP-PEP constate qu'un contexte de sécurité est nécessaire pour la requête, mais qu'il n'en existe pas. Le RP-PEP détermine, par le biais de la politique enregistrée, que l'utilisateur qui fait la demande doit être authentifié et qu'une certaine autorisation est nécessaire pour l'accès.
3. Le RP-PEP émet une requête SAML 2.0 AuthnRequest qui est envoyée au navigateur web de l'utilisateur sous une forme HTML auto-subordonnée avec la destination eIAM Trustbroker. Avec cette forme, l'URL que l'utilisateur a initialement appelée est indiquée dans un autre paramètre RelayState, afin que celui-ci puisse être redirigé vers cette URL par le PEP après une authentification réussie. En outre, un cookie temporaire est défini pour suivre les requêtes de ce client.
4. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML avec l'AuthnRequest au Trustbroker eIAM via Java Script.
5. Le Trustbroker eIAM vérifie si l'AuthnRequest provient d'un émetteur avec lequel il existe une relation de confiance.
6. Si la vérification de l'AuthnRequest est réussie, l'eIAM Trustbroker envoie à l'utilisateur un formulaire HTML avec le choix des FI disponibles pour l'authentification.
7. L'utilisateur envoie la sélection d'FI à l'eIAM Trustbroker.
8. Le Trustbroker émet une requête SAML 2.0 AuthnRequest qui est envoyée au navigateur web de l'utilisateur dans un formulaire HTML auto-soumis avec l'FI de destination.
9. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML avec l'AuthnRequest au fournisseur d'identité (FI) via Java Script.
10. Le fournisseur d'identité vérifie si l'AuthnRequest provient d'un émetteur avec lequel il existe une relation de confiance.
11. Si la vérification de l'AuthnRequest est positive, l'FI procède à l'authentification de l'utilisateur.
12. L'utilisateur est authentifié par le fournisseur d'identité - Le déroulement de l'authentification dépend de l'FI choisi et ne fait pas partie du champ d'application de cette description.
13. -Vérifier le(s) moyen(s) d'authentification sur l'FI - Le déroulement détaillé de l'authentification dépend de l'FI choisi et ne fait pas partie de la portée de ce guide.
14. Après une authentification réussie de l'utilisateur, l'FI émet une réponse SAML 2.0 avec une assertion. La réponse SAML est envoyée au navigateur web de l'utilisateur sous une forme HTML auto-subordonnée.
15. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML avec la réponse SAML au Trustbroker eIAM via Java Script.
16. Le Trustbroker eIAM vérifie la réponse SAML entrante et consomme les attributs qu'elle contient.
17. Le Trustbroker recherche l'utilisateur authentifié par le fournisseur d'identité dans l'eIAM-AM et lui demande des attributs supplémentaires qui sont gérés par l'utilisateur dans l'eIAM-AM, comme l'ID utilisateur, l'appartenance à un service, les rôles d'autorisation, etc.
18. Le Trustbroker émet une réponse SAML 2.0 avec une assertion qui contient des attributs provenant d'une part du fournisseur d'identité et d'autre part de l'AM eIAM.
19. La réponse SAML est envoyée au navigateur web de l'utilisateur sous une forme HTML auto-soumise.
20. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML avec la SAML Response au PEP par Java Script.
21. Le RP-PEP vérifie la SAML Response reçue et l'assertion qu'elle contient. Si la vérification est réussie, les attributs de l'assertion sont consommés par le PEP et un contexte de sécurité (session) est créé.
22. Le RP-PEP envoie au navigateur web de l'utilisateur une redirection HTTP vers l'URL initialement appelée par l'utilisateur (URL du RelayState). Avec cette réponse HTTP, un cookie de session permanent (pour la durée de la session de navigation) du RP-PEP est placé sur le navigateur de l'utilisateur.
23. Le navigateur web de l'utilisateur appelle l'URL vers laquelle il a été redirigé.
24. Le RP-PEP vérifie si la politique définie est respectée. Pour cela, la requête doit provenir d'un utilisateur authentifié, l'authentification doit avoir été effectuée avec la force nécessaire pour l'accès à cette ressource et l'utilisateur doit avoir le rôle granulaire nécessaire pour l'accès à la ressource. Si la vérification est réussie, le RP-PEP transmet la requête à l'application.

Structure de la session entre l'application et RP-PEP

SP initiated Web SSO - Introduction
Lors du traitement de la première requête dans l'application, celle-ci 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 dans le langage courant "SP-First".

Remarque:
L'application ne peut pas forcer la réauthentification de l'utilisateur d'une session PEP en cours via le RP-PEP (en définissant l'attribut 'ForceAuthn' dans AuthnRe-quest).

SP initiated Web SSO - Déroulement
Nous décrivons ci-après la mise en place du contexte de sécurité (session) entre l'application compatible SAML 2.0 au sein des réseaux de l'administration fédérale et le RP-PEP. La situation de départ est une session de l'utilisateur déjà existante sur le RP-PEP. Du point de vue de l'application, le PEP joue le rôle de fournisseur d'identité SAML 2.0 (FI). Du point de vue du RP-PEP, l'application est un fournisseur de services SAML 2.0 (SP). Si plusieurs applications sont intégrées derrière le RP-PEP, chacune des applications doit établir pour elle-même un contexte de sécurité avec le déroulement décrit, si un tel contexte est requis par l'application.

Session Structure de l'application-PEP

1. Requête de l'utilisateur dans une session déjà établie sur le RP-PEP.
   
2. Requête transmise à l'application.
3. L'application vérifie la requête et constate qu'un contexte de sécurité (session) est nécessaire mais qu'il n'existe pas encore.
4. L'application crée une demande SAML 2.0 AuthnRequest et la transmet au RP-PEP dans un formulaire HTML auto-soumis.
   
5. Le RP-PEP transmet la requête SAML 2.0 AuthnRequest au navigateur web de l'utilisateur.
6. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML par Java Script à l'URL définie dans le formulaire sur l'eIAM-Web PEP.
7. Le PEP RP vérifie l'AuthnRequest et, si la vérification est réussie, crée une réponse SAML 2.0 qui contient une assertion avec des informations sur l'utilisateur (sujet) et des attributs. La source de ces informations est la session existante de l'utilisateur sur le RP-PEP.
8. La réponse SAML est compressée dans un formulaire HTML auto-soumis et envoyée au navigateur web de l'utilisateur.
9. Le navigateur web de l'utilisateur envoie automatiquement le formulaire HTML par Java Script à la destination définie dans le formulaire sur le PEP eIAM-Web. L'URL à laquelle ce formulaire doit être envoyé est l'URL de l'Assertion Consumer Service de l'application tel qu'il peut être atteint via le RP PEP.
10. Le RP-PEP envoie le formulaire HTML à l'URL de l'Assertion Consumer Service de l'application.
11. L'application vérifie la réponse SAML 2.0 ainsi que l'assertion et crée un contexte de sécurité (session) en cas de succès.
12. L'application redirige le navigateur web de l'utilisateur vers l'URL du RelayState ou vers un autre URI qu'elle a défini. Avec cette réponse, l'application place un cookie de session qui est mis en cache sur le RP-PEP (les cookies de l'application sont mis en cache par défaut sur le RP-PEP et échangés uniquement entre le RP-PEP et l'application).
13. Le RP-PEP envoie la réponse au navigateur web avec la redirection de l'application.
14. Le navigateur web appelle l'URL sur laquelle il a été redirigé.
15. Le RP-PEP transmet la demande du navigateur web à l'application. Les cookies que l'application a installés lors des étapes précédentes sont également envoyés.
16. La réponse HTTP de l'application est envoyée au RP-PEP.
17. La réponse HTTP est envoyée par RP-PEP au navigateur web.
18. Et les requêtes suivantes se déroulent comme décrites aux points 14 - 17.

• 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 RP-PEP (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 RP-PEP. Ainsi, en cas de modification de l'application, aucune modification n'est nécessaire sur le RP-PEP.
• 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 RP-PEP.
• 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.