CIAM 101: Todennus, Identiteetti, SSO

Tausta#

Aloitin Logton rakentamisen, koska huomasin, että identiteetin ja pääsynhallinnasta (IAM) oli tullut ajan myötä yhä monimutkaisempaa ja laajempaa. IAM-konsepti on jopa tarpeeksi laaja synnyttääkseen uusia konsepteja, kuten WIAM (Workforce IAM) ja CIAM (Customer IAM).

Vaikka WIAM ja CIAM jakavat saman perustan, niillä on erilaiset käyttötapaukset: WIAM:ia käytetään tyypillisesti sisäisille käyttäjille, kun taas CIAM:ia käytetään ulkoisille asiakkaille. Joillain esimerkeillä:

• WIAM Yritykselläsi on yhtenäinen identiteettijärjestelmä työntekijöille, joten jokainen voi käyttää samaa tiliä päästäkseen yrityksen resursseihin, kuten ohjelmistotilauksiin, pilvipalveluihin jne.
• CIAM Sinun verkkokirjakauppasi vaatii käyttäjäidentiteettijärjestelmän asiakkaille ja myyjille. Sisäänkirjautumiskokemus on kriittinen osa onboardingia, sillä se sijaitsee muunnosketjun yläpäässä.

Logto aloitti CIAM:illa eri syistä (meillä on toinen artikkeli tästä aiheesta). Kehityksen aikana huomasimme, että yhtenäisen ymmärryksen luominen tiimin kesken olisi hyödyllistä ennen tuotteemme viemistä seuraavalle tasolle. Toivomme, että tämä auttaa sinua myös saamaan paremman käsityksen IAM-kentästä.

Aloitetaan!

CIAM:n perusteet#

Tässä artikkelissa keskitymme CIAM:n peruskäsitteisiin ja ongelmiin, joita voimme kohdata autentikointiprosessin aikana tai sen jälkeen. Keskustelemme myös kertakirjautumisesta (SSO) ja siihen liittyvistä skenaarioista.

Todennus ja valtuutus#

💡 Todennus on alun perin määritelty kysymyksellä "Kuka olet?". Kuitenkin, kun puhutaan digitaalisista identiteeteistä, on tarkempaa osoittaa todennus "identiteetin omistuksen todistamisella". (Kiitos Calm-Card-2424)

Jos havaitset jotain, joka ei sovi kumpaankaan näistä kahdesta kategoriasta, se ei luultavasti ole olennainen identiteettiliiketoiminnassa.

• Esimerkkejä todennuksesta
  • Salasanakirjautuminen, salasanaton kirjautuminen, sosiaalinen kirjautuminen jne.
  • Koneiden välinen todennus
• Esimerkkejä valtuutuksesta
  • Roolipohjainen pääsynhallinta
  • Attribuuttipohjainen pääsynhallinta
• Poikkeusten esimerkkejä
  • Ei-identiteettitiedot
  • Webhooks

Identiteetti ja vuokralainen#

Identiteetti edustaa tyypillisesti joko käyttäjää tai konetta. Onnistuneen todennuksen jälkeen myönnetään ID Token identiteettinä.

Toisin sanoen todennuksen pääasiallinen tarkoitus on saada Identiteetti.

Vuokralainen on ryhmä identiteettejä:

Kun puhumme "monivuokralaisuudesta", tarkoitamme useita Logto-instansseja, jotka ovat identiteetistä eristyksissä toisistaan. Toisin sanoen useita Logto-instansseja.

Huomaa, että siinä on kaksi eristettyä identiteettijärjestelmää, eli et voi käyttää Vuokralaisen 1 identiteettiä Vuokralaisessa 2, vaikka sama tunniste (sähköposti, puhelin jne.) olisi käytössä. Se on kuin Costcon jäsenyytesi ei olisi voimassa Whole Foodsissa.

Sovellus ja vuokralainen#

Aivan kuten identiteetti, myös sovellus kuuluu vuokralaiselle. Muutama asia muistaa:

• Tyypillisesti sovelluksella ja identiteetillä ei ole suoraa yhteyttä.
  • Identiteetti voi edustaa sovellusta, mutta niiden välillä ei ole suoraa yhteyttä.
• Kuten käyttäjät, myös sovellukset ovat vuokratason mukaisia.
• Sovellukset ovat koodia, kun taas käyttäjät ovat ihmisiä.
• Sovellusten ainoa tarkoitus on suorittaa todennus, eli saavuttaa identiteetti.

Identiteettipalveluntarjoaja (IdP) ja palveluntarjoaja (SP)#

Näiden kahden tarjoajan ero on hankala mutta tärkeä.

