Nederlands
  • serviceprovider
  • sso
  • b2b
  • identiteit
  • auth
  • authenticatie
  • single sign-on

Leer over SP-geïnitieerde Single Sign-On voor B2B-apps

Leer wat serviceprovider-geïnitieerde (SP-geïnitieerde) single sign-on (SSO) is en hoe het jouw business-to-business (B2B) product kan helpen.

Ran
Ran
Product & Design

Als het gaat om identiteitsmodellen, zijn B2B-producten in een klasse apart. Ze moeten navigeren door de complexiteiten van multi-tenancy, terwijl ze voldoen aan de vraag van zakelijke klanten naar een uniforme identiteits- en toegangsbeheer voor werknemers over een overvloed aan diensten en applicaties. Logto heeft deze eisen ook van klanten gekregen. In dit artikel maken we een productgerichte benadering om SP-geïnitieerde SSO te begrijpen en hoe het inspeelt op de behoeften van jouw klanten.

Concept

Laten we beginnen met enkele belangrijke elementen die je moet begrijpen:

  • Serviceprovider (SP): Jouw applicaties of diensten, die een enkele of meerdere apps kunnen zijn die een enkel identiteitsysteem delen.
  • Enterprise identity provider (IdP): De identiteitsprovider waarop jouw zakelijke klanten vertrouwen om werknemersidentiteiten en applicatierechten te beheren. Ze kunnen verschillende providers gebruiken, zoals Okta, Azure AD, Google Workspace of zelfs op maat gemaakte IdP's.
  • Serviceprovider's organisatie (SP Org): B2B-apps ondersteunen vaak multi-tenancy voor verschillende klantorganisaties.
  • Identity provider's organisatie (IdP Org): IdP's ondersteunen ook multi-tenancy voor verschillende klantorganisaties. Idealiter zou een onderneming haar IdP Org aan een SP Org moeten kunnen koppelen, waarbij werknemersidentiteiten worden gerepliceerd, maar de werkelijkheid kan gecompliceerder zijn.
  • Enterprise gebruikersaccount: Meestal geïdentificeerd door hun gebruik van een bedrijfs-e-maildomein voor inloggen. Dit zakelijke e-mailaccount behoort uiteindelijk tot het bedrijf.

Duik vervolgens in SSO en twee belangrijke protocollen:

  • Single sign-on (SSO): SSO stelt gebruikers in staat om meerdere diensten of applicaties te gebruiken met een enkele set inloggegevens. Het vereenvoudigt toegangsbeheer en verhoogt de beveiliging.
  • SAML en OIDC protocollen: SSO vertrouwt op deze protocollen voor authenticatie en autorisatie, elk met hun eigen voor- en nadelen.

Er zijn twee hoofdmechanismen om SSO te activeren om in overweging te nemen:

  • IdP-geïnitieerde SSO: Bij IdP-geïnitieerde SSO controleert de Identity Provider (IdP) primair het single sign-on proces. Gebruikers beginnen de authenticatie vanuit de interface van de IdP.
  • SP-geïnitieerde SSO: Bij SP-geïnitieerde SSO neemt de Serviceprovider (SP) het voortouw in het initiëren en beheren van het single sign-on proces, vaak geprefereerd in B2B-scenario's.

Laten we nu SP-geïnitieerde SSO in detail onderzoeken.

Oppervlakte niveau: gebruikerservaring

In tegenstelling tot B2C-producten die een paar vaste sociale IdP-aanmeldknoppen kunnen aanbieden, kunnen B2B-producten niet dicteren welke specifieke Enterprise IdP elke klant gebruikt. Daarom moeten gebruikers eerst hun identiteit verklaren. Nadat ze hebben bevestigd dat ze lid zijn van een onderneming die SSO ondersteunt, worden ze doorgestuurd naar hun respectieve Enterprise IdP voor inloggen.

