SP et IdP SSO initié

Cet article traite des concepts de SP et de IdP SSO initié entre deux déploiements de fédération, ainsi que des différences entre ces deux flux.

Cet article explique également le concept d'un état utilisateur ou d'une URL de retour partagée entre IdP et le SP lors de l'accès avec connexion unique (SSO) Federation, qui est appelée :

• RelayState pour SAML 2.0 TARGET pour SAML 1.1 wctx pour WS-Fed 1.1

• openid.return_to pour OpenID 2.0 (SSO de retour)

• L'URL peut contenir un paramètre de requête représentant l'état de l'utilisateur au niveau du SP)

Cet article présente des exemples utilisant le protocole SAML 2.0, bien que la même chose s'applique aux autres protocoles.

Flux SSO de fédération

Topologie

Un déploiement de fédération classique comprend les entités suivantes :

• Un domaine de sécurité pour le serveur IdP, où l'utilisateur dispose d'un compte et où l'authentification a lieu

• Un domaine de sécurité pour le serveur SP avec

  • Un serveur SP Federation

  • Un serveur SSO (parfois, le serveur SSO et le serveur SP Federation constituent la même entité)

  • Les agents Web SSO intégrés au serveur SSO protègent les ressources et s'assurent que l'utilisateur est authentifié et autorisé à accéder à une ressource. Si vous ne le faites pas, un flux d'authentification ou un échec d'autorisation peut survenir

  • Ressources ou applications Web

  

  Description de l'image Federation_deployment_Screen.jpg

SSO initié par le fournisseur de services

Un flux SSO initié par le fournisseur de services est une opération SSO de fédération démarrée à partir du domaine de sécurité du fournisseur de services. Le serveur SP Federation crée une demande d'authentification de fédération et redirige l'utilisateur vers IdP avec le message et une chaîne courte représentant l'état de l'opération :

• La demande d'authentification de fédération varie en fonction du protocole utilisé :

  • SAML 2.0 : AuthnRequest

  • SAML 1.1 : URL avec un paramètre représentant le fournisseur de services

  • WS-Fed : URL avec un paramètre wtrealm représentant le SP et d'autres paramètres facultatifs

  • OpenID 2.0 : Demande OpenID 2.0

• L'état de l'opération (ce que l'utilisateur faisait avant le démarrage de l'opération SSO de fédération) est transmis dans le message envoyé à IdP avec l'utilisateur, non comme l'état complet, mais plutôt comme un pointeur vers l'état dans le stockage d'exécution du serveur SP. Ces informations sont véhiculées différemment selon le protocole :

  • SAML 2.0 : paramètre RelayState

  • SAML 1.1 : Paramètre TARGET

  • WS-Fed : paramètre wctx

  • OpenID 2.0 : paramètre openid.return_to qui est une URL de fournisseur de services dans laquelle l'utilisateur est redirigé après authentification au niveau de IdP, qui est généré lors de l'exécution par le fournisseur de services et peut donc contenir un paramètre de requête référençant un état opérationnel

Remarque sur l'état opérationnel : En général, l'état partagé dans le message ne doit pas être trop long car il risque de casser les flux de réacheminement car la longueur de l'URL de réacheminement dépasse la longueur maximale que les navigateurs peuvent gérer pour les URL. En tant que tel, il est toujours préférable que le SP ait le statut SSO initié par le SP

• Stocker l'état opérationnel en mémoire/stockage de base de données sur le SP

• Envoyer en tant que RelayState/TARGET/wctx un pointeur vers l'état opérationnel

Il existe deux façons de déclencher un flux SSO initié par le fournisseur de services :

• L'utilisateur demande l'accès à une ressource, ce qui démarre un flux SSO de fédération. Une fois l'opération SSO de fédération effectuée, l'utilisateur est redirigé vers la ressource demandée.

• Ou l'utilisateur accède directement à un service sur le serveur SP pour démarrer spécifiquement un flux SSO de fédération avec un IdP distant. Dans ce cas, l'utilisateur fournit généralement l'URL vers laquelle il doit être redirigé une fois l'opération SSO de fédération effectuée.

Accéder à une ressource

Il s'agit du flux le plus courant pour les opérations SSO de fédération, où l'utilisateur tente d'accéder à une ressource protégée. Lors de l'exécution, le système SSO détermine que l'utilisateur doit être authentifié via SSO de fédération.

Les cas d'utilisation de ce flux peuvent être les suivants :

• L'utilisateur clique sur un lien dans une page faisant référence à la ressource protégée

• L'utilisateur clique sur un lien d'une page de portail faisant référence à la ressource protégée

• L'utilisateur dispose d'un signet pour la ressource protégée

Le flux comprend les étapes suivantes :

1. Le navigateur de l'utilisateur demande l'accès à une ressource protégée

