Situazione
Abbiamo un'app Web a singola pagina che consente all'utente di trascinare i propri certificati e la propria chiave privata. Questi vengono quindi utilizzati per l'autenticazione nel servizio web.
Mentre i browser sono in grado di eseguire un handshake TLS che include l'autenticazione del client tramite HTTPS, utilizzano solo i certificati installati nell'archivio certificati del sistema operativo (ad esempio Chrome su macOS o MS Edge su Windows) o nell'archivio certificati del browser (ad es. Firefox) .
Tuttavia, non c'è modo di fornire un certificato / chiave privata alle API di richiesta fornite dal browser come standardizzate dal W3C. Ad esempio, fetch () consente solo di specificare se le credenziali installate dovrebbero essere incluse oppure no.)
Domanda
È ragionevole implementare qualche tipo di addizione; "TLS bridging" servizio nella nostra situazione?
Funzionerebbe come segue:
- Il servizio di bridging accetta il certificato dal client (ad esempio tramite HTTP),
- ... avvia in modo sincrono un handshake con il vero servizio di autenticazione del client
- ... e risponde passando la sfida di handshake TLS al client.
- Il client è in grado di risolvere la sfida con la chiave privata rilasciata e di inviarla di nuovo con una richiesta HTTP aggiuntiva
- Il servizio di bridging può quindi rispondere al risultato dell'handshake / richiesta (ad esempio il token di autenticazione)
UPDATE 1:
Vincoli
Per ora sono impostati i seguenti vincoli tecnici:
- Soluzione solo JS nell'app Web (ad es. senza Flash)
- La chiave privata del client non deve essere trasmessa a nessun server
- L'installazione manuale del certificato su OS / browser non deve essere necessaria.
UPDATE 2:
A partire dal 20 marzo 2018 il W3C elenca lo Standard di autenticazione Web come "Candidate Recommendation" che risolverebbe il problema problema descritto nell'offerta di API standardizzate per eseguire l'autenticazione del client. I documenti MDN sono anche abbastanza istruttivi sull'utilizzo di tale API nello stato corrente.