Come incorporare il man-in-the-middle

0

Sto progettando un back-end basato sul web per un servizio online. Il servizio potrebbe supportare portali web e app mobili come front-end.

Ma sono bloccato su come supportare front-end di terze parti, cioè siti Web non attendibili. In effetti lo stesso problema esiste con le app mobili, anche se forse in misura minore.

In breve il problema è che l'autenticazione e l'autorizzazione dovrebbero avvenire nel back-end, e la domanda è come garantire che un portale di livello intermedio o un portale web non salvi le credenziali segrete di un utente o attraverso altri mezzi possa rappresentare un utente finale ed eseguire operazioni che l'utente non sta richiedendo!

Devo essere in grado di autenticare l'utente finale nel back-end e attualmente ho un proof-of-concept funzionante, e i processi di registrazione e autenticazione per questo sono i seguenti:

  1. Nuovo utente si connette alla pagina di registrazione pubblica.
  2. Forse include JS per generare una coppia di chiavi pubblica / privata?
  3. Autorizza l'accesso al provider Oauth per informazioni di base sul profilo.
  4. Recupera i dettagli dell'utente e popola il profilo.
  5. L'utente fornisce informazioni aggiuntive (ad es. numero di contatto, indirizzo email di recupero) e la sua chiave pubblica per completare la procedura di registrazione.

E quindi il processo di autenticazione per un utente di ritorno sarebbe qualcosa come:

  1. L'applicazione utente (Android o Javascript) crea una richiesta formattata JSON.
  2. L'applicazione firma la richiesta con la chiave privata dell'utente.
  3. L'applicazione allega l'identificazione dell'utente (id-utente / id-aperto / ecc.) alla richiesta.
  4. L'applicazione invia la richiesta all'API (back-end).
  5. API verifica che la richiesta sia autenticata per l'utente specificato (verifica firma)
  6. API verifica che le richieste siano autorizzate.
  7. I processi API richiedono e costruiscono la risposta.
  8. API crittografa la risposta utilizzando la chiave pubblica dell'utente.
  9. l'API allega alcune informazioni di base (es. versione API e identificativo della richiesta) alla risposta.
  10. API restituisce la risposta nella sessione HTTPS dell'utente.

Per quanto posso dire, il problema arriva al punto 4. L'applicazione può inviare la richiesta ovunque, ad esempio un sito Web di terzi che aggiunge vantaggi come la formattazione e le funzioni avanzate. Ciò significa che il livello intermedio invia più query al back-end per conto dell'utente finale, crea la risposta e restituisce la pagina o il report all'utente.

Tra l'altro spero di sfruttare due vantaggi specifici dell'uso di openid / oauth (che non ho ancora avuto modo di lavorare nella mia implementazione proof-of-concept)

a. Rendi facile il processo di registrazione: l'utente non ha bisogno di ricordarlo     una nuova password e non ha bisogno di compilare tutti i loro dettagli, solo     i bit necessari per l'applicazione che non sono forniti da Google+ e     amici.

b. Non ho bisogno di gestire password dimenticate / reset della password in     99% dei casi. Finché l'utente ha accesso al proprio open-id     account possono riacquistare l'accesso al servizio. Quando ci si connette da     un nuovo dispositivo, ad esempio un secondo PC / tablet / altro, l'applicazione     crea una nuova coppia di chiavi pubblica / privata e la parte del provider openid     dà accesso al profilo dell'utente. Se l'utente passa a un nuovo     provider openid può utilizzare l'indirizzo email di recupero per collegare un nuovo     URI openid al suo profilo sul sistema.

D'altra parte non sto cercando di integrarmi con altre funzionalità più avanzate dei provider openid in questa fase. Voglio davvero che una terza parte gestisca il lavoro svolto per identificare gli utenti e gestire le loro password.

Il problema è che l'utente si registra con il back-end attraverso un'interfaccia che potrebbe non essere attendibile. Un livello medio non valido può potenzialmente sostituire la chiave pubblica di un utente per una chiave pubblica per la quale controllano la chiave privata. Come posso progettare questo tipo di situazione? Disabilito completamente le interfacce di terzi verso il back-end (preferirei non essere coinvolto con le app e i siti web, anche se implementerò un'applicazione di riferimento)

    
posta Johan 19.01.2015 - 10:28
fonte

1 risposta

2

Questo è ciò che oAuth è per. oAuth consente a una richiesta di assistenza di terze parti di eseguire determinate operazioni per conto di un utente con il consenso dell'utente, ad esempio l'accesso in lettura ai contatti degli utenti. La terza parte riceve un token che consente di eseguire queste azioni ed è responsabilità del back-end convalidare il token e le azioni che è autorizzato a svolgere. Il token può essere limitato nel tempo e quindi anche se la terza parte mantiene il token, diventa inutile dopo che è scaduto.

    
risposta data 19.01.2015 - 15:08
fonte