2. L'agent Web SSO intercepte l'appel, détermine que l'utilisateur doit être authentifié et renvoie une redirection vers le navigateur de l'utilisateur.

3. Le navigateur de l'utilisateur accède au serveur SSO, étant redirigé par l'agent Web SSO

4. Le serveur SSO détermine que l'utilisateur doit être authentifié via SSO de fédération, sélectionne IdP, crée un message SAML 2.0 AuthnRequest, enregistre l'état opérationnel dans la banque du serveur SSO et redirige le navigateur de l'utilisateur vers IdP avec le message SAML et une chaîne référençant l'état opérationnel au niveau du SP

5. Le navigateur de l'utilisateur accède au service SAML 2.0 IdP avec le message AuthnRequest.

Description de l'image Accessing_Resources_Screen.jpg

Une fois que IdP a reçu le message SAML 2.0 AuthnRequest, le serveur détermine si l'utilisateur doit faire l'objet d'une question de vérification (pas encore authentifié, la session a expiré...). Une fois l'utilisateur identifié, le flux SSO de fédération reprend.

1. L'élément IdP crée une réponse SSO avec une assertion SAML 2.0 contenant des informations utilisateur ainsi que des données d'authentification, et redirige le navigateur de l'utilisateur vers le fournisseur de services avec le message et le paramètre RelayState

2. Le navigateur de l'utilisateur présente la réponse SSO au serveur SP

3. Le fournisseur de services valide l'assertion SAML 2.0 et crée une session SSO pour l'utilisateur. Le serveur SSO redirige ensuite le navigateur de l'utilisateur vers la ressource initialement demandée.

4. Le navigateur de l'utilisateur demande l'accès à la ressource. Cette fois, l'agent Web SSO accorde l'accès à la ressource

5. L'application Web renvoie une réponse au navigateur de l'utilisateur

Description de l'image Accessing_Resources_Response_Screen.jpg

Comme indiqué précédemment, ce flux est le plus couramment utilisé, car le SSO de fédération est déclenché uniquement par le serveur SSO lors de l'exécution, sans que d'autres composants du domaine de sécurité du SP n'aient besoin de connaître la fédération.

Appel d'un service SP de fédération

Ce flux n'est pas très utilisé car il implique que le SSO de fédération sera démarré sur le SP en accédant à un service sur le serveur SP et en ignorant toute session valide existante que l'utilisateur pourrait déjà avoir. Cela doit être évité car cela a un impact sur les performances :

• Les serveurs de fédération SSO sont coûteux (XML pour certains protocoles, signatures numériques pour protéger les messages, communications entre serveurs)

• L'expérience de l'utilisateur en tant que navigateur sera redirigée sur différents domaines, ce qui entraînera un délai avant que l'utilisateur puisse accéder à la ressource protégée ciblée.

Les cas d'utilisation de ce flux peuvent être les suivants :

• L'utilisateur clique sur un lien de n'importe quelle page faisant référence à la ressource protégée (habituelle)

• L'utilisateur clique sur un lien d'une page de portail faisant référence à la ressource protégée

Les cas d'emploi dans lesquels ce flux est utilisé impliquent les étapes suivantes :

1. Le navigateur de l'utilisateur accède au SP pour démarrer un flux SSO de fédération en indiquant éventuellement

   1. URL vers laquelle le navigateur de l'utilisateur doit être redirigé une fois l'authentification SSO de fédération terminée

   2. IdP à utiliser

2. Le serveur SSO sélectionne IdP s'il n'est pas fourni et sélectionne l'URL de retour par défaut si elle n'est pas fournie, crée un message SAML 2.0 AuthnRequest, enregistre l'état opérationnel dans la banque du serveur SSO et redirige le navigateur de l'utilisateur vers IdP avec le message SAML et une chaîne référençant l'état opérationnel au niveau du SP

3. Le navigateur de l'utilisateur accède au service SAML 2.0 IdP avec le message AuthnRequest.

Description de l'image IdP_Service_with_AuthnRequest_Screen.jpg

Une fois que IdP a reçu le message SAML 2.0 AuthnRequest, le serveur détermine si l'utilisateur doit faire l'objet d'une question de vérification (pas encore authentifié, la session a expiré...). Une fois l'utilisateur identifié, le flux SSO de fédération reprend :

1. L'élément IdP crée une réponse SSO avec une assertion SAML 2.0 contenant des informations utilisateur ainsi que des données d'authentification, et redirige le navigateur de l'utilisateur vers le fournisseur de services avec le message et le paramètre RelayState

2. Le navigateur de l'utilisateur présente la réponse SSO au serveur SP

3. Le fournisseur de services valide l'assertion SAML 2.0 et crée une session SSO pour l'utilisateur. Le serveur SSO redirige ensuite le navigateur de l'utilisateur vers la ressource initialement demandée.

