SSO : le fournisseur de services doit-il valider la session avec l'IDP à chaque demande ?

Question

Selon le flux SSO initié par le SP, l'utilisateur tente d'accéder au SP. Comme l'utilisateur n'est pas authentifié, il est redirigé vers l'IDP où il entre ses informations d'identification. Une fois la connexion réussie, l'IDP installe des cookies dans le navigateur de l'utilisateur (sous le domaine de l'IDP) et redirige l'utilisateur vers le SP avec une réponse SAML. Une fois que le fournisseur de services a vérifié la réponse SAML, il crée son propre cookie/token et le place dans le navigateur de l'utilisateur sous le domaine du fournisseur de services.

Que devrait-il se passer idéalement dans les demandes ultérieures ?

1. La SP devrait-elle s'appuyer uniquement sur son propre cookie pour obtenir des informations sur l'utilisateur ?
2. Le prestataire de services doit valider la session de l'utilisateur auprès de l'IDP à chaque demande.

Si option 1 Est-ce acceptable du point de vue de la sécurité, car après la connexion, il n'y a pas de communication entre le SP et l'IDP pour d'autres demandes.

Si option 2 est conseillée, l'appel à l'IDP pour chaque requête entraînerait un surcoût qui pourrait avoir une incidence sur les performances du système de paiement.

Veuillez nous indiquer quel devrait être le flux idéal dans ce cas.

Answer 1

Si l'option 1 est conseillée, est-elle acceptable du point de vue de la sécurité car, après la connexion, il n'y a pas de communication entre le SP et l'IDP pour d'autres demandes.

[Oui, il devrait incomber au fournisseur de services de valider le cookie (peut-être crypté avec tous les détails qu'il contient ou référencé par un identifiant pointant vers la zone de stockage persistante). Le travail de l'IDP est de fournir l'identité, ce qui est déjà fait.

Si l'option 2 est retenue, l'appel à l'IDP pour chaque requête entraînera un surcoût qui pourrait avoir une incidence sur les performances du système de paiement.

[ME] Oui, ce serait trop pour valider la session de l'utilisateur avec l'IDP. La façon dont cela fonctionne est la suivante : si la session de l'utilisateur a été invalidée ou est en cours de création, elle va à l'IDP, si les cookies/session de l'IDP sont valides, elle donne une réponse/affirmation SAML ou authentifie si ce n'est pas le cas et enfin, l'utilisateur crée une nouvelle session.

HTH.

Answer 2

L'utilisateur a donc été autorisé/authentifié par le fournisseur d'identité. Craignez-vous que cette autorisation/authentification n'expire soudainement ? Par exemple, le fournisseur d'identité appartient peut-être à l'employeur de l'utilisateur et, lorsque ce dernier est licencié, il est essentiel que l'accès au fournisseur d'identité soit également révoqué immédiatement. Ou peut-être l'utilisateur découvre-t-il que ses informations d'identification ont été volées et ferme/bloque-t-il son compte IdP, voulez-vous pouvoir arrêter votre session SP également ? Vous ne pouvez faire ces choses que dans l'option 1, c'est donc l'option la plus sûre.

Comme vous le dites à juste titre, cela s'accompagne de nombreux frais généraux. La question est donc de savoir dans quelle mesure il est important pour vous que votre session SP se termine immédiatement lorsque le compte IdP de l'utilisateur est révoqué.

D'ailleurs, ce que je n'aime pas, c'est que l'IdP stocke la session dans un cookie. À mon avis, il ne devrait pas le faire, surtout si vous mettez en œuvre l'option 2. La raison en est que cela rend la déconnexion très délicate : l'utilisateur doit maintenant se souvenir de se déconnecter à la fois du SP et de l'IdP, alors qu'il n'avait besoin de se connecter qu'une seule fois.