SAML 2.0 modèle d'intégration RP-PEP
Ce modèle d'intégration (RP-PEP) ne peut être choisi que pour les services au sein de BV-Net. Il offre une sécurité plus élevée et est nécessaire lorsque votre niveau de protection est élevé (Si00
Intégration SAML 2.0
L'illustration ci-dessous montre de manière simplifiée le déroulement et les composants impliqués de l'accès d'un utilisateur non encore authentifié à une application web, qui est protégée par le composant web eIAM (PR-PEP). Les différentes étapes sont décrites ci-dessous.-
- Accès utilisateur à une ressource protégée
| N° | Action | Description |
|---|---|---|
| 1 | Utilisateur tente d'accéder à la ressource protégée d'une application web | L'eIAM-Web PEP détecte que la ressource à laquelle on veut accéder est protégée et que l'accès est effectué par un utilisateur qui n'est pas encore authentifié |
| 2 | SAML AuthnRequest au navigateur web de l'utilisateur | Le eIAM-Web PEP émet une requête Authn signée SAML 2.0 à l'attention du eIAM Trustbroker et l'envoie au navigateur web de l'utilisateur sous forme de formulaire auto-transmissible. |
| 3 | SAML AuthnRequest au eIAM Trustbroker | Le navigateur de l'utilisateur envoie automatiquement le formulaire au eIAM Trustbroker par Brow-ser POST au moyen de Java Script. |
| 4 | Home Realm Discovery et SAML AuthnRequest au navigateur web de l'utilisateur | Le eIAM Trustbroker exécute une Home Realm Discovery (détermination de l'IdP à utiliser) et détermine l'IdP à utiliser pour l'authentification. L'eIAM Trustbroker émet une demande d'authentification SAML 2.0 signée à l'attention de l'IdP et l'envoie au navigateur web de l'utilisateur sous forme de formulaire auto-transmis. |
| 5 | SAML AuthnRequest à l'IdP | Le navigateur de l'utilisateur envoie automatiquement le formulaire à l'IdP par Browser POST au moyen de Java Script. |
| 6 | Authentification de l'utilisateur | L'IdP procède à une authentification de l'utilisateur qui varie selon les caractéristiques. Si l'authentification est réussie, l'IdP crée une réponse SAML qui contient une assertion signée avec des indications sur le sujet et les attributs du sujet (également appelés revendications). |
| 7 | SAML Response au navigateur web de l'utilisateur | L'IdP envoie la SAML Response au navigateur web de l'utilisateur sous la forme d'un formulaire auto-transmis. |
| 8 | SAML Response à l'eIAM Trustbroker | Le navigateur de l'utilisateur envoie automatiquement le formulaire à l'eIAM Trustbroker via le navigateur POST en utilisant Java Script. Le Trustbroker eIAM recherche le sujet de l'assertion SAML dans l'AM eIAM. L'eIAM Trustbroker enrichit l'assertion SAML de l'IdP avec d'autres attributs (par ex. l'ID utilisateur et les rôles d'autorisation) de l'eIAM-AM et crée une réponse SAML avec une assertion SAML à l'attention de l'eIAM-Web PEP. |
| 9 | SAML Response au navigateur web de l'utilisateur | Le Trustbroker eIAM envoie la SAML Response au navigateur web de l'utilisateur sous forme de formulaire auto-transmis. |
| 10 | SAML Response à eIAM-Web PEP | Le navigateur de l'utilisateur envoie automatiquement le formulaire à eIAM-Web PEP par Browser POST au moyen de Java Script. |
| 11 | Vérification de l'assertion SAML et redirection vers RelayState | L'eIAM-Web PEP vérifie la réponse SAML et l'assertion. En cas de succès, l'eIAM-Web PEP crée une session avec l'utilisateur. L'eIAM-Web PEP redirige l'utilisateur vers l'URL du RelayState. Il s'agit de l'URL à laquelle l'utilisateur a accédé à l'origine (avant l'authentification). Avec cette réponse, un cookie de session est émis, avec lequel la session entre le client et le PEP est suivie. |
| 12 | Le navigateur web de l'utilisateur tente à nouveau d'accéder à la ressource protégée de l'application web | Il existe maintenant une session avec l'utilisateur pour cette requête. Le PEP vérifie si l'utilisateur est autorisé à accéder à cette ressource et, en cas de succès, transmet la re-quête de l'utilisateur à l'application. |
| 13 | L'application vérifie l'autorisation de l'utilisateur | L'application reconnaît que l'utilisateur veut accéder à une zone protégée, mais que, de son point de vue, l'utilisateur n'est pas encore authentifié. L'application établit une AuthnRequest SAML 2.0 signée à l'attention du PEP et l'envoie au navigateur web de l'utilisateur sous forme de formulaire auto-transmis. |
| 14 | SAML AuthnRequest au PEP | Le navigateur de l'utilisateur envoie automatiquement le formulaire au PEP eIAM-Web par Browser POST au moyen de Java Script. |
| 15 | SAML Assertion pour l'application | L'eIAM-Web PEP vérifie la SAML AuthnRequest entrante et la relie à la session existante de l'utilisateur via le cookie de session. L'eIAM-Web PEP émet une réponse SAML avec une assertion à l'intention de l'application et l'envoie au navigateur web de l'utilisateur sous forme de formulaire auto-transmis. |
| 16 | SAML Response à l'application | Le navigateur de l'utilisateur envoie automatiquement le formulaire à l'application par Brow-ser POST au moyen de Java Script |
| 17 | Vérification de l'assertion SAML et redirection vers RelayState | L'application vérifie la SAML Response et l'assertion. En cas de succès, l'application crée une session avec l'utilisateur. L'application redirige l'utilisateur vers l'URL du RelayState. Il s'agit de l'URL à laquelle l'utilisateur a accédé à l'origine (avant l'authentification). Avec cette réponse, un cookie de session est émis, avec lequel la session entre le client et l'application est suivie. |
| 18 | Le navigateur web de l'utilisateur tente à nouveau d'accéder à la ressource protégée de l'application web | L'eIAM-Web PEP laisse passer la requête sur l'application, car il existe une session valable et l'utilisateur possède le rôle d'autorisation grossièrement granulaire nécessaire. L'application autorise la requête, car il existe une session valide et l'utilisateur possède le rôle à granularité fine nécessaire pour effectuer l'opération souhaitée sur l'application. |
| 19 | Réponse au navigateur web de l'utilisateur | L'application envoie la réponse au navigateur web de l'utilisateur. |