Om dit te bereiken, moet je op de inlogpagina bepalen of de gebruiker via SSO moet inloggen en naar welke IdP ze moeten worden doorgestuurd. Veelgebruikte methoden omvatten:

  1. E-maildomein mapping: Koppel een e-maildomein aan een specifieke IdP-connector. Dit beïnvloedt gebruikers met e-mailadressen onder dat domein. Zorg voor verificatie van domeineigendom om kwaadaardige configuraties te voorkomen.
  2. Organisatienaam mapping: Koppel de naam van een organisatie aan een IdP-connector, waarbij je vertrouwt op gebruikers om zich hun organisatienaam te herinneren.
  3. Persoonlijke e-mail mapping van gebruiker: Hiermee kun je direct bepalen of een gebruikersaccount is ingeschakeld voor SSO, zonder afhankelijk te zijn van e-maildomeinen of organisatienamen. Je kunt dit bereiken door gebruikers handmatig uit te nodigen, regels voor vereiste SSO aan te passen of hun accounts automatisch te synchroniseren via mappensynchronisatie.

In het ontwerp van de inlog startpagina zijn er meestal twee vormen die op basis van jouw productactiviteiten kunnen worden gekozen:

  1. B2B-producten: Aanbevolen om direct SSO-knoppen weer te geven om het intuïtief te maken voor de leden van jouw zakelijke klanten die SSO moeten gebruiken.
  2. Producten compatibel met B2C en B2B: Aangezien de meeste gebruikers geen SSO gebruiken, evalueer e-maildomeinen om te bepalen of SSO vereist is. Je kunt credentialverificatie uitstellen en aanvankelijk verbergen, en het pas onthullen zodra de identiteit van de gebruiker is bevestigd.

Onderliggende complexiteit: gebruikersidentiteitsmodel

Echter, het integreren van SSO in jouw identiteitsysteem brengt veel meer complexiteit met zich mee dan simpelweg een SSO-knop toevoegen aan de inlogpagina. Je moet veel meer factoren in overweging nemen.

De relaties van belangrijke elementen zijn zelden een-op-een; je moet een-op-veel en zelfs veel-op-veel scenario's overwegen. Om deze variaties geleidelijk te verkennen:

  • Eén IdP Org met meerdere e-maildomeinen: Als je vertrouwt op e-maildomeinen om gebruikersidentiteit te bepalen, moet je meerdere domeinkoppelingen ondersteunen.
  • Eén e-maildomein dat overeenkomt met meerdere IdP Orgs: Als een domein bij meerdere IdP Orgs kan horen, moeten gebruikers de IdP kiezen die ze willen voor single sign-on.
  • Eén IdP Org gekoppeld aan meerdere SP Orgs: Overweeg de snelle mogelijkheid om één IdP met meerdere SP Orgs te verbinden.
  • Eén gebruikersaccount in meerdere IdP Orgs en SP Orgs: Verschillende SP Orgs kunnen verificatie via verschillende IdP's vereisen.

Het inschakelen of uitschakelen van SSO binnen een onderneming kan de manier waarop gebruikers authenticeren veranderen, waardoor een veilige en soepele overgang vereist is.

  • Besluitvorming voor het activeren van SSO: Er moeten beslissingen worden genomen over of SSO alleen bepaalde SP Orgs van huurders beïnvloedt of alle SP Orgs van huurders. De eerste biedt flexibiliteit, terwijl de laatste in lijn is met de trend van ondernemingsbrede identiteit en toegangscontrole.
  • Overgangsperiode overwegingen: Als een SP moet je de onzekerheden van derde partij IdP-diensten accommoderen. Enterprise admins moeten altijd toegang hebben tot jouw app via SSO of als optie met gebruik van inloggegevens, en enterprise leden kunnen deze tijdens de overgang nodig hebben.

Dit zijn slechts enkele punten voor het omgaan met verschillende scenario's; veel meer mogelijkheden en details kunnen worden verkend.

Conclusie

We hopen dat deze analyse van SP-geïnitieerde SSO je nieuwe perspectieven biedt op bedrijfsidentiteitsoplossingen. Het goede nieuws is dat Logto ijverig oplossingen ontwikkelt die eenvoudige configuratie en out-of-the-box SSO-authenticatie-ervaringen bieden. Blijf op de hoogte voor onze aankomende release, waarin we dieper ingaan op specifieke SP-geïnitieerde SSO-oplossingen.