Non ripetere su Vostro singolo punto di errore nell'autenticazione

Il consolidamento dell'autenticazione in un singolo servizio si chiama Single Sign-On ed è stata una cosa, anche una migliore pratica, per come trent'anni.

His suggestion is that we either write the authentication into the individual applications or we should provide some sort of redundant auth system for if the primary system fails.

Hai già la tua autenticazione ASP.net nelle singole applicazioni, quindi, per essere onesti, "scrivere l'autenticazione nelle singole applicazioni" (con un sacco di copia e incolla, o librerie condivise, o qualsiasi altra cosa) è probabilmente il Minima quantità di lavoro.

Il suggerimento del sistema di autenticazione ridondante è un problema di sicurezza e un problema di manutenzione ed è chiaramente banane . Non è un suggerimento serio.

Mi sembra che tu abbia un problema con le persone, non un problema di programmazione. Il problema della tua gente è che devi capire il motivo reale del collega per l'opposizione. Probabilmente non è qualcosa che in realtà ha detto.

Alcune possibilità:

1. si sente che riscrivere l'intero stack di autenticazione per ogni applicazione sarà un lavoro eccessivo.
2. ritiene che riscrivere l'intero stack di autenticazione per ogni applicazione sia troppo rischioso, in termini di possibile violazione dell'autenticazione delle credenziali esistenti.
3. non capisce la soluzione IdentityServer e, a causa di ciò, non ci sta a suo agio.
4. non ha ideato personalmente la soluzione IdentityServer e, a causa di ciò, non è a suo agio con esso.
5. ha voglia di affrontare 2FA è abbastanza nuova tecnologia da affrontare e abbastanza nuova complessità da aggiungere alle app, senza assumere OpenID / OAuth / etc., ecc.
6. qualcos'altro a cui non ho pensato

Devi trovare quell'obiezione sottostante e valutarla in modo equo. (Potrebbe anche avere ragione!)

Un approccio sarebbe quello di fare un passo indietro rispetto alle soluzioni specifiche che ciascuno di voi ha sostenuto e cercare di concordare almeno sui criteri che dovrebbero essere usati per scegliere una soluzione, tenendo conto di ciascuna delle vostre preferenze in merito al rischio tecnico, short- termine contro carico di lavoro a lungo termine, ecc. (Nella scuola di negoziazione, chiamano questo distinguendo gli interessi dalle posizioni .)

Se, alla fine, è ancora convinto di avere ragione e ti stai sbagliando, e sei ancora convinto di avere ragione e ha torto, devi metterlo su un livello dove puoi presentare le tue opzioni preferite a qualcuno abilitato a effettuare la chiamata. E quindi entrambi dovete accettare la decisione.

Quella linea di pensiero secondo cui, dipendendo dallo stesso codice, quello che conta come singolo punto di errore non è necessariamente sbagliato ma assurdo. Con questa logica, puoi continuare a pensare a cose casuali che seguono questa regola - perché utilizzare gli stessi router, switch, server Web, linguaggio di programmazione, framework, ecc.?

La realtà è che tu già usi lo stesso database delle credenziali e già hai un singolo punto di errore. In effetti, se ognuno dei tuoi sistemi ha accesso diretto a questo database potresti interagire con esso in un modo che interferisce con altre applicazioni. Seguendo la logica di non fidarsi più del codice, si potrebbe sostenere che avendo un numero N di sistemi di autenticazione, si ha effettivamente N numero di punti singoli di guasti. Se invece disponi di una singola API, puoi controllare l'accesso e ridurre N a solo 1.

Abbiamo avuto discussioni simili su cui lavoro e il tuo collega non ha torto. Siamo arrivati alla conclusione (usiamo Atalasian's Crowd ma l'idea è la stessa di IdentityServer) che potremmo mitigare il rischio usando l'architettura ad alta disponibilità. C'è il rischio che se il servizio si interrompe, gli utenti non saranno in grado di autenticarsi. Per mitigare questo rischio suggerirei di rendere IdentityServer altamente disponibile. Essenzialmente si dovrebbe eseguire un bilanciamento del carico (mi piace HA Proxy o Nginx) e avere più di un'istanza di IdentityServer in esecuzione. Le istanze dovrebbero quindi connettersi a un cluster di database.

Questa elevata disponibilità fornirebbe un paio di vantaggi. Il primo è che se un nodo o un database non funziona, la funzionalità persiste e la disponibilità non viene influenzata. Il secondo è che distribuirà il carico degli utenti attraverso i nodi. È un po 'più di lavoro, ma ne vale la pena alla fine.

Questa è la pagina dei documenti che mostra una distribuzione tipica per l'alta disponibilità: link

Per quello che vale, l'architettura che stai suggerendo è ciò che la maggior parte delle organizzazioni più sane finiscono. Il fatto che l'autenticazione sia il proprio servizio semplifica la creazione di nuove funzionalità, come l'autenticazione OAuth2 per le terze parti che utilizzano le API.

In effetti, la specifica OAuth2 rivela questa progettazione interna nel fatto che si presume che il server di autorizzazione sia separato dal server delle risorse. Se non sai di cosa sto parlando, vedi link per una spiegazione che ho scritto alcuni anni fa su come funziona OAuth2.