autenticazione / autorizzazione multi-tenancy e microservices API

0

Sto cercando consigli su come possiamo implementare l'autenticazione e l'autorizzazione per la multitenancy con un numero leggermente diverso di scenari.

Stiamo costruendo una serie di API che, tra l'altro, sono internamente accessibili (all'interno dell'organizzazione) mentre altre saranno accessibili esternamente (Internet).

Quelli internamente e direttamente accessibili all'interno dell'organizzazione possono essere "indirettamente" accessibili tramite servizi più astratti esposti esternamente.

a causa della natura complessa della nostra attività (società di telecomunicazioni), i consumatori delle API dell'esterno saranno disponibili in diverse forme. Alcune saranno le nostre sussidiarie, mentre altre saranno terze parti, venditori e sviluppatori.

Prenderò in considerazione che, indipendentemente dal fatto che siano grandi consumatori di organizzazioni o singoli sviluppatori, sono tutti identificabili in modo univoco allo stesso modo.

La parte difficile ora è che in determinati scenari le risorse esposte pubblicamente potrebbero non essere accessibili a determinati consumatori. Esempio:

  • La sussidiaria X può accedere a tutte le risorse e alle operazioni CRUD sulla risorsa Y
  • Tuttavia, la terza parte Z può solo recuperare Probabilmente mi sto avventurando nel territorio dell'ACL ora ...

Inoltre, per aggiungere complessità alla questione, ci sono alcuni scenari di "separazione strutturale" (imposti dal governo) che giustificano la segregazione dei dati, ma non andrò più in basso in quella tana del coniglio.

C'è anche il problema di più titolari che accedono a un sistema che non soddisfa la multitenancy. :)

Quindi c'è molto, quindi mi chiedo quali sono le opinioni, i consigli e l'approccio delle persone in merito.

Speriamo che Oauth 2.0 in combinazione con OpenID con una soluzione ACL personalizzata possa funzionare.

EDIT:

Scuse hanno avuto problemi con il mio cellulare durante la pubblicazione di domande e metà di esso è stato tagliato.

Solo alcuni consigli generali sull'approccio.

È qualcosa che OpenID e Oauth2 con entitlement server potrebbero soddisfare?

    
posta Sash 12.11.2015 - 21:30
fonte

2 risposte

1

link

Il blog precedente suggerisce di mantenere le autorizzazioni a livello di oggetto all'interno di ciascun microservizio. In questo modo puoi autenticare e inoltrare user_id (o group_id) tramite qualcosa come OAuth 2.0 e token, ma eseguire il lavoro effettivo di autorizzazione / filtraggio della risposta all'interno del microservice.

Questo approccio mantiene lo spirito "debolmente accoppiato" dei microservizi.

    
risposta data 18.02.2016 - 19:03
fonte
0

Ogni utente API è un client OAuth 2.0 ed è registrato sul server di autorizzazione per determinati ambiti . Gli ambiti OAuth 2.0 possono essere visti come autorizzazioni, quindi è possibile applicare già un certo numero di regole di controllo dell'accesso basate sugli ambiti. Quando un client avvia un flusso di autorizzazione, chiede all'utente il suo consenso per un numero di ambiti e il token di accesso generato alla fine "trasporta" questi ambiti.

La tua risorsa X potrebbe richiedere ai client di avere un token con scope READ_X, mentre la risorsa Y richiede ai client di avere token con scope WRITE_Y.

Se hai bisogno di autorizzazioni più precise, puoi anche assegnare ruoli / permessi ai tuoi utenti. Tuttavia, al di fuori delle specifiche di OAuth 2.0, dipenderà dagli strumenti che utilizzi.

La multi-tenancy può essere implementata in vari modi a seconda del caso.

    
risposta data 27.11.2015 - 10:24
fonte

Leggi altre domande sui tag