Différences entre le SSO initié par le SP et le SSO initié par l'IDP

Question

Quelqu'un peut-il m'expliquer quelles sont les principales différences entre SSO initié par le SP y SSO initié par l'IDP notamment quelle serait la meilleure solution pour mettre en œuvre l'authentification unique en conjonction avec ADFS + OpenAM Federation ?

Answer 1

SSO initié par l'IDP

Extrait de la documentation de PingFederate :- https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html

Dans ce scénario, un utilisateur est connecté à l'IdP et tente d'accéder à une ressource sur un serveur SP distant. L'assertion SAML est transportée vers le SP via HTTP POST.

Étapes de traitement :

1. Un utilisateur s'est connecté à l'IdP.
2. L'utilisateur demande l'accès à une ressource protégée du PS. L'utilisateur n'est pas connecté au site SP.
3. En option, l'IdP récupère les attributs du magasin de données de l'utilisateur.
4. Le service SSO de l'IdP renvoie un formulaire HTML au navigateur avec une réponse SAML contenant l'assertion d'authentification et tout attribut supplémentaire. Le navigateur renvoie automatiquement le formulaire HTML au SP.

SSO initié par le PS

Extrait de la documentation de PingFederate:- http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST

Dans ce scénario, un utilisateur tente d'accéder à une ressource protégée directement sur un site Web du SP sans être connecté. L'utilisateur n'a pas de compte sur le site du SP, mais a un compte fédéré géré par un IdP tiers. Le SP envoie une demande d'authentification à l'IdP. La demande et l'assertion SAML renvoyée sont envoyées par le navigateur de l'utilisateur via HTTP POST.

Étapes de traitement :

1. L'utilisateur demande l'accès à une ressource protégée du PS. La demande est redirigée vers le serveur de fédération pour gérer l'authentification.

2. Le serveur de fédération renvoie un formulaire HTML au navigateur avec une demande SAML d'authentification de l'IdP. Le formulaire HTML est automatiquement envoyé au service SSO de l'IdP.

3. Si l'utilisateur n'est pas déjà connecté au site de l'IdP ou si une nouvelle authentification est nécessaire, l'IdP demande les informations d'identification (par exemple, l'ID et le mot de passe) et l'utilisateur se connecte.

4. Des informations supplémentaires sur l'utilisateur peuvent être extraites du magasin de données utilisateur pour être incluses dans la réponse SAML. (Ces attributs sont prédéterminés dans le cadre de l'accord de fédération entre l'IdP et le SP).

5. Le service SSO de l'IdP renvoie un formulaire HTML au navigateur avec une réponse SAML contenant l'assertion d'authentification et tout attribut supplémentaire. Le navigateur renvoie automatiquement le formulaire HTML au SP. NOTE : Les spécifications SAML exigent que les réponses POST soient signées numériquement.

6. (Non montré) Si la signature et l'assertion sont valides, le SP établit une session pour l'utilisateur et redirige le navigateur vers la ressource cible.

Answer 2

SSO initié par le PS

Facturer l'utilisateur : "Hé Jimmy, montre-moi ce rapport"

Jimmy le suppresseur : "Hé, je ne suis pas encore sûr de qui vous êtes. Nous avons un processus ici, donc tu vas d'abord te faire vérifier par Bob l'IdP. Je lui fais confiance."

Bob l'IdP : "Je vois que Jimmy vous a envoyé ici. Veuillez me donner vos informations d'identification."

Facturer l'utilisateur : "Bonjour, je m'appelle Bill. Voici mes informations d'identification".

Bob l'IdP : "Salut Bill. On dirait que tu es parti."

Bob l'IdP : "Hey Jimmy. Ce type, Bill, a été contrôlé et voici quelques informations supplémentaires à son sujet. Tu fais ce que tu veux à partir de là."

Jimmy le suppressif : "Ok cool. On dirait que Bill est aussi dans notre liste d'invités connus. Je vais laisser Bill entrer."

SSO initié par l'IdP

Facturer l'utilisateur : "Salut Bob. Je veux aller chez Jimmy. La sécurité est renforcée là-bas."

Bob l'IdP : "Salut Jimmy. Je fais confiance à Bill. Il a été vérifié et voici quelques informations supplémentaires à son sujet. Tu fais ce que tu veux à partir de là."

Jimmy le SP : "Ok cool. On dirait que Bill est aussi dans notre liste d'invités connus. Je vais laisser Bill entrer."

---

J'entre dans les détails ici, tout en gardant les choses simples : https://jorgecolonconsulting.com/saml-sso-in-simple-terms/ .

Answer 3

En IDP Init SSO (Unsolicited Web SSO), le processus de fédération est initié par l'IDP qui envoie une réponse SAML non sollicitée au SP. Dans SP-Init, le SP génère une AuthnRequest qui est envoyée à l'IDP comme première étape du processus de fédération et l'IDP répond ensuite avec une réponse SAML. A mon avis, le support de l'ADFSv2 pour SAML2.0 Web SSO SP-Init est plus fort que son support IDP-Init en ce qui concerne l'intégration avec des produits Fed tiers (principalement autour du support de RelayState), donc si vous avez le choix, vous voudrez utiliser SP-Init car il vous facilitera probablement la vie avec ADFSv2.

Voici quelques descriptions simples de SSO tirées du Guide de démarrage de PingFederate 8.0 que vous pouvez consulter et qui peuvent également vous être utiles https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html

Answer 4

https://support.procore.com/faq/what-is-the-difference-between-sp-and-idp-initiated-sso

Il y a beaucoup plus que cela, mais il s'agit d'une vue d'ensemble de haut niveau sur ce qui est quoi.

Procore supporte le SSO initié par le SP et l'IdP :

SSO initié par le fournisseur d'identité (IdP-initiated). Avec cette option, vos utilisateurs finaux doivent se connecter à la page SSO de votre fournisseur d'identité (par exemple, Okta, OneLogin ou Microsoft Azure AD), puis cliquer sur une icône pour se connecter et ouvrir l'application Web Procore. Pour configurer cette solution, voir Configurer le SSO initié par le fournisseur d'identité pour Microsoft Azure AD, Configurer Procore pour le SSO Okta initié par le fournisseur d'identité, ou Configurer le SSO initié par le fournisseur d'identité pour OneLogin. OU SSO initié par le fournisseur de services (SP-initiated). Appelée SSO initié par Procore, cette option donne à vos utilisateurs finaux la possibilité de se connecter à la page de connexion Procore, puis d'envoyer une demande d'autorisation au fournisseur d'identité (par exemple, Okta, OneLogin ou Microsoft Azure AD). Une fois que l'IdP a authentifié l'identité de l'utilisateur, ce dernier est connecté à Procore. Pour configurer cette solution, voir Configurer le SSO initié par Procore pour Microsoft Azure Active Directory, Configurer le SSO initié par Procore pour Okta, ou Configurer le SSO initié par Procore pour OneLogin.