Autorizzazione tramite il controllo degli accessi

L'autorizzazione è il processo che consiste nel concedere agli utenti l'accesso alle diverse parti e risorse dell'applicazione web. Un modo comune per autorizzare gli utenti è il controllo degli accessi, in cui l'amministratore del sito definisce quali permessi devono essere concessi agli utenti e alle altre entità per accedere a quali risorse.

L'autorizzazione non deve essere confusa con l'autenticazione, che è il processo di verifica che l'utente sia effettivamente chi afferma di essere, solitamente realizzato fornendo le credenziali dell'account. Una volta che l'utente è autenticato, il processo di autorizzazione deve comunque essere eseguito a ogni richiesta, per assicurarsi che l'utente abbia accesso alla risorsa richiesta.

Quando si accede all'applicazione tramite GraphQL, dobbiamo verificare se l'utente ha accesso agli elementi richiesti dello schema. La logica di autorizzazione deve essere codificata all'interno del livello GraphQL?

La risposta è no. Come chiarisce la documentazione su graphql.org, la logica di autorizzazione appartiene al livello della logica di business, ed è da lì che viene acceduta da GraphQL. In questo modo, l'applicazione può disporre di un'unica fonte di verità per l'autorizzazione (ovvero quella offerta da WordPress):

Gato GraphQL rispetta questo principio, riflettendo (e, sotto il motore, delegando a) il meccanismo di autorizzazione fornito da WordPress.

​

Politiche di controllo degli accessi

Tra le diverse politiche di controllo degli accessi che possiamo implementare per la nostra applicazione, le due più diffuse sono il controllo degli accessi basato sui ruoli (RBAC) e il controllo degli accessi basato sugli attributi (ABAC).

WordPress, e Gato GraphQL, supportano entrambi.

Con il controllo degli accessi basato sui ruoli concediamo i permessi in base ai ruoli, e poi assegniamo i ruoli agli utenti. Ad esempio, WordPress dispone di un ruolo administrator con accesso a tutte le risorse, e dei ruoli editor, author, contributor e subscriber con permessi limitati in vari gradi, come la possibilità di creare e pubblicare un articolo del blog, semplicemente crearlo, o semplicemente leggerlo.

Con il controllo degli accessi basato sugli attributi i permessi vengono concessi in base a metadati che possono essere assegnati a diverse entità, inclusi gli utenti, le risorse e le condizioni dell'ambiente (come l'ora del giorno o l'indirizzo IP del visitatore). Ad esempio in WordPress, la capacità edit_others_posts viene utilizzata per verificare se l'utente può modificare gli articoli di altri utenti.

In termini generali, l'ABAC è preferibile all'RBAC perché ci consente di configurare i permessi con un controllo dettagliato, e il permesso è inequivocabile nel suo obiettivo.

Ad esempio in WordPress, il ruolo editor possiede la capacità edit_others_posts, ma potremmo voler consentire a una persona con il ruolo author di modificare l'articolo di un altro autore, senza però concederle l'intero insieme di permessi che vengono concessi a un editor (come anche eliminare gli articoli di altri autori). Pertanto, concedere la capacità edit_others_posts e verificare questa condizione è più adeguato che verificare il ruolo editor.

​

Definire la visibilità

Quando l'utente non possiede il permesso di accedere al campo richiesto dello schema GraphQL, quale dovrebbe essere l'errore restituito?

Ci sono due possibilità, in conformità con la visibilità desiderata per lo schema: pubblica o privata.

Per lo schema pubblico, lo schema GraphQL esposto è lo stesso per tutti gli utenti, e ogni campo descrive quali permessi sono richiesti per accedervi. Quando si richiede un campo non accessibile, il messaggio di errore spiegherà perché all'utente non viene concesso l'accesso.

Per lo schema privato, lo schema GraphQL è personalizzato per ogni utente, e verranno esposti solo i campi a cui può accedere. Quando si richiede un campo non accessibile, il messaggio di errore indicherà che il campo non esiste.

​

Controllo degli accessi tramite l'interfaccia utente

In Gato GraphQL, le regole di controllo degli accessi vengono iniettate nello schema in fase di esecuzione, sotto forma di configurazione definita dall'utente tramite access control lists. In questo modo, il livello GraphQL rifletterà immediatamente le modifiche alla politica di controllo degli accessi, senza bisogno di aggiornare il codice o ricompilare lo schema:

L'amministratore del sito configura l'ACL, selezionando:

• I campi da validare
• Una regola da validare, tra:
  • l'utente deve essere connesso?
  • l'utente deve essere disconnesso?
  • l'utente deve avere un certo ruolo?
  • l'utente deve avere una certa capacità?
• La configurazione specifica della regola:
  • quali ruoli?
  • quali capacità?
• La visibilità:
  • predefinita (ovvero la stessa assegnata allo schema)?
  • pubblica?
  • privata?