Identità ASP.NET e provider di appartenenze ASP.NET "Mashup"

Question

Abbiamo un'applicazione Web esistente che è stata creata su MVC & Provider di appartenenze SQL per l'autenticazione dell'utente. L'applicazione include anche schermate di amministrazione dell'amministratore per creare/modificare utenti, reimpostare password, attivare account, ecc ... È un sistema abbastanza maturo ed è stato in produzione per ~ 2,5 anni.

Ora abbiamo un nuovo requisito per esporre alcuni dati dal sistema tramite API, e consideriamo WebApi come una tecnologia candidata.

Uno dei problemi che sto incontrando riguarda l'autenticazione. Mi piacerebbe sfruttare le funzionalità esistenti di gestione utenti/ruoli nella nostra applicazione, per creare e gestire gli account API. Tuttavia, poiché l'opzione preferita per WebAPI è l'uso dell'identità ASP.NET (token claim/bearer ecc.) Sono un po 'confuso su quali sarebbero le opzioni migliori.

Sarebbe possibile o una cattiva idea di in qualche modo il clacson nell'autenticazione utente/password del provider di appartenenza esistente nel web api auth mechs. C'è un metodo nello ApplicationOAuthProvider, che sembra che potrei manipolare sostituendo la linea IdentityUser user = await userManager.FindAsync(context.UserName, context.Password); con una chiamata al MembershipProvider. Questo sembra molto semplicemente cludgy.

Il pensiero & sarebbe molto apprezzato.

Answer 1

Questo potrebbe essere fatto implementando il proprio UserStore. Penso che ci sarebbero molti draghi. Dovresti pensare a tutti questi altri scenari e riconciliare i due aspetti: password dimenticata, conferma via e-mail, conteggi degli errori di accesso e tempi, e così via. Fondamentalmente tutto ciò che aggiorna i dati dell'utente dovrebbe essere pensato, e forse fatto doppiamente in ogni gruppo di tabelle. Se potessi aggiungere le colonne alle tue tabelle di appartenenza esistenti per supportare l'interfaccia dell'identità di asp.net che potrebbe essere di aiuto, ma a un certo punto finirai per rottamare la maggior parte della porzione di accesso ai dati e implementare un intero UserStore invece di uno per lo più delegare al codice basato su Entity Framework originale.

Answer 2

Non proprio una risposta, solo il mio 0,02 centesimi.

Penso che trascorrerai tutto il tempo che dedichi a diventare MembershipProvider in una nuova identità, come sarebbe necessario per aggiornare correttamente il nuovo framework Idenitty.

Ho effettuato l'aggiornamento in 2 sistemi diversi, entrambi non piccoli (un 200K, un altro 70K di linee di codice) con un numero esteso di utenti. Il sistema più piccolo mi ha richiesto 7 giorni uomo, uno più grande 5 giorni (sapevo cosa stavo facendo la seconda volta). Entrambi i sistemi avevano un numero esteso di codice di gestione degli utenti, uno dei sistemi aveva un modo di impersonare un altro utente per gli amministratori. Tutto ha funzionato senza intoppi e non ci sono stati tempi di fermo. Gli utenti non hanno notato alcuna differenza.
Ma dopo l'aggiornamento le cose con la gestione e l'autenticazione degli utenti sono state molto più semplici, avrete i vostri 5 giorni spesi per l'aggiornamento in pochissimo tempo. Pensa a questo come un investimento -))

Ho guardato il codice sorgente (nel decompilatore) di MembershipProvider e un sacco di cose sono statiche, disordinate, sigillate e semplicemente ingestibili. Direi che sarà più semplice scaricarlo invece di creare più codice legacy, solo per mantenere la libreria che sta morendo.

In altre parole, sarà più semplice aggiornare tutto invece di provare a riutilizzare le vecchie cose.

Answer 3

mi piacerebbe sfruttare la funzionalità di gestione utente/ruolo esistente nella nostra applicazione, per creare e gestire gli account API.Tuttavia poiché l'opzione preferita per WebAPI è quello di utilizzare ASP.NET Identity (gettoni reclami/al portatore ecc ...) Sono un po 'confuso su ciò che sarebbe la migliore opzioni.

Non è una buona idea di mescolare con provider SQL appartenenza esistente e API Web in un unico progetto.

Nel mio scenario, ho creato un progetto separato Web API 2. Quindi ho creato un progetto di libreria di classi separato per mantenere il contenitore IoC in una singola posizione e sia l'app Web che l'API Web fanno riferimento a tale libreria di classi.

Il progetto API Web può ancora utilizzare le tabelle del provider di appartenenze SQL. Tuttavia, è necessario convalidare l'utente da solo utilizzando Membership Provider Encode Algorithm e creare da solo l'oggetto IPrincipal con Claims. Quindi assegnare a Thread.CurrentPrincipal.

Per l'autenticazione basata su token, si può semplicemente utilizzare JSON Web Token.

Aggiornato: Se avete più tempo, è possibile migrare SQL iscrizione direttamente a ASP.NET identità utilizzando this example. Quindi è possibile mantenere MVC e Web API in un singolo progetto, poiché entrambi utilizzano l'identità di ASP.NET.