• Identiteettipalveluntarjoaja on palvelu, joka tarjoaa todennuksen (AuthN) ja myöntää identiteettejä.

Voit löytää erilaisia selityksiä palveluntarjoajista Googlesta, vaikka ne eivät ehkä ole tyydyttäviä. Mielestäni palveluntarjoaja on suhteellinen käsite:

• Palveluntarjoaja (tai Luottamuspuolue OIDC) on palvelu tai asiakas, joka aloittaa todennuksen (AuthN) ja pyytää tuloksia identiteettipalveluntarjoajilta.

Kysely#

Harkitse tyypillistä sosiaalisen kirjautumisen skenaariota:

❓ Kuinka monta palveluntarjoajaa ja identiteettipalveluntarjoajaa tässä kaaviossa on?

Vastaus

Molemmissa on kaksi. iOS-sovellus on palveluntarjoaja Logtolle, kun taas Logto on identiteettipalveluntarjoaja. Logto on myös palveluntarjoaja GitHubille, kun taas GitHub on identiteettipalveluntarjoaja. Näin ollen Logto on palveluntarjoaja ja identiteettipalveluntarjoaja.

Tapaustutkimus: Tekninen ratkaisuyritys#

Olet teknisen ratkaisuyrityksen CTO, sinulla on yli 100 liikekumppania ja olet toimittanut yli 300 projektia.

• Jokainen projekti on joko verkkosovellus tai mobiilisovellus taustapalvelulla.
• Jokaiselle liikekumppanille haluat uudistaa käyttäjäjärjestelmän tarjotaksesi SSO:n heidän projektissa.

❓ Kuinka Logto (tai CIAM-tuote) voi auttaa?

Vastaus

Luo Logto-instanssi kullekin liikekumppanille. Jokainen kumppani pitää hallussaan vuokralaista. Projektit kartoitetaan Logton "sovelluksiksi".

Logto tarjoaa universaalin sisäänkirjautumiskokemuksen (eli SSO) vuokralaisen sisällä, joten käyttäjien ei tarvitse kirjautua uudelleen sisään, kun he käyttävät toista sovellusta samassa vuokralaisessa, jos ovat jo kirjautuneet sisään.

Mitä tarkoittaa SSO:sta puhuminen#

Huomasimme, että termi "SSO" aiheuttaa usein sekaannusta. Meidän mielestämme kertakirjautuminen (SSO) on käyttäytymismalli, ei liiketoiminta-konsepti. Siksi SSO ei ole yhtä kuin “SSO WIAM:ssa”.

Kun sanomme ”se tarvitsee SSO:n”, se voi viitata johonkin seuraavista tapauksista:

SSO-tapaus 1#

👉🏽 Isossa korporaatiossa työntekijät käyttävät samoja tunnistetietoja kirjautuakseen kaikkiin yrityksen lisensioimiin resursseihin (esim. sähköposti, pikaviestit, pilvipalvelut).

Se on tyypillinen WIAM-skenaario. Tässä tapauksessa mukana on vain yksi identiteettipalveluntarjoaja. Emme välitä nyt siitä.

SSO-tapaus 2#

👉🏽 Loppukäyttäjät käyttävät samoja tunnistetietoja kirjautuakseen kaikkiin saman yrityksen kehittämiin palveluihin (esim. GSuite).

Logto keskittyy tällä hetkellä edellä kuvattuun lähestymistapaan. Useita ulkoisia identiteettipalveluntarjoajia, kuten kolmannen osapuolen sosiaalisen kirjautumisen tarjoaja, voi olla olemassa itsenäisesti ja ilman yhteyttä.

Tästä huolimatta Logto pysyy ainoana totuuden lähteenä identiteeteille, yksinkertaisesti "lainaten" niitä muilta tarjoajilta. Tässä tapauksessa Logto toimii sekä identiteettipalveluntarjoajana (GSuite-sovelluksille) että palveluntarjoajana (ulkoisille identiteettipalveluntarjoajille).

SSO-tapaus 3#

👉🏽 Loppukäyttäjät voivat käyttää vain tiettyä identiteettipalveluntarjoajaa sähköpostialueensa kontekstissa autentikoinnin suorittamiseen. Esimerkiksi kirjautuminen Figmaan Google Workspacen avulla.

Tämä on yleisin käyttötapaus SSO:ssa CIAM:ssa. Tarkastellaanpa tätä lähemmin.

Jos haluamme kirjautua Figmaan käyttämällä @silverhand.io-sähköpostiamme, voimme käyttää joko sosiaalista kirjautumista tai SSO:ta. Alla olevat kuvat havainnollistavat eroa näiden kahden välillä:

Sanoissa:

