Accesso basato sul ruolo alle risorse per un servizio RESTful

Naviga le tue risposte
5

Sto ancora avvolgendo la mia attenzione su REST, ma mi chiedo se qualcuno possa aiutare con suggerimenti o approcci al controllo dell'accesso basato sui ruoli per un servizio RESTful, in particolare dal punto di vista della protezione dei dati e di come potrebbero essere gli URL Guarda. Probabilmente è meglio prendere in considerazione un esempio:

Supponiamo di avere un servizio REST per i clienti e di dividere gli utenti di questo servizio REST in ruoli di amministratore, editor e lettore:

  • Gli amministratori possono modificare tutti gli attributi di una risorsa cliente
  • Gli editori possono cambiare solo alcuni
  • I lettori possono solo visualizzarli.

I diritti di controllo degli accessi sono assegnati individualmente alle entità Clienti. Quindi, ad esempio, un utente del servizio potrebbe avere diritti di amministratore per i clienti 1,2 e 3, ma l'accesso Editor a 4,5 e l'accesso Reader a 7,8,9.

Ora considera l'utente che chiama il servizio. Qual è un buon modo per separare l'elenco dei clienti per l'utente corrente?

GET / cliente - questo potrebbe ottenere un elenco di tutti i clienti a cui l'utente corrente ha accesso Admin \ Editor \ Reader. Ma poi su ciascun Cliente il consumatore avrebbe bisogno di un'indicazione sul ruolo che hanno.

O sarebbe "meglio" avere qualcosa di simile

GET / Cliente / Amministratore : restituisce tutti i clienti a cui l'utente corrente ha accesso come amministratore.

Cerca solo alcuni puntatori di alto livello o leggi in modo decente per proteggere \ filtro le risorse in base ai ruoli dell'utente corrente.

    
posta mutex 23.10.2013 - 06:19
fonte

1 risposta

5

Un metodo che ho utilizzato con grande successo per esporre il livello di accesso oi ruoli che l'utente autenticato ha rispetto a una particolare risorsa è di esporlo come verbi HTTP sull'entità stessa.

Ad esempio, richiedendo un elenco di tutti i clienti: 

GET /customers
{
   customers: [
     {
        id: "/customers/1"
        allowed: ["GET", "UPDATE", "PUT", "DELETE"]
     },
     {
        id: "/customers/2"
        allowed: ["GET"]
     }
   ]
}

GET ha indicato l'accesso in lettura UPDATE, PUT, DELETE indicava l'accesso a Editor e / o agli amministratori in base alla semantica dell'API. Se questo tipo di astrazione non funziona nel tuo caso, puoi chiamare direttamente i risultati.

Inoltre, puoi fornire un filtro alla richiesta dei clienti 

GET /customers?role=admin

Restituisce solo i clienti per i quali l'utente autenticato ha il ruolo "admin".

    
risposta data 23.10.2013 - 07:53
fonte

Leggi altre domande sui tag

Shoud I restituisce direttamente un messaggio di stringa o piuttosto una chiave i18n quando si tratta di API JSON? Come allocare preoccupazioni trasversali nella pianificazione dello sviluppo software agile?