Utilizzare (o non utilizzare) OAuth per il servizio interno per la comunicazione di servizi in SOA

3

Quindi siamo un gruppo di studenti che realizzano una piattaforma online per la nostra università. Stiamo modellando la nostra piattaforma come un insieme di servizi.

Ad esempio, un servizio "A" potrebbe memorizzare solo le informazioni personali degli utenti ed esporre un'API REST su di esso. Un altro servizio "B" potrebbe inviare solo email.

Una struttura approssimativa sarebbe simile a questa:

OravogliamoutilizzareOAuthperl'autenticazioneel'autorizzazione(socheOAuthèunframeworkdiautorizzazionemavogliamofare approssimativamente cosa google fa ).

Uno scenario tipico potrebbe essere qualcosa di simile:

  1. L'utente richiede la pagina web del servizio "A".
  2. Servizio "A" vede che l'utente non è autenticato, quindi invierà un reindirizzamento al server di autenticazione.
  3. L'utente inserisce le proprie credenziali e un token di accesso è concesso al servizio "A".

Ora, il servizio "A" potrebbe aver bisogno di chiamare un altro servizio "B". Tieni presente che questa è una richiesta interna al server . Vari altri servizi potrebbero chiamare il servizio "B".

Voglio assicurarmi che quando viene chiamato il servizio "B", solo i servizi consentiti possono chiamarlo. Ad esempio, "A" ha il diritto di chiamare "B", ma "C" no. In altre parole, desidero garantire che solo i chiamanti autorizzati per un determinato servizio possano chiamarlo .

Quindi la mia domanda è, è possibile proteggere le chiamate interne da servizio a servizio usando OAuth?

Può essere fatto in un modo più semplice e sicuro?

Non voglio delegare token: cioè, non voglio che il primo token emesso per servire A venga usato da qualche altra parte. Si presume che se "A" sta chiamando "B", quindi "A" ha il diritto di farlo, anche se non vi è alcun utente loggato.

Il mio tentativo : (potrebbe essere sbagliato, correggimi) * Il server Auth può rilasciare clientIds e segreti client per ciascun servizio. * Un servizio che desidera chiamare un altro servizio si identifica con il server di autenticazione utilizzando la chiave e il segreto. * Se il servizio è autorizzato a chiamare il servizio di destinazione, il server di autenticazione emette un token, altrimenti restituisce proibito.

Ma anche in questo caso, il server Auth sta facendo troppo.

Non è possibile che ogni servizio controlli ciò che altri servizi possono chiamarlo?

Grazie.

    
posta Akshay Arora 05.10.2016 - 08:54
fonte

1 risposta

3

Questo è iniziato come un commento, ma è diventato un po 'più ampio, quindi l'ho spostato su una "risposta".

Il passo mancante dalle specifiche OAuth2.0 è la 'comunicazione di back-end': la parte in cui il server di autorizzazione e i vari servizi concordano su cosa è un token valido e quale ambito è associato ad esso. Questi 'dettagli di implementazione' sono lasciati alla discrezione del fornitore di servizi OAuth.

Inoltre, il tuo diagramma potrebbe essere migliorato avvicinandosi alla terminologia OAuth2.0 (non sto dicendo che hai fatto un brutto lavoro, il diagramma è utile, ma potrebbe essere più chiaro).

Il tuo 'utente' in questo caso è (presumibilmente) il proprietario risorse . Il 'Frontend' potrebbe (sto indovinando qui) essere un'applicazione a pagina singola, in esecuzione all'interno di User Agent .

È Agente utente che riceve il token di accesso dal server di autorizzazione , per accedere ai dati per conto di Proprietario delle risorse .

In altre parole, nel diagramma manca la comunicazione tra "Utente" e "Server di autenticazione".

Per il flusso di OAuth, forse il diagramma seguente è utile:

Figura1:flussoOAuthperclient(riservati)

Perrispondereallatuadomanda:OAuthriguardaladelegadiautorizzazionedaunproprietariodirisorseaqualcheservizioperaccedereaidatidelproprietariodelrisorsaaloronome.

Quindi,usareOAuthpotrebbenonesserelasoluzionemigliore.Tuttavia,nonconoscosoluzioniout-of-the-boxcherisolvanoveramenteiltuoproblema(delegadeidirittidiaccesso,percontodiunutente).Puoidareun'occhiataa basato sul controllo di accesso basato su autorizzazione (ZBAC) ma potrebbe essere piuttosto eccessivo per quello che stai cercando di raggiungere.

    
risposta data 05.10.2016 - 11:07
fonte

Leggi altre domande sui tag