CIAM 102: Valtuutus ja Roolipohjainen Käyttöoikeuksien Hallinta

Tausta#

Edellisessä artikkelissa 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?#

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 Tasolla 1: Tasainen RBAC.

Roolipohjainen Käyttöoikeuksien Hallinta#

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.

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 <toiminto> on pakollinen kuvaamaan käyttöoikeutta, :<kohde> 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:

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:

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 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 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ä?