Utente autenticato in movimento per un servizio diverso

0

Questa è una di quelle situazioni "Non so nemmeno cosa non so". Scusate se suono confuso o commetto errori da principiante. Qualsiasi aiuto, incluso il materiale di lettura, sarebbe apprezzato.

Sto cercando di costruire per lavoro un servizio che si basa su dati riservati di un altro servizio.

Supponiamo che un utente abbia effettuato l'accesso in service1 . L'utente fa clic su un link su service2 .

service2 deve essere consapevole dei dati sensibili memorizzati in service1 server. Inoltre, service2 consente agli utenti di consumare crediti pagati con denaro e che potrebbero essere utili per gli autori di attacchi, quindi deve essere certo dell'identità dell'utente, come previsto da service1 .

È necessario che service1 e service2 vadano su server diversi e utilizzino domini diversi. È anche richiesto che l'utente passi da service1 a service2 facendo clic su un collegamento. Afaik, questo significa che l'unico dato che service2 può ottenere è sull'URL stesso.

La mia soluzione proposta:

1) L'utente fa clic per passare da service1 a service2

2) service1 genera una chiave univoca, utilizzabile e si aggiunge all'URL. Javascript apre questo URL.

3) service2 riceve questa chiave e la invia a service1 . Service1 invia i dati direttamente a service2

Per quanto posso dire, i dati sono (per definizione) sicuri. Ma c'è ancora il problema che un utente malintenzionato potrebbe ottenere la chiave unica e usarlo invece.

Ma c'è molto che non capisco e non so nemmeno cosa cercare.

Qualsiasi aiuto / commento / materiale di lettura apprezzato.

    
posta josinalvo 29.06.2017 - 20:51
fonte

1 risposta

1

Questo è molto simile a un servizio Single Sign-On, tranne che di solito non controlli tu stesso tutti i servizi (invece, uno di questi è controllato dal provider SSO, come Facebook o Google). Puoi guardare OAuth2 per alcune idee su come SSO è più comunemente implementato, ma è onestamente eccessivo per uno scenario in cui controlli entrambi i servizi.

Supponendo che tu controlli entrambi i servizi e che le chiamate tra di loro siano sufficientemente economiche, una soluzione semplice è quella di avere una di queste fonti di verità sull'identità, quindi service2 controlla semplicemente il servizio1 per la conferma di chi è l'utente e cosa possono fare (quali sono i loro dati segreti, quanti crediti hanno, ecc.), senza memorizzare alcuna di tali informazioni. Il problema è quindi collegare la sessione dell'utente attraverso entrambi i servizi.

Puoi utilizzare l'approccio URL:

  1. service1 genera un token casuale sicuro monouso e lo passa a service2 nell'URL
  2. service2 invia quel token a service1 attraverso un canale diretto
  3. service1 risponde con un identificativo di sessione per la sessione dell'utente e anche qualsiasi altro servizio dati2 vorrà sicuramente
  4. service2 imposta l'identificativo di sessione da service1 come identificativo di sessione sul client (probabilmente in un cookie sicuro) e facoltativamente memorizza i dati richiesti nel proprio stato di sessione per quella sessione

In alternativa, è possibile utilizzare CORS (Cross-Origin Resource Sharing), che è un modo per un browser Web di violare la politica della stessa origine in modo controllato tra siti che si fidano l'uno dell'altro (e sono eventualmente controllati dallo stesso entità). CORS ti consente di creare XMLHttpRequest o di recuperare le chiamate tra le origini e vedere le risposte. Un esempio potrebbe essere simile a questo:

  1. service2 riceve una richiesta da un nuovo utente che non ha una sessione o un utente la cui sessione è scaduta
  2. service2 risponde con una pagina contenente uno script che effettua una richiesta CORS, con autenticazione, a service1
  3. Supponendo che l'utente sia connesso al servizio1, service1 accetta la richiesta CORS e risponde con un token casualmente sicuro monouso
  4. Lo script sul lato client invia questo token a service2
  5. service2 invia questo token a service1 tramite un canale back diretto
  6. service1 verifica il token e invia un identificatore di sessione a service2, ecc.

Questo schema equivale a passare il token nell'URL, con due eccezioni:

  • Il token non viene mai inviato nell'URL e pertanto è molto meno probabile che finisca da qualche parte, non dovrebbe come un log del server o una cronologia del browser.
  • L'utente può accedere direttamente a un URL di servizio2 senza fare clic su un collegamento speciale da service1, a condizione che abbia una sessione attiva su service1.

Si noti che il token di sessione stesso non viene mai inviato in un corpo di risposta (quello che vede il client). Potresti semplificare questo schema se lo facessi, quindi lo script client imposterà l'ID di sessione in un cookie per service2, eliminando un round-service2 round-round e un servizio round2-service1 - ma poi un utente malintenzionato con un XSS potrebbe rubare il token di sessione ( al contrario di "semplicemente" che ha il controllo remoto completo sulla sessione compromessa finché l'utente ha caricato la pagina).

    
risposta data 28.05.2018 - 22:58
fonte

Leggi altre domande sui tag