CIAM 101: Autentisering, Identitet, SSO

Bakgrund#

Jag började bygga Logto eftersom jag märkte att Identity and Access Management (IAM) hade blivit allt mer komplext och omfattande över tiden. Begreppet IAM är till och med stort nog att ge upphov till nya koncept, såsom WIAM (Workforce IAM) och CIAM (Customer IAM).

Medan WIAM och CIAM delar samma grund, har de olika användningsfall: WIAM används vanligtvis för interna användare, medan CIAM används för externa kunder. Några exempel:

• WIAM Ditt företag har ett enhetligt identitetssystem för anställda, så att alla kan använda samma konto för att få tillgång till företagsresurser, såsom programprenumerationer, molntjänster, etc.
• CIAM Din nätbokhandel kräver ett användaridentitetssystem för kunder och säljare. Inloggningsupplevelsen är en kritisk del av onboardingprocessen, eftersom den ligger högst upp i konverteringstratten.

Logto började med CIAM av olika skäl (vi kommer att ha en annan artikel som pratar om detta). Under utvecklingen insåg vi att det skulle vara fördelaktigt att bygga en enhetlig förståelse inom teamet innan vi tar vår produkt till nästa nivå. Vi hoppas också att detta hjälper dig att få en bättre förståelse för IAM-landskapet.

Låt oss börja!

Grundläggande om CIAM#

I den här artikeln fokuserar vi på de grundläggande koncepten i CIAM och problem vi kan stöta på under eller efter autentiseringsflödet. Vi kommer också att diskutera single sign-on (SSO) och dess relaterade scenarier.

Autentisering och auktorisering#

💡 Autentisering definieras initialt som "Vem är du?". Men när man diskuterar digitala identiteter är det mer korrekt att demonstrera autentisering genom att "bevisa ägande av identitet". (Tack till Calm-Card-2424)

Om du upptäcker något som inte passar in i någon av dessa två kategorier är det troligtvis inte väsentligt för identitetsverksamheten.

• Exempel på autentisering
  • Lösenordsinloggning, lösenordsfri inloggning, social inloggning, etc.
  • Maskin-till-Maskin-autentisering
• Exempel på auktorisering
  • Rollbaserad åtkomstkontroll
  • Attributbaserad åtkomstkontroll
• Exempel på undantag
  • Icke-identitetsdata
  • Web hooks

Identitet och Hyresgäst#

Identitet representerar typiskt antingen en användare eller en maskin. Vid framgångsrik autentisering utfärdas en ID-token som en Identitet.

Med andra ord är huvudsyftet med autentisering att erhålla en Identitet.

En Hyresgäst är en grupp av identiteter:

När vi diskuterar "Multi-tenant" hänvisar vi till flera Logto-instans som är identitetsisolerade från varandra. Med andra ord, flera Logto-instans.

Observera att det finns två isolerade identitetssystem, dvs. du kan inte använda Identiteten från Hyresgäst 1 i Hyresgäst 2, även för samma identifierare (e-post, telefon, etc.). Det är som ditt Costco-medlemskap inte är giltigt på Whole Foods.

App och Hyresgäst#

Precis som Identitet, ett App också hör till en Hyresgäst. Några saker att komma ihåg:

• Det finns vanligtvis inget direkt förhållande mellan en App och en Identitet.
  • En Identitet kan representera en App, men det finns ingen direkt koppling mellan dem.
• Precis som användare är appar också på Hyresgäst-nivå.
• Appar är kod, medan användare är människor.
• Det enda syftet med Appar är att slutföra autentisering, dvs erhålla en Identitet.

Identity Provider (IdP) och Service Provider (SP)#

Skillnaden mellan dessa två leverantörer är knivig men viktig.

• Identity Provider är en tjänst som tillhandahåller autentisering (AuthN) och utfärdar identiteter.

Du kan hitta olika förklaringar om Service Provider från Google, även om de kanske inte är tillfredsställande. För mig är Service Provider ett relativt koncept:

• Service Provider (eller Relying Party i OIDC) är en tjänst eller klient som initierar autentisering (AuthN) och begär resultatet från Identity Providers.

Quiz#

Tänk på ett typiskt scenario för social inloggning:

❓ Hur många Service Providers och Identity Providers finns i detta diagram?

Svar

Båda har två. iOS App är en serviceprovider till Logto, medan Logto är en identity provider. Logto är också en serviceprovider till GitHub, medan GitHub är en identity provider. Således är Logto en Service Provider och också en Identity Provider.

Case study: Ett tekniklösningsföretag#

Du är CTO för ett tekniklösningsföretag, du har över 100 affärspartners och du har levererat över 300 projekt.

• Varje projekt är antingen en webbapp eller en mobilapp med en backend-tjänst.
• För varje affärspartner vill du omstrukturera användarsystemet för att tillhandahålla SSO över sina projekt.

