RBAC hallitseminen Logtossa: kattava käytännön esimerkki

Johdanto#

Pääsynhallinta ja turvallisuus ovat olennaisia osia nykyaikaisissa sovelluksissa, varmistamassa, että käyttäjillä on asianmukainen pääsy resursseihin. Logton Role-Based Access Control (RBAC) tarjoaa kehittäjille tehokkaan tavan hallita pääsynhallintaa ja turvallisuutta sovelluksissa. Tässä artikkelissa tutkimme Logton RBAC:n voimakkaita ominaisuuksia käyttäen oikean maailman esimerkkiä, auttaen sinua ymmärtämään ja soveltamaan näitä käsitteitä omiin projekteihisi.

Tarkastelemalla sekä frontend- että backend-koodipätkiä saat kattavan käsityksen Logton RBAC:n integroimisesta sovelluskokonaisuuteesi. Artikkelin lopussa olet hyvin varustautunut hyödyntämään Logton RBAC-ominaisuuksia parantaaksesi projektisi turvallisuutta ja pääsynhallintaa.

BookHarberin esittely: Verkkokirjakaupan esimerkkitapaus#

Logton RBAC-ominaisuuksien tehokkaaksi esittelemiseksi käytämme oikeaa esimerkkiä: BookHarberia, verkkokirjakauppaa. BookHarber tarjoaa laajan valikoiman ominaisuuksia asiakkaille ja henkilökunnalle, varmistaen saumattoman ja turvallisen ostokokemuksen.

BookHarberin tärkeimpiä ominaisuuksia ovat:

1. Kirjojen selaaminen ja ostaminen: Käyttäjät voivat helposti etsiä ja ostaa kirjoja monipuolisesta kokoelmasta, joka kattaa erilaisia genrejä ja kirjailijoita.
2. Tilausten hallinta ja logistiikan seuranta: Rekisteröityneet asiakkaat voivat hallita tilauksiaan, seurata toimituksia ja saada päivityksiä ostoksistaan.
3. Erikoistarjoukset ja lomatoiminnot: BookHarber tarjoaa yksinomaisia alennuksia ja kampanjoita erityistapahtumina ja lomien aikana sitouttaakseen ja palkitakseen asiakaskuntaansa.
4. Asiakaspalvelu: Asiakkaat voivat avata tukilippuja käsittelemään huolia tai ongelmia, joita he saattavat kohdata, ja saavat BookHarberin henkilökunnan nopeaa apua.
5. Asiakashallinta: Henkilökunnan erilaisilla rooleilla on mahdollisuus hallita alustan erilaisia osa-alueita, kuten asiakastilejä, tilausten käsittelyä ja ongelmien ratkaisua.

Roolit#

BookHarber-ekosysteemissä voimme tunnistaa useita keskeisiä käyttäjärooleja, kuten:

1. Vierailija: Rekisteröitymättömät käyttäjät, jotka voivat selata verkkosivustoa, etsiä kirjoja ja nähdä erityistarjouksia.
2. Asiakas: Rekisteröityneet käyttäjät, jotka voivat ostaa kirjoja, hallita tilauksia, seurata logistiikkaa ja avata tukilippuja.
3. Kaupan ylläpitäjä: Henkilökunnan jäsenet, jotka vastaavat alustan yleisestä hallinnasta ja toiminnasta. Koko pääsy.
4. Kirjapäällikkö: Henkilökunnan jäsenet, jotka vastaavat kirjojen ja kategorioiden hallinnasta.
5. Asiakaspalveluagentti: Henkilökunnan jäsenet, joiden tehtävänä on vastata tukilippuihin.
6. Kolmannen osapuolen logistiikkatoimittaja: Ulkoiset kumppanit, jotka vastaavat tilausten toimituksen ja seurannan hallinnasta.
7. Markkinointihenkilöstö: Henkilökunnan jäsenet, jotka ovat vastuussa BookHarberin markkinoinnista ja erityistarjousten ja tapahtumien hallinnasta.

BookHarber REST API:iden laajuuksien suunnitteleminen#

Toteuttaaksemme tehokkaasti Logton RBAC-järjestelmän BookHarberille, meidän on suunniteltava laajuudet, jotka vastaavat erilaisia REST API:ita. Laajuudet ovat lupia, jotka määrittävät erityisen roolin käyttötason kussakin API-päätepisteessä. Määrittämällä asianmukaiset laajuudet kullekin käyttäjäroolille voimme varmistaa, että käyttäjillä on pääsy vain niihin toimintoihin ja resursseihin, jotka liittyvät heidän rooliinsa.

