REST - Quale verbo utilizzare per verificare l'autorizzazione

Sto progettando un servizio di autorizzazione che verrà interrogato internamente da altri servizi pubblici che stanno recuperando un'intestazione Authorization all'interno di una richiesta.REST - Quale verbo utilizzare per verificare l'autorizzazione

Questo servizio gestisce l'autorizzazione (una coppia di chiave pubblica (user_id) e chiave privata) e il suo compito è di rigenerare la firma (HMAC) - è l'unico servizio a conoscere la chiave privata -, quindi sembrava giusto per identificarlo come risorsa del server. Poi ho ritenuto che non v'è alcuna risorsa autorizzazione a utente, quindi ho finito con questo URI di base:

/user/:user_id/authorization

Ho poi progettato operazioni CRUD per gestire l'autorizzazione, creare quando si crea un nuovo utente, l'aggiornamento quando richiesto, leggere ed eliminare quando l'utente viene cancellato.

Nota: l'entità Utente è gestita da un altro servizio, sto solo utilizzando questo URI per passare in modo logico la chiave pubblica (poiché è strettamente correlata a un utente).

Non sono sicuro di come dovrei interrogare questo servizio da altri servizi per dire: "Ehi, questa chiave è giusta?" passando accanto a questa richiesta tutti i dati necessari per rigenerare la firma.

Quindi quello che serve è un modo per verificare l'autorizzazione in modo riposante

ho insegnato qualcosa come:

GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY

Ma forse, potremmo anche vedere per essere la creazione di una nuova risorsa di autorizzazione (anche se non viene restituito nulla, non è un sistema di token) rendendo così PUT o POST più adatto per questo scopo.

Qual è il tuo punto di vista? Qual è l'approccio giusto per gestire questo tipo di situazione?

fonte

2012-11-02 Anonymous

Perché stai reinventando la ruota? Qualunque schema attuale non soddisfa le tue esigenze? Di base, Digest MD5, CERT, SPNEGO? –

Non penso che tu abbia capito cosa stavo chiedendo. Sto già utilizzando SHA1 per generare l'HMAC che sto chiedendo su cosa sia un modo riposante per inviare questa firma al servizio di autorizzazione (e ottenere una risposta booleana). I dati vengono inviati per consentire al servizio di calcolare l'HMAC. –

Sto progettando questo sistema dopo il meccanismo S3 perché nessuno degli standard è applicabile alle mie esigenze. –

Questo servizio gestisce l'autorizzazione (una coppia di chiave pubblica (user_id) e la chiave privata)

Stai Memorizzazione lato server chiave privata? E stai gestendo l'autorizzazione e l'autenticazione sullo stesso servizio?

Personalmente preferirei un'architettura come WebID. Vedere:

fonte

2012-11-03 06:44:04

Sì, lo so. La chiave privata è memorizzata in un database redis accessibile solo da questo servizio. Quindi si aspettano richieste da altri servizi, che sono questo consumatore di servizi, che passano una firma HMAC e i dati necessari per rigenerare la firma HMAC ... È l'unico servizio a conoscere la chiave privata, tranne l'utente. Leggerò i tuoi link, grazie, ma mi piacerebbe mantenere l'autorizzazione semplice, come la soluzione S3. Voglio che un servizio lo gestisca per evitare la duplicazione tra tutti i servizi che necessitano di una sorta di autenticazione. –

Sono perplesso dal fatto che la tua architettura richiede che la chiave privata sia conosciuta sia dal servizio che dall'utente. Questo accende una lampadina di avviso per un sistema di chiavi asimmetriche. Penso che questa scelta progettuale debba essere riesaminata prima di rispondere alla tua domanda poiché questo è accoppiato con la tua necessità di rigenerare la firma. –

Come consentirebbe al client di generare la firma se non gli viene fornita la chiave privata? Naturalmente l'autorizzazione è centralizzata e solo questo sistema conoscerà la chiave. Tutti gli altri servizi no. –

GET/user /:? User_id/autorizzazione di firma = QUALCOSA & data = JSON-DATA-TO-REGENERATE-KEY

Non dimenticare mai che un metodo GET dovrebbe essere 'safe'. Non dovrebbe "avere il significato di intraprendere un'azione diversa dal recupero". In altre parole, il client "non dovrebbe richiedere effetti collaterali".

fonte

2012-11-03 06:51:17

Devo considerare questa richiesta come effetti collaterali di reqeuesting? Ho bisogno di controllare se l'intestazione di autorizzazione è giusta ... se è così il servizio deve rispondere con un 200 OK, dicendo che è ok. Come lo faresti? –

Personalmente penso che ottenere l'autorizzazione iniziale (il login) per una sessione/utente/qualunque debba essere un POST in quanto (presumibilmente) crea qualcosa di nuovo: qualche token di autorizzazione.

Le richieste di convalida dell'autorizzazione successive devono essere GET. Non creano nulla di nuovo e sostanzialmente restituiscono un valore booleano (anche se attraverso i codici di risposta) per indicare se le intestazioni di autorizzazione sono valide o meno.

fonte

2012-11-03 10:37:53

Non creo una sessione, ogni volta che viene ricevuta una richiesta, controllo se l'HMAC è valido. Faresti una richiesta direttamente al servizio di tuo interesse, creando una firma HMAC, quindi sarà il servizio che stai trattando per creare una chiamata interna a un altro servizio per calcolare la firma HMAC, in attesa di una risposta prima di procedere . Cosa pensi che dovrei usare allora? –

Non sono esperto di sicurezza/autorizzazione. Ho solo risposto alla domanda su quale verbo usare. Per quanto ho capito, il flusso normale sarebbe che, dopo aver ottenuto l'autorizzazione, si ottiene un token di sicurezza che si aggiunge alla seguente richiesta. Questo token avrà validità limitata, per ora e/o numero di richieste. –

REST - Quale verbo utilizzare per verificare l'autorizzazione

risposta

Problemi correlati