Comment SAML résout-il le problème d'authentification unique interdomaine?
Disons que j'ai deux sites Web qui vivent sur des domaines distincts, et leurs fournisseurs de services parlent tous les deux au même fournisseur d'identité sur un troisième domaine. Je me connecte au premier site Web et m'authentifie, et maintenant je décide de visiter le deuxième site Web. Le deuxième site Web communique avec le fournisseur d'identité, je n'ai donc pas besoin de me reconnecter pour accéder à mon compte. Comment cela est-il réalisé en utilisant SAML? Est-il possible d'utiliser des cookies dans ce cas?
Il peut en fait s'agir d'un cookie, car il ne doit pas du tout être associé au fournisseur de services, mais uniquement au fournisseur d'identité. Chacun des deux fournisseurs de services va faire la demande d'authentification au fournisseur d'identité, de sorte que le processus pour un utilisateur non authentifié sera le même pour sp.example1.com que pour sp.example2.com.
Cependant, lorsque la première demande est effectuée à partir de sp.example1.com et que l'utilisateur est redirigé vers sso.example3.com, l'utilisateur se connecte à sso.example3.com et peut ensuite définir un cookie pour sso.example3.com.
Ensuite, lorsque l'utilisateur visite sp.example2.com, il redirige également l'utilisateur non authentifié vers sso.example3.com, mais cette fois, le navigateur aura un cookie à envoyer avec la demande de la dernière fois que l'utilisateur a visité sso .example3.com, même si cette visite a été initiée par un autre fournisseur de services.
Ainsi, le cookie de sso.example3.com peut identifier l'utilisateur comme déjà authentifié, et le fournisseur d'identité peut continuer le processus d'émission d'une assertion pour l'utilisateur sur sp.example2.com sans exiger que l'utilisateur termine à nouveau le flux de travail de connexion.
C'est possible en utilisant des cookies.
Les cookies ne sont rien d'autre que de petits éléments de données (paires nom-valeur) qui sont stockés dans votre navigateur par l'application Web avec laquelle vous communiquez. Chaque cookie a un domaine qui lui est associé et un cookie appartenant à example.com n'est pas accessible par abc.com. Il est important de noter que chaque fois que le navigateur fait une demande HTTP à un certain domaine, tous les cookies associés à ce domaine sont également envoyés avec la demande au serveur.
Dans la terminologie SAML
Fournisseur d'identité (IdP) - Fournit l'authentification en tant que service
Fournisseur de services (SP) - S'appuie sur IdP pour l'authentification de ses utilisateurs
SSO utilisant SAML : disons qu'il y a deux services SP1 et SP2 auxquels l'utilisateur souhaite accéder.
L'utilisateur visite SP1 et essaie de se connecter. SP1 envoie une demande d'authentification à IdP et le navigateur de l'utilisateur est redirigé vers IdP où il entre ses informations d'identification. Après une authentification réussie, l'utilisateur est à nouveau redirigé vers SP1 et IdP envoie un assertion à SP1 qui contient des informations d'authentification. L'utilisateur est maintenant authentifié et peut utiliser les services de SP1. Dans ce cas, la réponse provenant d'IdP contient également un cookie pour identifier l'utilisateur. Ce cookie est stocké dans le navigateur.
L'utilisateur ouvre maintenant un autre onglet dans le navigateur et essaie d'accéder au site Web du SP2. Encore une fois, alors qu'il essaie de se connecter, le navigateur est redirigé vers IdP et avec cette redirection, les cookies définis par l'IdP sont également envoyés. L'IdP reçoit le cookie et envoie une assertion redirigeant le navigateur vers SP2. L'utilisateur est connecté à SP2 sans avoir à saisir à nouveau ses informations d'identification.
Je crois que mod_auth_openidc implémente cette fonctionnalité en tant que "Gestion de session" en utilisant des iframes . Ici
Mais je ne sais pas s'il existe une autre meilleure solution/alternative avec d'autres produits SAML/OpenIdC
le défi est le cookie de session, car nous savons que nous allons définir un cookie de session ou un cookie basé sur le temps dans le site Web SSO, mais comme d'habitude l'utilisateur visite le site SP1 et SP2, le cookie de session et le cookie de temps seront expirés pendant la visite. comment conserver le statut de connexion? essayez ajax appel au site Web SSO au backend? c'est la seule façon dont je peux penser.