CIAM 101: Authenticatie, Identiteit, SSO

Achtergrond#

Ik begon Logto te bouwen omdat ik merkte dat Identity and Access Management (IAM) in de loop der tijd steeds complexer en uitgebreider was geworden. Het concept van IAM is zelfs groot genoeg om nieuwe concepten voort te brengen, zoals WIAM (Workforce IAM) en CIAM (Customer IAM).

Hoewel WIAM en CIAM dezelfde basis delen, hebben ze verschillende toepassingen: WIAM wordt meestal gebruikt voor interne gebruikers, terwijl CIAM wordt gebruikt voor externe klanten. Enkele voorbeelden:

• WIAM Jouw bedrijf heeft een uniform identiteitssysteem voor werknemers, zodat iedereen hetzelfde account kan gebruiken om toegang te krijgen tot bedrijfsmiddelen, zoals software-abonnementen, clouddiensten, enzovoort.
• CIAM Jouw online boekwinkel vereist een gebruikersidentiteitssysteem voor klanten en verkopers. De inlogervaring is een cruciaal onderdeel van onboarding, aangezien het zich aan het begin van de conversietrechter bevindt.

Logto begon met CIAM om verschillende redenen (we zullen hier een ander artikel over schrijven). Tijdens de ontwikkeling realiseerden we ons dat het nuttig zou zijn om een gemeenschappelijk begrip binnen het team te creëren voordat we ons product naar het volgende niveau brengen. We hopen dat dit jou ook zal helpen om een beter begrip van het IAM-landschap te krijgen.

Laten we beginnen!

De basisprincipes van CIAM#

In dit artikel zullen we ons richten op de fundamentele concepten van CIAM en de problemen die we kunnen tegenkomen tijdens of na het authenticatieproces. We bespreken ook single sign-on (SSO) en de bijbehorende scenario's.

Authenticatie en autorisatie#

💡 Authenticatie wordt aanvankelijk gedefinieerd als "Wie ben jij?". Echter, bij het bespreken van digitale identiteiten is het nauwkeuriger om authenticatie aan te tonen door "het eigenaarschap van identiteit te bewijzen". (Dank aan Calm-Card-2424)

Als je iets ontdekt dat niet in een van deze twee categorieën past, is het waarschijnlijk niet essentieel voor de identiteitsbusiness.

• Voorbeelden van authenticatie
  • Wachtwoord inloggen, wachtwoordloos inloggen, sociaal inloggen, enz.
  • Machine-tot-machine authenticatie
• Voorbeelden van autorisatie
  • Rolgebaseerde toegangscontrole
  • Attribuutgebaseerde toegangscontrole
• Voorbeelden van uitzonderingen
  • Niet-identiteitsgegevens
  • Webhooks

Identiteit en huurder#

Identiteit vertegenwoordigt meestal een gebruiker of een machine. Na succesvolle authenticatie wordt een ID-token uitgegeven als een Identiteit.

Met andere woorden, het belangrijkste doel van authenticatie is het verkrijgen van een Identiteit.

Een Huurder is een groep identiteiten:

Wanneer we het hebben over "Multi-huurder", verwijzen we naar meerdere Logto-instanties die identiteits-geïsoleerd zijn van elkaar. Met andere woorden, meerdere Logto-instanties.

Merk op dat er twee geïsoleerde identiteitsystemen zijn, dwz je kunt de Identiteit van Huurder 1 niet gebruiken in Huurder 2, zelfs niet voor dezelfde identificator (e-mail, telefoon, enz.). Het is net als jouw Costco-lidmaatschap dat niet geldt bij Whole Foods.

App en huurder#

Net als Identiteit behoort een App ook tot een Huurder. Enkele dingen om te onthouden:

• Er is doorgaans geen directe relatie tussen een App en een Identiteit.
  • Een Identiteit kan een App vertegenwoordigen, maar er is geen directe verbinding tussen hen.
• Net als gebruikers zijn apps ook op huurderniveau.
• Apps zijn code, terwijl gebruikers menselijk zijn.
• Het enige doel van Apps is om authenticatie te voltooien, dwz om een Identiteit te verkrijgen.

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

