Come consentire più metodi di autenticazione in ASP.NET?

Question

Sto costruendo una nuova applicazione ASP.NET MVC (in C#) e uno dei requisiti è creare un nuovo database di membri. Per questo, avremmo bisogno di ruoli per gestire i diversi tipi di membri e profili per gestire i metadati aggiuntivi associati a ciascun membro. Fin qui tutto bene, basta usare gli standard MembershipProvider, RoleProvider e ProfileProvider forniti come parte di .NET Framework.

Tuttavia, il problema è che mi piacerebbe consentire diversi metodi di autenticazione. Vorrei che gli account e le credenziali di accesso avessero una relazione uno-a-molti (un account può avere un numero di credenziali di accesso allegato). Ad esempio, un utente potrebbe avere un account OpenID e ActiveDirectory collegato al proprio account.

Tuttavia, dopo aver sperimentato alcuni modi, abbiamo optato per il percorso MembershipProvider (spiegato come è stato ottenuto come risposta sotto).

La mia domanda è: come hanno fatto le persone prima e come la gente potrebbe suggerire di avvicinarmi? Sembra che si tratti di qualcosa che è stato raggiunto su un certo numero di siti, ma una ricerca qui non restituisce nulla di solido con cui giocare.

EDIT: Dopo aver guardato intorno per un buon periodo di ore durante la notte e questa mattina - non sono ancora convinto che la macellazione di un singolo MembershipProvider sarebbe stata l'opzione più semplice. Avere più MembershipProviders dà lo stesso effetto?

BOUNTY EDIT: Con nessuna risposta, presumo che non ci sia più la soluzione ottimale che quella che ho postato come risposta. È davvero così? Sto offrendo una ricompensa per cercare di vedere se qualcuno ha ulteriori pensieri su questo e se ci sono alternative migliori.

BOUNTY ACCEPT EDIT: Penso che WIF sia la risposta accettata di seguito, per una versione .NET 4 e forse altre versioni in quanto probabilmente funziona con 3.5. Oltre a questo, forse un MembershipProvider macellato o adattato potrebbe essere ancora rilevante.

Answer 1

A mio parere, la "via reale" di fare questo è quello di utilizzare federazione con WIF (Windows Identity Foundation, già struttura di Ginevra).

L'idea è di separare l'autenticazione dall'autorizzazione. L'autenticazione viene eseguita da un cosiddetto STS (Security Token Service) e gestisce tutti i possibili meccanismi di accesso che si desidera supportare. Quando un utente è stato autenticato, STS emette un token contenente un insieme di attestazioni e l'identità dell'utente. Questo token viene inviato al sito Web (chiamato relying party in questo gergo) e il sito Web determina quali parti del sito l'utente ha accesso in base alle attestazioni nel token. WIF fornisce sia i membri che i provider di ruoli che estraggono le informazioni dal token.

È possibile leggere sulla creazione di claims aware website here.

Uno dei vantaggi di questo approccio è la separazione delle preoccupazioni tra autenticazione e autorizzazione. Non è necessario alcun abbonamento complesso e roleproviders nel tuo sito web. Inoltre, l'STS può essere riutilizzato per autenticare gli utenti ad altre applicazioni che si possono avere senza dover registrarsi più di una volta (effettivamente ottenendo il single sign-on)

Lo svantaggio è che si dovrà passare un po 'di tempo a studiare questi concetti e codifica il tuo STS. Intendiamoci, non è difficile codificare un STS con WIF, ma non è nemmeno un compito al 100%.

Se sono riuscito a solleticare il tuo interesse, ti consiglio di iniziare leggendo this whitepaper.

Cordiali saluti,

Klaus

Answer 2

Un'idea che abbiamo seguito è creare un provider di appartenenza/ruolo/profilo personalizzato. Abbiamo personalizzato in modo significativo i metodi di accesso/autenticazione e disponiamo di una tabella aggiuntiva di accessi. In questa tabella sono fondamentalmente solo contenuto:

LoginID (Auto-Incremental ID, PK) 
UserID (FK) 
LoginSystemID (FK) 
...blah blah 

All'interno quanto sopra, la LoginSystemID era un collegamento a una tabella di ricerca straniero che ha aiutato il sistema per determinare quale servizio di autenticazione da utilizzare (ad esempio standard, AD, OpenID, collegarsi con facebook - ecc) .

Il problema che abbiamo avuto era che il campo Nome utente nella MembershipProvider non poteva essere vuoto e mentre nel nostro schema di ognuno aveva un'UserID (era il nome account), non avevano un nome utente che è stato unico. Abbiamo dovuto aggirare questo generando un GUID e usando quello. Questo ovviamente è nascosto all'utente e può essere visualizzato un attributo DisplayName dalla nostra tabella Users.

Questo è stato fatto tramite FormsAuthenication (i controlli AD sono stati eseguiti tramite i controlli LDAP). Tuttavia, è stato aggiunto un ulteriore livello (un modulo web) con le impostazioni appropriate all'interno di IIS che ha fornito un mezzo per l'autenticazione automatica di Windows - ci reindirizziamo lì nell'istanza che riteniamo che l'utente sia probabilmente interno (in base all'indirizzo IP).

Answer 3

Utilizzare materiale framework standard.Vedere http://blogs.teamb.com/craigstuntz/2009/09/09/38390/

si può avere un numero illimitato di metodi di autenticazione collegato a un conto, la magia è nel FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); dichiarazione