• Sosiaalisen kirjautumisen jälkeen käyttäjät voivat vapaasti asettaa salasanan tai muuttaa sähköpostiosoitetta Figmassa
• SSO:n jälkeen käyttäjät eivät voi asettaa salasanaa tai muuttaa mitään henkilökohtaisia tietoja, mukaan lukien sähköpostiosoitetta, koska heidän identiteettiään hallitsee Google Workspace

Tässä tapauksessa Logto on sekä identiteettipalveluntarjoaja että palveluntarjoaja. Näyttää siltä, että SSO on monimutkaisempi kuin tavallinen kirjautumisprosessi. Mitkä ovat identiteetin omistajan hyödyt?

• Keskitetty hallinta: Pidä identiteettitiedot ja kirjautumisprosessit yhdessä paikassa ja varmista, että käyttäjätiedot ovat aina ajan tasalla. Ei tarvitse lisätä ja poistaa lisenssejä eri sovelluksista muutosten takia.
• Parannettu käyttäjäkokemus: Identiteetin omistajat, jotka vaativat SSO:ta, ovat yleensä yrityksiä. Heidän työntekijänsä voivat käyttää samoja tunnistetietoja ja jaettua istuntoa poikkiyrityssovelluksille, kuten Figma, Zoom, Slack jne.
• Lisätty turvallisuus: Saatat olla huomannut, että jotkut yritykset vaativat tiettyjä kirjautumismenetelmiä kuten dynaamisia varmistuskoodeja. Käyttämällä SSO:ta voidaan varmistaa, että jokainen työntekijä käyttää samaa kirjautumismenetelmäyhdistelmää kaikkien resurssien käyttöön.

🤔 Fiksu kuten sinä varmaan huomasi tämän olevan itse asiassa SSO-tapaus 1 SaaS-näkökulmasta.

On aika keskustella "X":stä SSO-kaaviossa. Tämä edustaa prosessia, jossa Figma yhdistää sähköpostialueen tiettyyn identiteettipalveluntarjoajaan. Mutta miten se toimii?

SSO-kartoitus#

Koska pyyntö usein tulee yritysasiakkailta, viittamme edellisen osion "SSO Case 3" -prosessiin termillä "Enterprise SSO" selkeyden vuoksi.

Voimme helposti keksiä naiivin ratkaisun: luodaan kartoitus sähköpostialueiden ja SSO-menetelmien välille ja päivitetään sitä manuaalisesti.

Prosessin "X" toiminta on nyt selvä:

🔍 Löydä annetun sähköpostialueen mappaama Enterprise SSO-menetelmä

Näin, jos määrität silverhand.io:n kelvolliseksi sähköpostialueeksi, joka yhdistää Google Workspace SSO URL:iin, käyttäjät, jotka yrittävät kirjautua @silverhand.io:n sähköpostilla, ohjataan vastaavalle Google Workspace-kirjautumissivulle sen sijaan, että he käsitellään paikan päällä.

Kun sinulla on vain vähän kymmeniä asiakkaita, jotka tarvitsevat Enterprise SSO:n, manuaalinen kartoituksen hallinta on okei. Kuitenkin on otettava huomioon useampia asioita:

1. Entä jos on satoja tai tuhansia Enterprise SSO-asiakkaita?
2. Mikä on suhde “normaalien käyttäjien” ja “Enterprise SSO-käyttäjien” välillä?
3. Tuleeko data eristää eri Enterprise SSO-asiakkaiden välillä?
4. Onko tarvetta tarjota hallintapaneeli Enterprise SSO:n ylläpitäjille aktiivisten käyttäjien, tarkastuslokien jne. katseluun?
5. Kuinka tilit voidaan poista käytöstä automaattisesti, kun käyttäjä poistetaan Enterprise SSO identiteettipalveluntarjoajasta?

Ja paljon enemmän. Koska lähes kaikki Enterprise SSO:t perustuvat sähköpostialueeseen, voimme nopeasti keksiä paremman ratkaisun:

• Jos käyttäjä voi todistaa omistavansa kyseisen alueen, hän voi itsepalveluna asentaa kyseisen alueen Enterprise SSO:n.

Tämä ratkaisu vastaa ensimmäisiin kahteen kysymykseen:

1. Entä jos on satoja tai tuhansia Enterprise SSO-asiakkaita?

• He voivat itsepalveluna konfiguroida Enterprise SSO:n.

2. Mikä on suhde “normaalien käyttäjien” ja “Enterprise SSO-käyttäjien” välillä?

• Avaamme kaikki mahdolliset kirjautumismenetelmät normaaleille käyttäjille paitsi Enterprise SSO; Samaan aikaan rajoitamme kirjautumismenetelmää vain Enterprise SSO:lle niille käyttäjille, jotka yrittävät kirjautua sisään määritetyillä sähköpostialueilla.