Suunnitellaanpa laajuudet seuraaville REST API:ille:

1. Kategoriat API:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. Kirjat API:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. Asiakkaat API:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. Tilaukset API:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. Tapahtumat API:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. Tilausseuranta API:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. Liput API:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Roolien laajuuksien määrittäminen#

Nyt kun olemme määrittäneet asianmukaiset laajuudet kullekin REST API:lle, voimme määrittää nämä laajuudet BookHarberin ekosysteemin käyttäjärooleille:

Ymmärtää ero "list" ja "read" laajuuksien välillä#

Havainnollistaaksemme tarkemmin "list" ja "read" laajuuksien eroja REST-API:n suunnittelun ja RBAC:n kontekstissa, harkitaampa oikean maailman esimerkkiä verkkokirjakaupasta, BookHarberista.

Oletetaan, että BookHarberilla on kahdenlaisia käyttäjiä: asiakkaita ja asiakaspalveluagentteja. Asiakkaat voivat luoda tilauksia, kun taas asiakaspalveluagentit vastaavat asiakkaiden auttamisesta tilaustensa kanssa. Katsotaanpa, kuinka "list" ja "read" laajuudet koskevat orders API-resurssia tässä tilanteessa.

1. List Scopes: "list" laajuus mahdollistaa käyttäjälle kokoelman entiteettien pääsyn järjestelmässä. Esimerkiksi list:orders laajuus sallii käyttäjän noutaa listan kaikista käytettävissä olevista tilauksista. BookHarberin kontekstissa tämä laajuus voisi olla hyödyllinen kaupan järjestelmänvalvojille tai muille henkilökunnan jäsenille, jotka tarvitsevat yleiskuvan kaikista tilauksista järjestelmässä. Asiakaspalveluagenttien ei kuitenkaan pitäisi pystyä pääsemään koko tilauslistaan, koska heidän roolinsa on avustaa yksittäisiä asiakkaita heidän erityisissä tilauksissaan.
2. Read Scopes: "read" laajuus antaa käyttäjälle luvan päästä käsiksi yhteen entiteettiin tietyllä ID:llä. Esimerkiksi, read:orders laajuus sallii käyttäjän tarkastella yksityiskohtaista tietoa erityisestä tilauksesta sen ID:n perusteella. BookHarberin tapauksessa tämä laajuus on ihanteellinen asiakaspalveluagentteille, jotka tarvitsevat pääsyn tiettyyn asiakkaan tilaukseen. Kun asiakas avaa tukilipun, asiakaspalveluagentti voi käyttää lipussa annettua tilaus-ID:tä päästäkseen käsiksi kyseisen tilauksen tietoihin.

Omistuksen ymmärtäminen: Miksi asiakkaat eivät tarvitse "read" tai "list" laajuuksia omille tilauksilleen#

Monissa sovelluksissa on yleistä, että käyttäjillä on pääsy omiin resursseihinsa ilman, että heille myönnetään nimenomaisesti vastaavia "read" tai "list" laajuuksia. Tämä johtuu siitä, että käyttäjiä pidetään näiden resurssien omistajina, joilla tulisi luonnollisesti olla pääsy niihin. BookHarberin esimerkissä asiakkaat voivat luoda tilauksia, mutta eivät omaa "read:orders" tai "list:orders" laajuuksia.

Omistuksen käsite on tärkeä määritettäessä pääsynhallintaa tiettyihin resursseihin REST-API:ssa. Tunnustamalla, että käyttäjät voivat aina päästä käsiksi omiin resursseihinsa, voimme toteuttaa tehokkaampaa ja turvallisempaa pääsynhallintaa ilman tarpeettomien lupien myöntämistä. BookHarberin tapauksessa tämä tarkoittaa, että asiakkaat voivat silti tarkastella ja hallita tilauksiaan ilman lisälaajuuksia.

Havainnollistaaksemme kuinka tämä toimii, tarkastellaan GET /orders päätepistettä:

