Nel post precedente di questa serie abbiamo visto come sfruttare un API Gateway ed un Identity Provider per gestire l’autenticazione. Giusto per rinfrescare i concetti, ecco il diagramma di base:

</figure>

In pratica il client comunica direttamente con l’API Gateway, il quale a sua volta chiederá all’Identity Provider di fornire i dettagli dell’utente corrente. Per poter completare la richiesta abbiamo bisogno ovviamente che l’utente sia autenticato nel sistema. Il client verrá quindi rimandato ad un’area esterna dove potrá inserire le sue credenziali. Se valide, il Provider genererá un token che verrá usato per ogni chiamata all’API Gateway.

Bene, adesso che abbiamo il nostro utente, ci serve un modo per controllare i suoi permessi su ogni microservizio.

Un opzione potrebbe essere usare l’autorizzazione basata sui Claims: praticamente significa salvare tutti i permessi dell’utente per ogni microservizio come claims a bordo del token.

Quando un microserizio riceve una richiesta dovrá decodificare il token, verificarlo e successivamente controllare che siano presenti i giusti claim per l’azione richiesta.

É un meccanismo abbastanza semplice da implementare e funziona anche benino ma significa pure che dobbiamo mandare un bel po’ di dati avanti e indietro in ogni chiamata alle nostre API. Il token sará praticamente pieno zeppo di informazioni che molto probabilmente non ci serviranno, se non solo per alcune delle chiamate.

I claims dei permessi sono un’informazione utile solo per il microservizio che copre quello specifico Bounded Context. Tutti gli altri riceveranno i dati ma non ne faranno alcun uso.

Un’altra opzione quindi é quella di aggiungere un microservizio specifico per l’Autorizzazione, qualcosa del genere:

<figcaption>Authorization Service</figcaption></figure>

Questo nuovo microservizio sará responsabile di tutti i permessi per ogni utente del sistema.

Come in precedenza, quando un microserizio riceve una richiesta dovrá decodificare il token e verificarlo. Poi, se l’azione richiede un’autorizzazione specifica, verrá effettuata una chiamata al nuovo Authorization Service chiedendo appunto se l’utente puó o non puó portare a termine la richiesta.

In questo modo abbiamo separato i compiti, spostando i controlli in uno specifico microservizio che si occuperá quindi di una sola ed unica cosa: gestire i permessi utente (e probabilmente anche altre cosette come ruoli/profili e cosí via).

Did you like this post? Then