❓ Hur kan Logto (eller en CIAM-produkt) hjälpa?

Svar

Skapa en Logto-instans för varje affärspartner. Varje partner har en Hyresgäst. Projekt mappar till "Appar" i Logto.

Logto erbjuder en universell inloggningsupplevelse (dvs. SSO) inom en Hyresgäst, så användare behöver inte logga in igen när de får tillgång till en annan app i samma Hyresgäst om de redan har loggat in.

Vad vi pratar om när vi pratar om SSO#

Vi upptäckte att termen “SSO” ofta orsakar förvirring. Vi anser single sign-on (SSO) vara ett beteende, inte ett affärskoncept. Därför motsvarar SSO inte “SSO i WIAM”.

När vi säger “det behövs SSO”, kan det referera till ett av följande fall:

SSO Case 1#

👉🏽 I ett stort företag använder anställda samma referenser för att logga in på alla företagets licensierade resurser (t.ex. e-post, IM, molntjänster).

Det är det typiska WIAM-scenariot. I detta fall är endast en Identity Provider inblandad. Vi bryr oss inte för tillfället.

SSO Case 2#

👉🏽 Slutanvändare använder samma referenser för att logga in på alla tjänster utvecklade av samma företag (t.ex. GSuite).

Logto fokuserar för närvarande på det angivna tillvägagångssättet ovan. Flera externa identitetsleverantörer, såsom en tredje parts social inloggning, kan existera oberoende och utan koppling.

Trots detta förblir Logto den enda sanna källan för Identiteter, och "lånar" dem bara från andra leverantörer. I detta fall fungerar Logto som både Identity Provider (till GSuite-appar) och Service Provider (till externa Identity Providers).

SSO Case 3#

👉🏽 Slutanvändare kan endast använda den specifika Identity Provider inom den motsvarande e-postdomänen för att slutföra autentisering. Till exempel, logga in på Figma med Google Workspace.

Detta är det vanligaste användningsfallet för SSO i CIAM. Låt oss ta en närmare titt.

Om vi vill logga in på Figma med vår @silverhand.io e-post kan vi använda antingen Social inloggning eller SSO. Diagrammen nedan illustrerar skillnaden mellan de två:

I ord:

• Efter social inloggning är användarna fria att sätta ett lösenord eller ändra e-postadress i Figma
• Efter SSO kan användarna inte sätta lösenord eller ändra någon personlig info inklusive e-post, eftersom deras identiteter hanteras av Google Workspace

I detta fall är Logto både en Identity Provider och en Service Provider. Det verkar som att SSO är mer komplex än en vanlig inloggningsprocess. Vilka är fördelarna för identitetsägaren?

• Centraliserad kontroll: Håll identitetsinformation och autentiseringsprocesser på ett ställe och säkerställ att användarens information alltid är uppdaterad. Det finns ingen anledning att lägga till och ta bort licenser över olika applikationer för ändringar.
• Förbättrad användarupplevelse: Identitetsägare som kräver SSO är vanligtvis företag. Deras anställda kan använda samma referenser och delad session för företagsapplikationer, såsom Figma, Zoom, Slack, etc.
• Förbättrad säkerhet: Du kanske har märkt att vissa företag kräver specifika inloggningsmetoder, såsom dynamiska verifieringskoder. Använda SSO kan säkerställa att varje anställd använder samma kombination av inloggningsmetoder för att komma åt alla resurser.

🤔 Smart som du måste ha märkt att detta faktiskt är SSO Case 1 ur ett SaaS-perspektiv.

Det är dags att diskutera "X" i SSO-grafen. Detta representerar processen för Figma att koppla e-postdomänen till en specifik Identity Provider. Men hur fungerar det?

SSO-mappning#

Eftersom begäran ofta kommer från företagskunder hänvisar vi till processen för "SSO Case 3" från föregående avsnitt som "Enterprise SSO" för tydlighet.

Vi kan enkelt utarbeta en naiv lösning: skapa en mappning mellan e-postdomäner och SSO-metoder och uppdatera den manuellt.

Åtgärden av processen “X” är nu klar:

🔍 Hitta den mappade Enterprise SSO-metoden för den angivna e-postdomänen

Således, om du konfigurerar silverhand.io som en giltig e-postdomän som kopplas till en Google Workspace SSO URL, kommer användare som försöker logga in med en @silverhand.io e-post att omdirigeras till motsvarande Google Workspace inloggningssida, i stället för att behandlas på plats.

När du bara har några dussin kunder som behöver Enterprise SSO kan den manuella hanteringen av mappningen vara ok. Men det finns fler faktorer att ta hänsyn till:

1. Vad händer om det finns hundratals eller tusentals Enterprise SSO-kunder?
2. Vad är förhållandet mellan “vanliga användare” och “Enterprise SSO-användare”?
3. Ska data isoleras mellan olika Enterprise SSO-kunder?
4. Finns det behov av att tillhandahålla en instrumentpanel för Enterprise SSO-administratörerna för att visa aktiva användare, granskningsloggar, etc.?
5. Hur kan konton inaktiveras automatiskt när en användare tas bort från Enterprise SSO Identity Provider?

Och mycket mer. Eftersom nästan alla Enterprise SSO är e-postdomän-baserade kan vi snabbt lista ut en bättre lösning:

• Om användaren kan bevisa äganderätt av den domänen kan de ställa in företagets SSO för den domänen på ett självbetjäningssätt.

Denna lösning adresserar de första två frågorna:

1. Vad händer om det finns hundratals eller tusentals Enterprise SSO-kunder?

• De kan konfigurera Enterprise SSO på ett självbetjäningssätt.

2. Vad är förhållandet mellan “vanliga användare” och “Enterprise SSO-användare”?

• Vi öppnar alla möjliga inloggningsmetoder för vanliga användare utom Enterprise SSO; medan vi begränsar inloggningsmetoden till enbart Enterprise SSO för de användare som försöker logga in med de konfigurerade domänerna.

Vad gäller den tredje frågan:

3. Ska jag isolera data mellan olika Enterprise SSO-kunder?

• Ja och nej. Det är dags att introducera organisation.

Organisation#

Vi nämnde att använda e-postdomäner för att känna igen den specifika Enterprise SSO-metoden att använda; med andra ord, tillämpa en specifik behandling för en specifik grupp av användare.

Men kundens krav är ofta mer än bara Enterprise SSO; till exempel, frågorna 4 och 5 i föregående avsnitt. Under åren har en mogen modell utvecklats av framstående SaaS-företag för att adressera dessa typer av problem: Organisationer.

Organisationsregler

1. En organisation är en grupp av identiteter, vanligtvis mindre än en Hyresgäst.
2. Alla organisationer är kopplade till en Hyresgäst.

Du kan se andra termer, såsom "Workspace", “Team”, eller till och med "Hyresgäst" i programvaran. För att identifiera om det är det koncept vi diskuterar, kolla bara om det representerar “en grupp av Identiteter”.

I denna artikel kommer vi att använda termen "Organisation" för konsekvensens skull.

I Notion kan du skapa och gå med i flera arbetsytor (dvs. Organisationer) med samma e-postadress och enkelt växla mellan dem.

För Slack verkar det vara samma sak, men vi misstänker att de använder olika Identiteter i bakgrunden eftersom vi behöver skapa ett nytt konto för varje arbetsyta.

Notion har en “Personlig Plan” tillgänglig, vilken normalt är en Organisation under skalet, med den enda användaren (du) inuti. Vi känner inte till den exakta implementeringen av Notion, men denna förklaring är rimlig och möjlig för vår modell.

Varje Organisation har också en identifierare, som vanligtvis kallas “Organisationsdomän”.

Quiz#

❓ Kan en app associeras med en Organisation?

Svar

Ja, ja. Som vi diskuterade i början kan en app ha en Identitet. Kan du utveckla ett affärsscenario för detta?

Kvarvarande frågor#

3. Ska data isoleras mellan olika Enterprise SSO-kunder?

• Ja: Isolera affärsdata, såsom meddelanden och dokument, på Organisationsnivå.
• Nej: Håll Identiteter oberoende, eftersom de inte behöver associeras med en Organisation.
• Observera att det finns tre distinkta enheter inblandade här: Identiteter, Organisationer och Enterprise SSO-konfigurationer; vilket markant ökar komplexiteten. Frågan i sig är inte tillräckligt specifik.

4. Finns det ett behov av att tillhandahålla en instrumentpanel för Enterprise SSO-administratörerna för att visa aktiva användare, granskningsloggar, etc.?

5. Hur ska konton automatiskt inaktiveras när en användare tas bort för Enterprise SSO Identity Provider?

• Dessa krav är mer affärsinriktade och kan implementeras på Organisationsnivå. Vi lämnar dem öppna här.

Slutanteckningar#

Vi har introducerat flera koncept: Autentisering (AuthN), Auktorisering (AuthZ), Identitet, Hyresgäst, Applikation, Identity Provider (IdP), Service Provider (SP), Single sign-on (SSO), och Enterprise SSO (Organisation). Det kan ta lite tid att förstå dem alla.

När jag skrev denna artikel märkte jag att intressant nog, de dyraste planerna för onlinetjänster ofta inkluderar exklusiva funktioner relaterade till auktorisering, vilket är helt omtalat i denna artikel. Du kanske redan har några frågor om auktorisering, såsom:

• Hur kan vi tilldela behörigheter till en användare och verifiera dem?
• Vilken auktoriseringsmodell borde jag använda?
• Vad är bästa praxis för att tillämpa en auktoriseringsmodell?