Elementi essenziali da considerare prima di esternalizzare l'autenticazione con OpenID, OAuth o SAML

La risposta corretta dipenderà chiaramente dalla tua applicazione.

Ad esempio, hai elencato:

Option for "difficult" sign in process to improve security (Verisign), also see this related question

L'utilizzo di un provider come questo sarebbe una scelta terribile per un sito con requisiti di sicurezza di accesso bassi e un strong desiderio di basse barriere all'ingresso per ottenere una base di utenti, ad esempio uno stackexchange o Twitter. D'altra parte sarebbe un vantaggio per un sito che ha bisogno di eseguire transazioni finanziarie.

In una certa misura dipenderà anche dalla combinazione delle preferenze dei tuoi utenti in combinazione con la reputazione del fornitore. Se costringi gli utenti a utilizzare, ad esempio, Facebook, per iscriverti, potresti perdere utenti che hanno evitato Facebook. O google - hanno già abbastanza dati su di me, perché dovrei farli sapere ogni volta che accedo al tuo, per esempio, sito di appuntamenti?

Infine, penso che una "caratteristica" che ti manca sia la cronologia della sicurezza attuale (contro promessa ). Se un determinato fornitore ha avuto una serie di fallimenti, è probabile che continueranno ad avere dei fallimenti. Questo non vuol dire che un provider che non ha vulnerabilità note non ne avrà alcuni esposti in futuro.

Un problema chiave quando si utilizza un fornitore di identità in outsourcing (IdP) è una posizione di fiducia. Ti fidi di loro? Il fattore di fiducia assumerà molte forme ed è imperativo che cammini i tuoi sponsor aziendali attraverso i vantaggi e gli svantaggi dei modelli di fiducia federati prima di andare a farlo.

1. Hai un contratto esplicito o implicito con l'IdP? Questo è importante perché se la tua azienda fa affidamento su un IdP di terze parti, devi assicurarti che le pubblicità siano pienamente comprese su ciò che puoi e non puoi fare con le identità fidate e se IdP può estrarre il servizio senza preavviso ecc.
2. Non dici se gli utenti sono il pubblico o lo staff. Se si tratta di personale, è necessario considerare il processo JML (joiners, leavers, mover) e assicurarsi di disporre dei processi associati per gestire chi è autorizzato a vedere cosa. La federazione risolve in modo accurato gran parte dell'autenticazione, ma nessuno dei privilegi e dell'autorizzazione.
3. Hai elencato alcuni meccanismi federati che sono utili nei siti web pubblici. Se si sta anche federando con gli utenti del personale (cioè con le proprie identità), potrebbe essere necessario un connettore SAML. Lei parla di ADFS; che ha avuto i suoi limiti in passato in termini di conformità SAMLv2, ma è ottimo se si utilizza Active Directory come strumento IdP. L'industria ha alcuni giocatori importanti come Shibboleth (OSS) e Ping con il loro strumento "Federale". Hanno anche una soluzione Ping Connect che è un po 'più economica. Tuttavia, questi sono necessari solo se si è l'IdP e si utilizza un provider di servizi di terze parti (SP). Ping, IBM e CA dispongono di strumenti di federazione ma si trovano nella parte più costosa dello spettro.