CIAM 102: Valtuutus ja Roolipohjainen Käyttöoikeuksien Hallinta
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).
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).
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ä.
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.
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.
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.
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 TOIMINTORESURSSILLA, 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:itseTilaukset 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Ä.
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!
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.