1. Jos käyttäjällä on list:orders laajuus (esim. kaupan ylläpitäjät tai henkilöstö), he voivat tarkastella kaikkia tilauksia järjestelmässä. Tämä antaa heille kattavan näkymän tilaustietoihin, jotka ovat tarpeen heidän rooliaan varten.
2. Jos käyttäjällä ei ole list:orders laajuutta (esim. tavalliset asiakkaat), järjestelmä palauttaa vain käyttäjän omat tilaukset. Tämä varmistaa, että asiakkaat voivat yhä päästä käsiksi tilauksiensa tietoihin ilman niiden tarpeettomien lupien myöntämistä.

Toteuttamalla tämä omistukseen perustuva pääsynhallinta, API voi tarjota asianmukaisen tason pääsyn eri käyttäjärooleille samalla kun ylläpitää turvallisuutta ja räätälöityä käyttäjäkokemusta. BookHarberin skenaariossa omistajuusmalli antaa asiakkaille mahdollisuuden päästä tilauksensa tietoihin ilman "read:orders" tai "list:orders" laajuuksia, yksinkertaistaen pääsynhallinnan suunnittelua ja parantaen kokonaiskäyttäjäkokemusta.

Asetusten konfigurointi Logto Consolessa#

Viimeistelläkseen konfiguroinnin Logton Consolessa, seuraa näitä vaiheita:

1. Yhden sivun sovelluksen (SPA) luominen Reactille: Asenna SPA Logton Consolessa React-sovelluksellesi.
2. API-resurssin luominen: Lisää uusi API-resurssi tunnisteella https://api.bookharber.com.
3. Määrittele resurssin laajuudet: Luo tarvittavat laajuudet vastikään luodulle API-resurssille.
4. Luo roolit ja määritä laajuudet: Määrittele käyttäjäroolit ja jaa asianmukaiset laajuudet kullekin roolille.
5. Määritä roolit käyttäjille: Määritä sovelluksesi käyttäjille asianmukaiset roolit varmistaen, että jokaisella käyttäjällä (Erityisesti henkilökunnalla) on oikeat oikeudet roolinsa perusteella.

API:n suojaaminen laajuuksilla#

Esimerkkiprojektissamme, BookHarber, käytämme taustapalvelimelle Expressiä ja etusivulle Reactia. Tämä osio tarjoaa lyhyen katsauksen Logton RBAC-ominaisuuksien integroimiseen näihin suosittuihin teknologioihin suojataksemme sovellustamme.

Täysi dokumentaatio: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

Logton alustamiseksi React-sovelluksessasi, seuraa dokumentaatiota, joka on tarjolla täällä: https://docs.logto.io/docs/recipes/integrate-logto/react/

Perusasennuksen lisäksi sinun tulee määrittää "resource" ja "scopes" konfiguraatiossa:

Esimerkki API-pyynnön tekemisestä käyttäen Logtoa:

Backend#

Api:n suojaamiseksi seuraa: https://docs.logto.io/docs/recipes/protect-your-api/

Esimerkkikoodiin (https://docs.logto.io/docs/recipes/protect-your-api/node) tulee lisätä laajuusvalidaatio:

Johtopäätös#

Logton RBAC-järjestelmä on voimakas työkalu pääsynhallinnan ja turvallisuuden hallintaan nykyaikaisissa sovelluksissa. Hyödyntämällä Logton RBAC-ominaisuuksia voit varmistaa, että käyttäjillä on asianmukainen pääsy resursseihin rooliensa perusteella, suojaten herkät tiedot ja toiminnot luvattomalta pääsyltä.

Tässä artikkelissa tutkimme oikean maailman esimerkkiä verkkokirjakaupasta, BookHarberista, ja näytimme kuinka suunnitella laajuuksia, määrittää ne käyttäjärooleille ja toteuttaa Logton RBAC-ominaisuuksia sekä sovelluksen etu- että taustapuolella.

Soveltamalla näitä käsitteitä ja tekniikoita projekteihisi voit parantaa sovellustesi turvallisuutta ja pääsynhallintaa, tarjoten saumattoman ja turvallisen käyttäjäkokemuksen. Riippumatta siitä, työskenteletkö verkkokaupan, sisällönhallintajärjestelmän tai minkä tahansa muun projektin parissa, joka vaatii roolipohjaista pääsynhallintaa, Logton RBAC-järjestelmä tarjoaa joustavan ja tehokkaan ratkaisun pääsynhallinnan tarpeisiisi.