4. Le navigateur de l'utilisateur demande l'accès à la ressource. Cette fois, l'agent Web SSO accorde l'accès à la ressource

5. L'application Web renvoie une réponse au navigateur de l'utilisateur

Description de l'image IdP_Service_with_Response_Screen.jpg

Ce flux doit être rarement utilisé, car le SSO de fédération est déclenché de manière statique, même si l'utilisateur dispose déjà d'une session SSO valide. En outre, cela implique que certains composants du domaine de sécurité du SP connaissent le service du SP.

IdP SSO initié

Un flux SSO initié par IdP est une opération SSO de fédération démarrée à partir du domaine de sécurité IdP par le serveur Federation IdP, qui crée une réponse SSO de fédération et redirige l'utilisateur vers le SP avec le message de réponse et un état opérationnel facultatif :

• La réponse SSO de fédération varie en fonction du protocole utilisé :

  • SAML 2.0 : SAMLResponse avec assertion

  • SAML 1.1 : Réponse avec assertion

  • WS-Fed : réponse avec assertion

  • OpenID 2.0 : réponse OpenID 2.0

• L'état de fonctionnement facultatif dans ce flux transmet l'URL vers laquelle l'utilisateur doit être redirigé une fois que l'accès avec connexion unique (SSO) Federation est terminé au niveau du SP. S'il manque, le SP doit déterminer où l'utilisateur doit être redirigé. Ces informations sont véhiculées différemment selon le protocole :

  • SAML 2.0 : paramètre RelayState

  • SAML 1.1 : paramètre TARGET

  • WS-Fed : paramètre wctx OpenID 2.0 : ce protocole ne prend pas en charge le flux SSO initié par IdP.

Comme indiqué dans la section précédente, l'état partagé dans le message ne doit pas être trop long car il risque de casser les flux de redirection car la longueur de l'URL de redirection dépasse la longueur maximale que les navigateurs peuvent gérer pour les URL.

Ce flux est couramment utilisé lorsque les utilisateurs IdP ont besoin d'accéder aux ressources hébergées par un fournisseur de services, mais il ne s'agit pas de la meilleure approche pour l'accès avec connexion unique de fédération, car il ignore toute session valide existante au niveau du fournisseur de services que l'utilisateur peut déjà avoir. Cela doit être évité car cela a un impact sur les performances :

• Les serveurs de fédération SSO sont coûteux (XML pour certains protocoles, signatures numériques pour protéger les messages, communications entre serveurs)

• L'expérience de l'utilisateur en tant que navigateur sera redirigée sur différents domaines, ce qui entraînera un délai avant que l'utilisateur puisse accéder à la ressource protégée ciblée.

Les cas d'utilisation de ce flux peuvent être les suivants :

• L'utilisateur clique sur un lien d'une page de portail IdP référençant la ressource protégée sur le SP.

Les cas d'emploi dans lesquels ce flux est utilisé impliquent les étapes suivantes :

1. Le navigateur de l'utilisateur accède à IdP pour démarrer un flux SSO de fédération en indiquant

   1. Le SP à utiliser

   2. URL vers laquelle le navigateur de l'utilisateur doit être redirigé une fois l'authentification SSO de fédération terminée (facultatif)

2. Après avoir identifié l'utilisateur, l'élément IdP crée une réponse SSO avec une assertion SAML 2.0 contenant des informations utilisateur ainsi que des données d'authentification, et redirige le navigateur de l'utilisateur vers le fournisseur de services avec le message et le paramètre RelayState

3. Le navigateur de l'utilisateur présente la réponse SSO au serveur SP

4. Le fournisseur de services valide l'assertion SAML 2.0 et crée une session SSO pour l'utilisateur. Le serveur SSO redirige ensuite le navigateur de l'utilisateur vers la ressource initialement demandée.

5. Le navigateur de l'utilisateur demande l'accès à la ressource. Cette fois, l'agent Web SSO accorde l'accès à la ressource

6. L'application Web renvoie une réponse au navigateur de l'utilisateur

Description de l'image SSO_Response_Screen.jpg

Conclusion

Comme le montrent les différents flux, la meilleure approche d'un déploiement de fédération consiste à déclencher le SSO de fédération par le serveur SSO, au moment de l'exécution, lorsqu'il est jugé requis par le serveur SSO. Les autres cas ont une approche statique et exercent toujours un flux SSO de fédération, même s'il n'est pas requis (si l'utilisateur dispose déjà d'une session valide, par exemple), et l'exécution d'opérations Federation inutiles a un impact sur :

• Les performances des serveurs (interactions CPU, LDAP/SGBDR...)

• Temps de réponse de l'utilisateur, en fonction du temps nécessaire à l'exécution d'une opération SSO de fédération avec les réacheminements impliqués.

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuite sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation du produit, visitez le site Oracle Help Center.

---

Informations relatives au titre et au copyright

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.