## 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 Huolimatta niiden eroavaisuuksista WIAM ja CIAM jakavat molemmat saman perustan: todennus ja valtuutus. Nämä kaksi käsitettä ovat niiden ominaisuuksien ytimessä. 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 (AuthN) vastaa kysymykseen "Mikä identiteetti sinulla on?" - Valtuutus (AuthZ) vastaa kysymykseen "Mitä voit tehdä?" > 💡 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](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) 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ä: ```mermaid graph TD Vuokralainen --- A[Identiteetti: Käyttäjä 1] Vuokralainen --- B[Identiteetti: Käyttäjä 2] Vuokralainen --- C[Identiteetti: Kone 1] ``` Kun puhumme "monivuokralaisuudesta", tarkoitamme useita Logto-instansseja, jotka ovat identiteetistä eristyksissä toisistaan. Toisin sanoen useita Logto-instansseja. ```mermaid graph TD T1[Voukralainen 1] --- A[Identiteetti: Käyttäjä 1] T2[Voukralainen 2] --- B[Identiteetti: Käyttäjä 1] T2[Voukralainen 2] --- C[Identiteetti: Kone 1] subgraph IS2[Identiteettijärjestelmä 2] T2 B C end subgraph IS1[Identiteettijärjestelmä 1] T1 A end ``` 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. 🧱 Lyhyesti sanottuna vuokralaisten välillä on “fyysiset seinät”. "Vuokralaisen" määritelmä vaihtelee eri CIAM-tuotteissa. Jotkut viittaavat termiin "Organisaatio" Logtossa, joka esitellään myöhemmin. ### 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](https://openid.net/specs/openid-connect-core-1_0.html))** on palvelu tai asiakas, joka aloittaa todennuksen (AuthN) ja pyytää tuloksia identiteettipalveluntarjoajilta. #### Kysely Harkitse tyypillistä sosiaalisen kirjautumisen skenaariota: ```mermaid graph LR A[iOS-sovellus] --> |Aloita kirjautuminen| Logto --> |Uudelleenohjaus| GitHub GitHub --> |Palauta GitHub ID| Logto --> |Palauta Logto ID| A ``` **❓ 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". ```mermaid graph TD T1[Vuokralainen 1] --- A[Sovellus 1] T1 --- B[Sovellus 2] T1 --- C[Sovellus 3] T1 --- U1[Käyttäjä 1] T1 --- U2[Käyttäjä 2] T2[Vuokralainen 2] --- D[Sovellus 1] T2 --- E[Sovellus 2] T2 --- U21[Käyttäjä 1] T2 --- U22[Käyttäjä 2] ``` 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. 🤹🏽‍♀️ Useimmissa tapauksissa "identiteettiryhmällä" on sama merkitys kuin "käyttäjäryhmällä". Kuitenkin, **sama identiteetti voi esiintyä useassa organisaatiossa**. 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.

![Slackin työtilat](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slackin työtilat_ ![Notionin työtilat](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notionin työtilat_

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”. "Organisaatiodomain" on sisäinen tunniste, jota käytetään erottamaan organisaatiot. Se voi poiketa "sähköpostidomainista", koska edellisen hallinnoi palveluntarjoaja, kun taas jälkimmäinen on yleensä ulkoisen identiteettipalveluntarjoajan tarjoama. Voit esimerkiksi käyttää `foo` organisaatiodomainina Slackissä, mutta käyttää `@bar.io` sähköpostidomainina tälle organisaatiolle. ### 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? 🔥 Pidä tauko ja nähdään CIAM 102:ssa!