Apprendre le SSO initié par le fournisseur de services pour les applications B2B

Lorsqu'il s'agit de modèles d'identité, les produits B2B sont dans une classe à part. Ils doivent naviguer dans les complexités de la multi-location tout en satisfaisant les demandes des clients d'entreprise pour une gestion unifiée des identités et des accès des employés à travers une multitude de services et d'applications. Logto a également rencontré ces demandes de la part de ses clients. Dans cet article, nous adopterons une approche orientée produit pour comprendre le SSO initié par le SP et comment il répond aux besoins de vos clients.

Concept#

Commençons par introduire quelques éléments clés que vous devez comprendre :

• Fournisseur de services (SP) : Vos applications ou services, qui peuvent être une ou plusieurs applications partageant un système d'identité unique.
• Fournisseur d'identité d'entreprise (IdP) : Le fournisseur d'identité sur lequel vos clients d'entreprise comptent pour gérer les identités des employés et les autorisations d'application. Ils peuvent utiliser différents fournisseurs, tels que Okta, Azure AD, Google Workspace, ou même des IdP personnalisés.
• Organisation du fournisseur de services (SP Org) : Les applications B2B prennent souvent en charge la multi-location pour différentes organisations clientes.
• Organisation du fournisseur d'identité (IdP Org) : Les IdP prennent également en charge la multi-location pour différentes organisations clientes. Idéalement, une entreprise devrait pouvoir lier son IdP Org à un SP Org, en répliquant les identités des employés, mais la réalité peut être plus complexe.
• Compte utilisateur d'entreprise : Typiquement identifié par l'utilisation d'un domaine de courriel d'entreprise pour la connexion. Ce compte de courriel d'entreprise appartient finalement à l'entreprise.

Ensuite, plongez dans le SSO et deux protocoles clés :

• Single sign-on (SSO): Le SSO permet aux utilisateurs d'accéder à plusieurs services ou applications avec un seul ensemble d'identifiants. Il simplifie la gestion des accès et améliore la sécurité.
• Protocoles SAML et OIDC : Le SSO repose sur ces protocoles pour l'authentification et l'autorisation, chacun ayant ses propres avantages et inconvénients.

Il y a deux principaux mécanismes de déclenchement du SSO à considérer :

• SSO initié par l'IdP : Dans le SSO initié par l'IdP, le fournisseur d'identité (IdP) contrôle principalement le processus de single sign-on. Les utilisateurs commencent l'authentification à partir de l'interface de l'IdP.
• SSO initié par le SP : Dans le SSO initié par le SP, le fournisseur de services (SP) prend l'initiative de lancer et de gérer le processus de single sign-on, souvent préféré dans les scénarios B2B.

Voyons maintenant en détail le SSO initié par le SP.

Aspect superficiel : expérience utilisateur#

Contrairement aux produits B2C qui peuvent offrir quelques boutons fixes de connexion via des IdP sociaux, les produits B2B ne peuvent pas dicter quel IdP d'entreprise spécifique chaque client utilise. Par conséquent, les utilisateurs doivent d'abord déclarer leur identité. Après avoir confirmé qu'ils sont membres d'une entreprise activée pour le SSO, ils sont redirigés vers leur IdP d'entreprise respectif pour la connexion.

Pour y parvenir, vous devez, sur la page de connexion, déterminer si l'utilisateur doit se connecter via SSO et vers quel IdP il doit être redirigé. Les méthodes courantes incluent :

1. Mappage de domaine de courriel : Associez un domaine de courriel à un connecteur IdP spécifique. Cela affecte les utilisateurs dont les adresses courriel sont sous ce domaine. Assurez la vérification de la propriété du domaine pour éviter les configurations malveillantes.
2. Mappage du nom de l'organisation : Associez le nom d'une organisation à un connecteur IdP, en comptant sur les utilisateurs pour se souvenir du nom de leur organisation.
3. Mappage de courriel personnel de l'utilisateur : Cela vous permet de déterminer directement si un compte utilisateur est activé pour le SSO, sans dépendre des domaines de courriel ou des noms d'organisation. Vous pouvez y parvenir en invitant les utilisateurs manuellement, en personnalisant les règles de SSO requis, ou en synchronisant automatiquement leurs comptes via la synchronisation d'annuaire.

Dans la conception de la page d'accueil de connexion, il existe généralement deux formes, que vous pouvez choisir en fonction du modèle commercial de votre produit :

1. Produits B2B : Recommandez d'afficher directement les boutons SSO pour le rendre intuitif pour les membres de votre client d'entreprise qui ont besoin d'utiliser le SSO.
2. Produits compatibles avec le B2C et le B2B : Comme la plupart des utilisateurs n'utiliseront pas le SSO, évaluez les domaines de courriel pour déterminer si le SSO est requis. Vous pouvez retarder la présentation de la vérification d'identifiants, en la masquant au départ et en la révélant une fois l'identité de l'utilisateur confirmée.

Complexité sous-jacente : modèle d'identité utilisateur#

Cependant, intégrer le SSO dans votre système d'identité implique beaucoup plus de complexité que de simplement ajouter un bouton SSO à la page de connexion. Vous devez considérer beaucoup plus de facteurs.

Les relations entre les éléments clés sont rarement un-à-un ; vous devez prendre en compte des scénarios un-à-plusieurs voir plusieurs-à-plusieurs. Pour explorer ces variations progressivement :

• Un IdP Org avec plusieurs domaines de courriel : Si vous vous appuyez sur les domaines de courriel pour déterminer l'identité de l'utilisateur, vous devez prendre en charge plusieurs liaisons de domaines.
• Un domaine de courriel correspondant à plusieurs IdP Orgs : Si un domaine peut appartenir à plusieurs IdP Orgs, les utilisateurs doivent choisir l'IdP qu'ils souhaitent pour la single sign-on.
• Un IdP Org lié à plusieurs SP Orgs : Envisagez de fournir la capacité rapide de connecter un IdP à plusieurs SP Orgs.
• Un compte utilisateur dans plusieurs IdP Orgs et SP Orgs : Différents SP Orgs peuvent nécessiter une vérification via différents IdP.

Activer ou désactiver le SSO au sein d'une entreprise peut modifier la façon dont les utilisateurs s'authentifient, nécessitant une transition sécurisée et fluide.

• Prise de décision pour l'activation du SSO : Des décisions doivent être prises pour savoir si le SSO affecte uniquement certains tenants SP Orgs ou tous les tenants SP Orgs. Le premier offre de la flexibilité, tandis que le second suit la tendance du contrôle d'identité et d'accès à l'échelle de l'entreprise.
• Considérations pour la période de transition : En tant que SP, vous devez vous adapter aux incertitudes des services IdP tiers. Les administrateurs d'entreprise doivent toujours pouvoir accéder à votre application par SSO ou identifiants classiques comme option, et les membres d'entreprise pourraient en avoir besoin pendant la période de transition.

Ce ne sont que quelques points pour traiter divers scénarios ; de nombreuses autres capacités et détails peuvent être explorés.

Conclusion#

Nous espérons que cette analyse du SSO initié par le SP vous offrira de nouvelles perspectives sur les solutions d'identité d'entreprise. La bonne nouvelle est que Logto développe diligemment des solutions offrant une configuration simple et des expériences d'authentification SSO prêtes à l'emploi. Restez à l'écoute pour notre prochaine version, où nous approfondirons les solutions spécifiques de SSO initié par le SP.