Protezione di un URL Web quando viene chiamato da un'applicazione client

1

Stiamo sviluppando una singola app Angular2 / NodeJS che avrà un modulo basato sul web per i nostri utenti da compilare e inviare. Non abbiamo nessuna applicazione Web per i nostri utenti per accedere (quindi nessun SSO), ma il nostro gli utenti accedono alle nostre app partner, che possono essere un'applicazione Web o un dispositivo mobile, ciascuno con il proprio meccanismo di autenticazione. Le nostre applicazioni per i partner chiamano fondamentalmente la nostra API per ottenere vari contenuti e mostrarli nella loro interfaccia utente. Ora uno dei nostri contenuti avrà il link alla nuova app di forma che stiamo sviluppando.

Vogliamo proteggere la chiamata all'app Form in modo tale che la richiesta possa essere attivata solo dalle nostre app partner e da nessun altro luogo. Le app partner non possono impedire all'utente di copiare l'URL, ma vogliamo essere sicuri che la richiesta provenga dalle nostre app partner.

Qual è il modo migliore per ottenere questo risultato con una codifica minima o nulla per i nostri partner poiché non abbiamo alcun controllo sui loro cicli di sviluppo o di rilascio. Poche delle opzioni che stiamo valutando

Opzione 1:

Controlla l'intestazione http, Referer. link . Questa potrebbe non essere la soluzione giusta come a) può essere facilmente falsificato ( link ) e b) Il client può essere un'app mobile e decidere di non inviare l'intestazione

Opzione 2:

Un'altra opzione sarebbe il nostro partner per passare un token come parametro nascosto. Quindi, supponendo che qualsiasi utente esperto di tecnologie non guardi nel sorgente della pagina per trovare ciò che è il token. Ovviamente questo potrebbe richiedere qualche attività dev dai nostri partner che vorremmo evitare.

Ci sono altre soluzioni eleganti che possiamo provare

    
posta Tatha 16.06.2017 - 20:38
fonte

1 risposta

1

Stai provando a utilizzare i tuoi fornitori come provider Single Sign-On. Questo è assolutamente possibile ... se sono disposti ad implementare un protocollo di identità federato come OAuth, SAML, Kerberos, ecc. Ciò implicherebbe un notevole lavoro di ingegneria da parte loro e probabilmente un notevole lavoro burocratico e responsabilità legale dal momento che HIPAA è in gioco. (Non lo so, non sono il tuo avvocato)

Per i motivi che hai elencato, fare affidamento sull'intestazione del Referer o su un segreto condiviso, illimitato e illimitato è assolutamente fuori questione. Inoltre, fidarsi di un utente semplicemente perché era connesso a un fornitore fidato è anche fuori questione. La tua API deve sapere chi, in particolare, sta agendo su di esso e memorizza / registra tali informazioni. La tua attività potrebbe non interessarti, ma HIPAA lo fa.

I protocolli SSO / identità federata sono metodi per generare, passare e controllare token come l'opzione 2 specifici per l'utente, finestra temporale, ecc. Non inventare il proprio. OAuth è probabilmente il più semplice da implementare.

La soluzione più semplice è creare account utente nell'app NodeJS. Gli utenti devono effettuare l'accesso (avere i cookie di sessione) per andare ovunque con l'URL dal proprio fornitore. Nessun problema di identità federata.

Un'altra soluzione piuttosto semplice consiste nel comunicare direttamente l'API e i backend dei fornitori, senza alcun browser dell'utente finale. HTTPS e un semplice token in un'intestazione HTTP sarebbero ragionevoli. Il reciproco TLS con i certificati client è il gold standard. Ma questo dipende dai segreti che restano nel backend. Ciò significherebbe anche che eventuali modifiche nel modo in cui interagisci sono modifiche al codice per i tuoi fornitori.

La vera soluzione è implementare un provider di identità (distribuirlo a Microsoft Azure, AWS o OneLogin o assumere consulenti per farlo all'interno del firewall) e integrarlo con tutti i fornitori e le API in modo che solo gli utenti avere un account da trattare I tuoi fornitori esistenti quasi certamente non vogliono questo ruolo. La gente di SaaS potrebbe non volerlo perché HIPAA, ma probabilmente uno di loro sarà disposto a sottoscrivere un Accordo di Business Associate HIPAA per il giusto prezzo.

    
risposta data 17.06.2017 - 07:48
fonte

Leggi altre domande sui tag