Posso/devo usare Asp.Net Identity con gli account organizzativi?

Question

Desidero che i miei utenti accedano alla mia app Web con i loro account organizzativi (AD, AAD, O365) e utilizzino Identità Asp.Net per archiviare localmente le informazioni relative al profilo o al ruolo delle app nella mia applicazione, informazioni I don ' Voglio sporcare il mio elenco o quello dei miei inquilini con.

Non sono sicuro che questo scenario sia realistico poiché trovo così poche informazioni a riguardo. In MVC 4 era fattibile. Vorrei creare un'applicazione Web MVC4 vuota, utilizzare lo strumento Identity and Access per configurare l'autenticazione federata e archiviare il claim del nome in una tabella Users che avrei configurato con SimpleMembership (come this.)

Sembra comunque meglio favorire l'identità di Asp.Net su SimpleMembership per un nuovo sviluppo. Ma sembra molto più difficile. Guardando i modelli Web ASP.NET in Visual Studio 2013 RTM dovrei combinare i bit del modello Account individuali con quelli del modello Account aziendali. Ho visto che l'identità di Asp.Net memorizza le informazioni di accesso esterne nella tabella AspNetUserLogins out-of-the-box (che posso modificare prima con il codice EF6) ma non riesco a capire quali informazioni dal mio ClaimsIdentity memorizzerei migliore (titolarità di titolare e nome?) o in quale punto del codice. Il modello Account organizzativi fa riferimento a Microsoft.Aspnet.Identity ma non sembra mai chiamarlo.

Il mio scenario è valido? Ci sarà un campione su cui posso costruire la versione finale del VS2013? Sarebbe meglio usare una propria implementazione per archiviare informazioni di ruolo e profilo invece di Asp.Net Identity?

Answer 1

Questo è uno scenario valido e ho implementato qualcosa di simile a questo. Supponiamo che tu voglia memorizzare i "metadati" di un utente WAAD nel tuo repository locale. Per metadati, intendo le informazioni di identificazione di base che è possibile utilizzare per legare l'utente nel repository locale alla stessa voce dell'utente in WAAD. Ecco quello che vorrei conservare:

IdentityProvider (Waad, in questo caso)
TenantId (il formato di questo campo può variare tra i provider di identità, ma una stringa dovrebbe essere sufficiente)
UserId (ancora una volta , il formato di questo campo può variare tra gli idP ma una stringa potrebbe funzionare ... nome reclamo, in questo caso - purché sia ​​univoco tra gli utenti all'interno di un titolare)

Queste sono le informazioni che dovresti essere in grado di prendi il ClaimsPrincipal/ClaimsIde ntity. Ho implementato la mia applicazione prima che VS 2013 entrasse in scena, quindi ho fatto il mio, ma dopo aver letto il nuovo documento di identità "one" ASP.NET, sembra abbastanza estensibile e potrebbe essere una buona idea accettarlo. Permette anche di collegare diversi fornitori di storage (non solo database relazionali).