## Tausta [Edellisessä artikkelissa](/ciam-101-intro-authn-sso/) esittelimme käsitteen todennus (AuthN) ja valtuutus (AuthZ), sekä joitakin päänsärkyä aiheuttavia termejä: Identiteetti, Organisaatio, Vuokralainen jne. Organisaatio ja Vuokralainen ovat erinomaisia identiteettien ryhmittelyyn, mutta ne johtavat täydelliseen demokratiaan: jokainen voi tehdä mitä tahansa tässä järjestelmässä. Vaikka utopia on vielä mysteeri, tutustutaanpa käyttöoikeuksien hallintaan: Valtuutus (AuthZ). ### Miksi tarvitsemme valtuutusta? Valtuutus (AuthZ) vastaa kysymykseen ”Mitä voit tehdä?” Notion on loistava esimerkki. Jokaiselle hallitsemallesi sivulle voit valita, pidätkö sen yksityisenä itsellesi, jaatko sen ystävien kanssa tai jopa julkiseksi. Tai, kun ajatellaan verkkokirjakauppaa, haluat kaikkien voivan tarkastella kaikkia kirjoja, mutta asiakkaat voisivat katsoa vain omia tilauksiaan, ja myyjät hallita vain omaan liikkeeseensä kuuluvia kirjoja. AuthZ ja AuthN ovat olennaisia osia monimutkaisessa liiketoimintamallissa. Ne menevät usein käsi kädessä; AuthZ tarkistaa käyttäjän käyttöoikeudet, kun taas AuthN todentaa identiteetit. Molemmat ovat välttämättömiä turvallisessa järjestelmässä. ## Perusteet valtuutusmallille Tässä on yksi yleisimmistä AuthZ-malleista: Jos **IDENTITEETTI** tekee **TOIMINTO** **RESURSSILLA**, sitten **HYVÄKSY** tai **ESTÄ**. Notion-esimerkissä malli on **HENKILÖ** tekee **TARKASTELE** **SIVULLA.** Jos sivu on yksityinen: - Saat **HYVÄKSY**, kun suoritat **TARKASTELE** omalla **SIVULLASI**. - Kaikkien muiden tulisi saada **ESTÄ**, kun he suorittavat **TARKASTELE** omalla **SIVULLASI**. Yhteisymmärrykseen perustuessa teollisuus kehitti erilaisia valtuutusteknologioita, kuten Roolipohjainen Käyttöoikeuksien Hallinta (RBAC), Ominaisuuspohjainen Käyttöoikeuksien Hallinta (ABAC). Tänään keskitymme [NIST RBAC-malliin](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Tasolla 1: Tasainen RBAC. ## Roolipohjainen Käyttöoikeuksien Hallinta NIST RBAC-malli jätti monia asioita avoimeksi tarjotakseen joustavuutta ja sopeutumiskykyä eri skenaarioille. Logto ottaa nyt käyttöön Tason 1 määritelmän lisäkäsitteen "Resurssi" (eli API Resurssi) kanssa. Laajennetaan kirjakauppaesimerkkiä. Oletetaan, että meillä on monia asiakkaita, mutta vain yksi myyjä: - Asiakkaat voivat katsella ja tilata kirjoja, sekä tarkastella omia tilauksiaan. - Myyjä voi tarkastella, luoda ja poistaa kirjoja, ja hallita asiakastilauksia. ### Määritä resurssit Logto-ohjelmassa resurssi (eli API Resurssi) edustaa yleensä joukkoa entiteettejä tai kohteita, koska sen vaaditaan käyttävän kelvollista URL-osoitetta indikaattorina. Siksi määrittelemme kaksi resurssia: - Kirjat: `https://api.bookstore.io/books` - Tilaukset: `https://api.bookstore.io/orders` Yksi URL-muodon noudattamisen eduista on, että se voi karttaa todelliseen API-palvelusi osoitteeseen, mikä parantaa luettavuutta ja tunnistettavuutta, kun se integroidaan muihin järjestelmän osiin. 🤔 Resurssit tulisi jakaa liiketoiminnan tarpeiden mukaan. Ei ole olemassa yhdelle sopiva kaikille -lähestymistapaa; päätöksen tulee perustua tapaus kerrallaan. Tämän artikkelin esimerkki jakaa Kirjat ja Tilaukset saattaa sopia mikropalveluille, muttei monoliittiselle arkkitehtuurille. ### Määritä käyttöoikeudet Koska esittelimme resurssin käsitteen, Logto-ohjelmassa vaadimme myös, että käyttöoikeuksien on kuuluttava resurssiin, toisin päin, resurssit voivat omistaa käyttöoikeuksia. Lisätään resursseille joitakin käyttöoikeuksia: - Kirjat: `lukea`, `luoda`, `poistaa` - Tilaukset: `lukea`, `lukea:itse`, `luoda:itse`, `poistaa` Vaikka käyttöoikeuden nimeämiselle ei ole vaatimuksia, meillä on seuraava konventio: ``` [:] ``` Kun `` on pakollinen kuvaamaan käyttöoikeutta, `:` voidaan ohittaa kuvaamaan yleistä kohdetta, eli kaikkia resurssin entiteettejä tai kohteita. Esimerkiksi: - Käyttöoikeus `lukea` resurssissa Kirjat tarkoittaa toimintoa lukea mielivaltaisia kirjoja. - Käyttöoikeus `luoda:itse` resurssissa Tilaukset tarkoittaa toimintoa luoda tilauksia, jotka kuuluvat nykyiselle käyttäjälle. ### Määritä roolit Lyhyesti, rooli on ryhmä käyttöoikeuksia. Luodaan kaksi roolia `asiakas` ja `myyjä` ja liitetään niille käyttöoikeuksia seuraavasti: ```mermaid erDiagram Rooli-Asiakas { käyttöoikeus Kirjat "lukea" käyttöoikeus Tilaukset "lukea:itse" käyttöoikeus Tilaukset "luoda:itse" } Rooli-Myyjä { käyttöoikeus Kirjat "lukea" käyttöoikeus Kirjat "luoda" käyttöoikeus Kirjat "poistaa" käyttöoikeus Tilaukset "lukea" käyttöoikeus Tilaukset "poistaa" } ``` Saatat huomata, että käyttöoikeus-rooliliitokset ovat moni-moni-suhteita. ### Roolien asettaminen käyttäjille Aivan kuten rooli-käyttöoikeus-liitokset, käyttäjä-rooli-liitokset ovat myös moni-moni-suhteita. Siksi voit asettaa useita rooleja yhdelle käyttäjälle, ja yksi rooli voidaan asettaa useille käyttäjille. ### Yhdistä pisteet Tässä on täydellinen suhteiden kaavio Logton Tason 1 RBAC-mallista: ```mermaid erDiagram Käyttäjä }|--|{ Rooli : kartat Rooli }|--|{ Käyttöoikeus : kartat "API Resurssi" ||--|{ Käyttöoikeus : sisältää ``` RBAC-mallissa käyttöoikeudet ovat aina "positiivisia", mikä tarkoittaa, että valtuutusarviointi on yksinkertaista: jos käyttäjällä on käyttöoikeus, hyväksy; muuten, hylkää. Oletetaan, että Alice on myyjäroolissa, Bob ja Carol ovat asiakasroolissa. Kuvaamme toimet ensin luonnollisella kielellä ja käännämme ne sitten tavalliseen valtuutusmuotoon: **IDENTITEETTI** tekee **TOIMINTO** **RESURSSILLA**, antamalla lopulta johtopäätöksen. - Alice haluaa lisätä uuden kirjan myyntiin: - Käyttäjä Alice tekee `luoda` resurssilla Kirjat (`https://api.bookstore.io/books`). - Koska Alicelle on määritelty käyttöoikeus `luoda` kirjoille heidän roolinsa `myyjä` perusteella, tulos on ✅ **HYVÄKSY**. - Alice haluaa tarkastella kaikkia tilauksia nähdäkseen, täyttävätkö ne odotukset: - Käyttäjä Alice tekee `lukea` resurssilla Tilaukset (`https://api.bookstore.io/orders`). - Koska Alicelle on määritelty käyttöoikeus `lukea` tilauksille heidän roolinsa `myyjä` perusteella, tulos on ✅ **HYVÄKSY**. - Bob haluaa selata kirjaluetteloa nähdäkseen, onko siellä kirjoja, joita hän haluaa ostaa. - Käyttäjä Bob tekee `lukea` resurssilla Kirjat (`https://api.bookstore.io/books`). - Koska Bobille on määritelty käyttöoikeus `lukea` kirjoille heidän roolinsa `asiakas` perusteella, tulos on ✅ **HYVÄKSY**. - Bob haluaa tarkastella Carolin tilausta. - Koska se on jonkun toisen tilaus, käyttöoikeus `lukea:itse` `Tilaukset` ei toimi tässä. - Käyttäjä Bob tekee `lukea` resurssilla Tilaukset (`https://api.bookstore.io/order`). - Koska Bobilla ei ole käyttöoikeutta `lukea` tilauksille, tulos on ❌ **ESTÄ**. ### Muut RBAC-tasot NIST RBAC-mallissa on neljä tasoa: - Tasainen RBAC - Hierarkkinen RBAC - Rajoitettu RBAC - Symmetrinen RBAC Katso [paperi](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) yksityiskohtia, jos olet kiinnostunut. Logto:lla on nyt Tason 1 toteutus ja se etenee korkeammille tasoille yhteisön palautteen perusteella. Älä epäröi kertoa meille, jos korkeampi taso sopii tarpeisiisi! ## Käytännössä Teorian lisäksi meillä on vielä raskasta teknistä työtä, jotta malli toimisi odotetusti: - Asiakas- ja todennuspalvelimen kehitys - RBAC:n tietokantasuunnittelu - Vahvistaminen eri palveluiden välillä - Turvallisuus ja avoimien standardien noudattaminen - Roolien, käyttöoikeuksien ja resurssien hallinta ja määräykset Älä panikoi. Olemme ottaneet tämän huomioon ja lisänneet valmiiksi tukea kaikkien edellä mainittujen asioiden kattamiseksi. Tutustu [🔐 RBAC-reseptiin](https://docs.logto.io/docs/recipes/rbac/) oppiaksesi käyttämään RBAC:ia Logtossa. ## Loppusanat RBAC on tehokas käyttöoikeuksien hallintamalli useimmissa tapauksissa, mutta siitä ei ole hopealuotia. Meillä on silti joitakin kysymyksiä: - Tarvitsenko RBAC:n korkeita tasoja? - Kuinka RBAC vertautuu muihin valtuutusmalleihin? - Kuinka määrittää valtuutusmalli eri Organisaatioiden välillä? 🔥 Pysy kuulolla. Nähdään CIAM 103:ssa!