Het verschil tussen deze twee providers is lastig maar belangrijk.

• Identity Provider is een service die authenticatie (AuthN) biedt en identiteiten uitgeeft.

Je kunt verschillende verklaringen vinden over Service Provider van Google, hoewel ze misschien niet bevredigend zijn. In mijn gedachten is Service Provider een relatief concept:

• Service Provider (of Relying Party in OIDC) is een dienst of client die authenticatie (AuthN) initieert en het resultaat aanvraagt bij Identity Providers.

Quiz#

Overweeg een typisch scenario van sociaal inloggen:

❓ Hoeveel Service Providers en Identity Providers zijn er in deze grafiek?

Antwoord

Beide hebben er twee. iOS App is een serviceprovider voor Logto, terwijl Logto een identiteit provider is. Logto is ook een serviceprovider voor GitHub, terwijl GitHub een identiteit provider is. Dus, Logto is zowel een Service Provider als een Identiteit Provider.

Case study: een tech oplossing bedrijf#

Je bent een CTO van een tech oplossing bedrijf, je hebt meer dan 100 zakelijke partners en je hebt meer dan 300 projecten opgeleverd.

• Elk project is ofwel een web app of een mobiele app met een back-end service.
• Voor elke zakelijke partner wil je het gebruikerssysteem opnieuw inrichten om SSO over zijn projecten te bieden.

❓ Hoe kan Logto (of een CIAM-product) helpen?

Antwoord

Maak een Logto-instantie voor elke zakelijke partner. Elke partner heeft een Huurder. Projecten worden in Logto aan "Apps" gekoppeld.

Logto biedt een universele inlogervaring (dwz SSO) binnen een Huurder, zodat gebruikers niet opnieuw hoeven in te loggen wanneer ze een andere app in dezelfde Huurder openen als ze al zijn ingelogd.

Waar we het over hebben als we het over SSO hebben#

We hebben gemerkt dat de term “SSO” vaak verwarring veroorzaakt. Wij beschouwen single sign-on (SSO) als een gedrag, niet als een bedrijfsconcept. Daarom staat SSO niet gelijk aan “SSO in WIAM”.

Wanneer wij zeggen “het heeft SSO nodig”, kan het verwijzen naar een van de volgende gevallen:

SSO-geval 1#

👉🏽 In een groot bedrijf gebruiken werknemers dezelfde inloggegevens om toegang te krijgen tot alle door het bedrijf gelicentieerde bronnen (bijv. e-mail, IM, clouddiensten).

Het is het typische WIAM-scenario. In dit geval is er slechts één Identity Provider betrokken. Daar zijn we nu niet mee bezig.

SSO-geval 2#

👉🏽 Eindgebruikers gebruiken dezelfde inloggegevens om in te loggen op alle diensten die door hetzelfde bedrijf zijn ontwikkeld (bijv. GSuite).

Logto richt zich momenteel op de hierboven beschreven aanpak. Meerdere externe identiteit providers, zoals een derde partij sociaal inloggen provider, kunnen onafhankelijk en zonder verbinding bestaan.

Desondanks blijft Logto de enige waarheid voor identiteiten, simpelweg "lenen" ze van andere providers. In dit geval fungeert Logto zowel als een Identity Provider (voor GSuite-apps) als een Service Provider (voor externe Identity Providers).

SSO-geval 3#

👉🏽 Eindgebruikers kunnen alleen de specifieke Identity Provider binnen het overeenkomstige e-maildomein gebruiken om authenticatie te voltooien. Bijvoorbeeld inloggen op Figma met Google Workspace.

Dit is het meest voorkomende gebruiksscenario voor SSO in CIAM. Laten we eens nader bekijken.

Als we willen inloggen op Figma met ons @silverhand.io e-mail, kunnen we sociaal inloggen of SSO gebruiken. De figuren hieronder illustreren het verschil tussen de twee:

In woorden:

• Na sociaal inloggen kunnen gebruikers vrijelijk een wachtwoord instellen of het e-mailadres wijzigen in Figma
• Na SSO kunnen gebruikers geen wachtwoord instellen of persoonlijke informatie, inclusief hun e-mailadres, wijzigen, omdat hun identiteiten worden beheerd door Google Workspace

