Come gestire le autorizzazioni ACL a grana fine basate su campo in un servizio RESTful?

Question

Come gestire le autorizzazioni ACL a grana fine basate su campo in un servizio RESTful?

#1 da (4 voti)
#2 da (1 voti)

7

Ho cercato di progettare un'API RESTful e ho avuto risposta alla maggior parte delle mie domande, ma c'è un aspetto delle autorizzazioni con cui sto lottando.

Diversi ruoli possono avere permessi diversi e diverse rappresentazioni di una risorsa. Ad esempio, un amministratore o l'utente stesso possono visualizzare più campi nella propria rappresentazione utente rispetto a un altro utente con privilegi inferiori. Ciò si ottiene semplicemente modificando la rappresentazione sul back-end, ovvero: decidendo se includere o meno tali campi.

Inoltre, alcune azioni possono essere intraprese su una risorsa da alcuni utenti e non da altri. Ciò si ottiene decidendo se includere o meno tali elementi di azione come collegamenti, ad esempio: modifica ed eliminazione dei collegamenti. Un utente che non dispone delle autorizzazioni di modifica non avrà un collegamento di modifica.

Questo copre quasi tutti i miei casi di utilizzo dei permessi, ma ce n'è uno che non ho ancora capito. Esistono alcuni scenari in cui per una determinata rappresentazione di un oggetto, tutti i campi sono visibili per due o più ruoli, ma solo un sottoinsieme di quei ruoli sono stati modificati per determinati campi.

Un esempio:

{
    "person": {
        "id": 1,
        "name": "Bob",
        "age": 25,
        "occupation": "software developer",
        "phone": "555-555-5555",
        "description": "Could use some sunlight.."
    }
}

Dato 3 utenti: un amministratore, un utente normale e Bob stesso (anche un utente normale), ho bisogno di essere in grado di trasmettere al front-end che:

Gli amministratori possono modificare tutti i campi, Bob stesso può modificare tutti i campi, ma un utente normale, mentre possono visualizzare tutti i campi, può solo modificare il campo della descrizione. Certamente non voglio che il cliente debba fare la determinazione (o anche, se è per questo, avere qualche nozione dei ruoli coinvolti) ma ho bisogno di un modo per il back-end per trasmettere al cliente quali campi sono modificabili.

Non posso semplicemente usare una combinazione di rappresentazione (i campi restituiti per la visualizzazione) e i collegamenti (indipendentemente dal fatto che sia disponibile o meno un collegamento di modifica) in questo scenario poiché è più finemente granuloso.

Qualcuno ha risolto questo problema elegantemente senza aggiungere la logica direttamente al client?

api-design rest

posta Jason McClellan 30.10.2013 - 08:48

fonte

2 risposte

1

Un'altra opzione è di avere un'altra risorsa (cioè / permessi / userResource / utente / 1) che restituirà i campi che l'utente può modificare o visualizzare.

{

read: [id,name,age,occupation,etc],

write: [description]

}

Penso che sia simile al suggerimento precedente .

risposta data 02.05.2014 - 03:12

fonte

Leggi altre domande sui tag api-design rest

Qual è la giustificazione dell'uso di file .inc per dichiarare e implementare il codice sono alcune unità Delphi RTL? Dividere le storie degli utenti in storie più piccole

score 4 · Accepted Answer

Che ne dici di aggiungere autorizzazioni specifiche come "link" nella rappresentazione delle risorse. Fondamentalmente, lasciando che il client sappia quali attributi sono disponibili per l'aggiornamento (da parte degli utenti regolari). Sia Admin che Self sono utenti non regolari a cui è consentito modificare tutto. Sulla base del tuo esempio che gli utenti regolari possono modificare solo il campo "descrizione", ecco i miei pensieri:

{
    "person": {
        "id": 1,
        "name": "Bob",
        "age": 25,
        "occupation": "software developer",
        "phone": "555-555-5555",
        "description": "Could use some sunlight.."
        "_links": {
           "href": "/person/1",
           "method": "PUT",
           "attributes": ["description"]
        }
    }
}