Kolmanteen kysymykseen:

3. Tuleeko data eristää eri Enterprise SSO-asiakkaiden välillä?

• Kyllä ja ei. On aika esitellä organisaatio.

Organisaatio#

Mainitsimme käyttämällä sähköpostialueita tunnistamaan tietyn Enterprise SSO-menetelmän; toisin sanoen soveltamaan erityistä käsittelyä tiettyyn käyttäjäryhmään.

Kuitenkaan asiakkaiden vaatimukset eivät usein ole pelkästään Enterprise SSO; esimerkiksi kysymykset 4 ja 5 edellisessä kohdassa. Vuosien varrella kypsä malli on kehitetty erinomaisilla SaaS-yrityksillä ratkaisemaan tämän tyyppisiä ongelmia: Organisaatiot.

Organisaatiosäännöt

1. Organisaatio on identiteettien ryhmä, tyypillisesti pienempi kuin vuokralainen.
2. Kaikki organisaatiot liittyvät vuokralaiseen.

Saatat nähdä muita termejä, kuten "Workspace", “Team” tai jopa "Vuokralainen" ohjelmistossa. Tunnistaaksesi onko se konsepti, jota keskustelemme, tarkista vain, edustaako se “identiteettiryhmää”.

Tässä artikkelissa käytämme termiä "Organisaatio" johdonmukaisuuden vuoksi.

Notionissa voit luoda ja liittyä useisiin työtiloihin (eli organisaatioihin) samalla sähköpostiosoitteella ja vaihtaa niitä helposti.

Slackista näyttäisi olevan sama, mutta epäilemme, että se käyttää eri identiteettejä kulisseissa, koska meidän on luotava uusi tili jokaista työtilaa varten.

Notionilla on “Henkilökohtainen suunnitelma” käytettävissä, joka on normaali organisaatio kulissien takana, jossa olet ainoa käyttäjä. Emme tiedä tarkkaa Notionin toteutusta, mutta tämä selitys on järkevä ja saavutettavissa mallillamme.

Jokaisella organisaatiolla on myös tunniste, yleensä viitattu nimellä “Organisaatiodomain”.

Kysely#

❓ Voiko sovellus liittyä organisaatioon?

Vastaus

Kyllä kyllä. Kuten keskustelimme alussa, sovelluksella voi olla identiteetti. Voitko selittää liiketoimintaskenaarion tähän liittyen?

Jäljellä olevat kysymykset#

3. Tuleeko data eristää eri Enterprise SSO-asiakkaiden välillä?

• Kyllä: Eristää liiketoimintatiedot, kuten viestit ja dokumentit, organisaatiotasolla.
• Ei: Pidä identiteetit itsenäisinä, koska niiden ei tarvitse liittyä organisaatioon.
• Huomaa, että täällä on mukana kolme erillistä entiteettiä: identiteetit, organisaatiot ja Enterprise SSO-konfiguraatiot; mikä huomattavasti lisäsi monimutkaisuuden. Itse kysymys ei ole riittävän tarkka.

4. Onko tarvetta tarjota hallintapaneeli Enterprise SSO:n ylläpitäjille aktiivisten käyttäjien, tarkastuslokien jne. katseluun?

5. Kuinka tilit voidaan poista käytöstä automaattisesti, kun käyttäjä poistetaan Enterprise SSO identiteettipalveluntarjoajasta?

• Nämä tarpeet ovat enemmän liiketoimintaan liittyviä ja ne voidaan toteuttaa organisaatiotasolla. Jätämme ne avoimeksi tähän.

Päätöshuomatukset#

Olemme esitelleet useita käsitteitä: Todennus (AuthN), Valtuutus (AuthZ), Identiteetti, Vuokralainen, Sovellus, Identiteettipalveluntarjoaja (IdP), Palveluntarjoaja (SP), Kertakirjautuminen (SSO) ja Enterprise SSO (organisaatio). Näiden kaikkien käsitteiden ymmärtäminen voi viedä aikaa.

Kirjoittaessani tätä artikkelia huomasin, että mielenkiintoisesti verkkopalveluiden kalleimmat suunnitelmat sisältävät usein yksinoikeudella liittyviä ominaisuuksia valtuutukseen, jota ei ollenkaan mainita tässä artikkelissa. Saatat jo kysyä joitakin kysymyksiä valtuutuksesta, kuten:

• Kuinka voimme antaa oikeuksia käyttäjälle ja varmistaa ne?
• Mitä valtuutusmallia minun pitäisi käyttää?
• Mikä on paras käytäntö soveltaa valtuutusmallia?