In dit geval is Logto zowel een Identity Provider als een Service Provider. Het lijkt erop dat SSO complexer is dan een normaal inlogproces. Wat zijn de voordelen voor de identiteits eigenaar?

• Gecentraliseerde controle: Houd identiteit informatie en authenticatieprocessen op één plek en zorg ervoor dat gebruikerinformatie altijd up-to-date is. Er is geen behoefte om licenties toe te voegen en te verwijderen voor wijzigingen in verschillende toepassingen.
• Verbeterde gebruikerservaring: Identiteits eigenaren die SSO vereist zijn meestal bedrijven. Hun werknemers kunnen dezelfde inloggegevens en gedeelde sessie gebruiken voor bedrijfsoverschrijdende toepassingen, zoals Figma, Zoom, Slack, enz.
• Verhoogde beveiliging: Je hebt misschien gemerkt dat sommige bedrijven specifieke inlogmethoden vereisen, zoals dynamische verificatiecodes. Het gebruik van SSO kan ervoor zorgen dat elke werknemer dezelfde combinatie van inlogmethoden voor toegang tot alle bronnen gebruikt.

🤔 Slim zoals jij moet hebben opgemerkt dat dit eigenlijk SSO-geval 1 is vanuit het SaaS-perspectief.

Het is tijd om de "X" in het SSO-schema te bespreken. Dit vertegenwoordigt het proces van Figma dat het e-maildomein verbindt met een specifieke Identity Provider. Maar, hoe werkt het?

SSO-mapping#

Omdat het verzoek vaak afkomstig is van zakelijke klanten, verwijzen we naar het proces van "SSO-geval 3" uit de vorige sectie als "Enterprise SSO" voor de duidelijkheid.

We kunnen gemakkelijk een eenvoudige oplossing bedenken: een mapping creëren tussen e-maildomeinen en SSO-methoden, en deze vervolgens handmatig bijwerken.

De actie van proces “X” is nu duidelijk:

🔍 Vind de gekoppelde Enterprise SSO-methode van het gegeven e-maildomein

Dus, als je silverhand.io configureert als een geldig e-maildomein dat is verbonden met een Google Workspace SSO-URL, worden gebruikers die proberen in te loggen met een @silverhand.io e-mail doorgestuurd naar de overeenkomstige Google Workspace-inlogpagina, in plaats van in plaats te worden verwerkt.

Wanneer je slechts enkele tientallen klanten hebt die Enterprise SSO nodig hebben, is het handmatig beheren van de mapping prima. Er zijn echter meer overwegingen waarmee rekening moet worden gehouden:

1. Wat als er honderden of duizenden Enterprise SSO-klanten zijn?
2. Wat is de relatie tussen “normale gebruikers” en “Enterprise SSO-gebruikers”?
3. Moeten gegevens geïsoleerd worden tussen verschillende Enterprise SSO-klanten?
4. Is er een noodzaak voor een dashboard voor de Enterprise SSO-beheerders om actieve gebruikers, auditlogs, enz. weer te geven?
5. Hoe kunnen accounts automatisch gedeactiveerd worden wanneer een gebruiker wordt verwijderd van de Enterprise SSO Identity Provider?

En nog veel meer. Omdat bijna alle Enterprise SSO e-maildomein-gebaseerd zijn, kunnen we snel een betere oplossing bedenken:

• Als de gebruiker kan bewijzen dat hij eigenaar is van dat domein, kan hij de Enterprise SSO van dat domein zelf inrichten.

Deze oplossing beantwoordt de eerste twee vragen:

1. Wat als er honderden of duizenden Enterprise SSO-klanten zijn?

• Ze kunnen Enterprise SSO op een zelfbedienings manier configureren.

2. Wat is de relatie tussen “normale gebruikers” en “Enterprise SSO-gebruikers”?

• We stellen alle mogelijke inlogmethoden open voor normale gebruikers, behalve Enterprise SSO; terwijl we de inlogmethode beperken tot alleen Enterprise SSO voor de gebruikers die proberen in te loggen met de geconfigureerde domeinen.

Wat betreft de derde vraag:

3. Moeten gegevens geïsoleerd worden tussen verschillende Enterprise SSO-klanten?

• Ja en nee. Het is tijd om organisatie te introduceren.

Organisatie#

We hebben eerder gezegd dat we e-maildomeinen gebruiken om de specifieke Enterprise SSO-methode te herkennen die moet worden gebruikt; met andere woorden, een specifieke behandeling toepassen voor een specifieke groep gebruikers.

De klantvereisten zijn echter vaak meer dan alleen Enterprise SSO; bijvoorbeeld vragen 4 en 5 in de vorige sectie. In de loop der jaren heeft een volwassen model zich ontwikkeld door uitstekende SaaS-bedrijven om dit soort problemen aan te pakken: Organisaties.

Organisatieregels

1. Een organisatie is een groep identiteiten, meestal kleiner dan een Huurder.
2. Alle organisaties zijn verbonden met een Huurder.

Je kunt andere termen zien, zoals "Workspace", “Team”, of zelfs "Huurder" in de software. Om te identificeren of het het concept is dat we bespreken, controleer gewoon of het “een groep identiteiten” vertegenwoordigt.

In dit artikel gebruiken we de term "Organisatie" voor consistentie.

In Notion kun je meerdere werkruimtes (d.w.z. Organisaties) maken en eraan deelnemen met hetzelfde e-mailadres en er gemakkelijk tussen switchen.

Bij Slack lijkt het hetzelfde, maar we vermoeden dat het verschillende Identiteiten gebruikt achter de schermen, aangezien we een nieuw account moeten aanmaken voor elke werkruimte.

Notion heeft een “Personal Plan” beschikbaar, dat normaal gezien een Organisatie is onder de motorkap, met de enige gebruiker (jij) erin. We weten de exacte implementatie van Notion niet, maar deze uitleg is redelijk en haalbaar voor ons model.

Elke Organisatie heeft ook een identificator, meestal aangeduid als het “Organisatie domein”.

Quiz#

❓ Kan een app worden geassocieerd met een Organisatie?

Antwoord

Ja ja. Zoals we in het begin hebben besproken, kan een app een Identiteit hebben. Kun je een bedrijfsscenario van dit illustreren?

Vragen blijven#

3. Moeten gegevens geïsoleerd worden tussen verschillende Enterprise SSO-klanten?

• Ja: Isoleer bedrijfsgegevens, zoals berichten en documenten, op organisatieniveau.
• Nee: Houd Identiteiten onafhankelijk, aangezien ze niet hoeven te worden geassocieerd met een Organisatie.
• Merk op dat er drie verschillende entiteiten hier betrokken zijn: Identiteiten, Organisaties, en Enterprise SSO-configuraties, wat opmerkelijk de complexiteit heeft vergroot. De vraag zelf is niet specifiek genoeg.

4. Is er een noodzaak voor een dashboard voor de Enterprise SSO-beheerders om actieve gebruikers, auditlogs, enz. weer te geven?

5. Hoe kunnen accounts automatisch gedeactiveerd worden wanneer een gebruiker wordt verwijderd van de Enterprise SSO Identity Provider?

• Deze eisen zijn meer bedrijfsgericht en kunnen op organisatieniveau worden geïmplementeerd. We laten ze hier open.

Afsluitende notities#

We hebben verschillende concepten geïntroduceerd: Authenticatie (AuthN), Autorisatie (AuthZ), Identiteit, Huurder, Applicatie, Identity Provider (IdP), Service Provider (SP), Single sign-on (SSO), en Enterprise SSO (Organisatie). Het kan enige tijd duren om ze allemaal te begrijpen.

Terwijl ik dit artikel schreef, merkte ik op dat interessant genoeg de duurste plannen van online diensten vaak exclusieve functies bevatten die verband houden met autorisatie, wat totaal niet wordt genoemd in dit artikel. Je hebt misschien al enkele vragen over autorisatie, zoals:

• Hoe kunnen we rechten toekennen aan een gebruiker en deze verifiëren?
• Welk autorisatiemodel moet ik gebruiken?
• Wat is de beste praktijk voor het toepassen van een autorisatiemodel?