Sto osservando i nuovi bit dell'autenticazione ASP.NET MVC 5 e ho notato che tutto ora è un ClaimsIdentity. Mi chiedevo dove sono memorizzati quei valori:ClaimsIdentity in ASP.NET MVC 5
Sessione, Cache o nel Cookie stesso.
Se è memorizzato nel cookie, esiste un ovvio limite al numero di richieste che è possibile archiviare prima di superare il limite di dimensione dei cookie.
ClaimsIdentity non dispone di un meccanismo di archiviazione. Ma se si utilizza il middleware cookie OWIN, sì, esso viene memorizzato in un cookie. E sì - c'è un limite.
Quindi, per impostazione predefinita, il modello MVC5 genera ClaimsIdentity dal database e lo mantiene in un modulo cookie valido per un po '. Ma i dati dell'utente sono memorizzati in un database SQL per impostazione predefinita.
Per impostazione predefinita i dati del dominio sono archiviati in SQL Server, capisco quella parte, ma quando si va a creare e alimentare l'oggetto ClaimsIdentity a AuthenticationManager in quel punto si memorizzano gli stessi dati nel cookie. Se i tuoi dati sono troppo grandi per un cookie, i cookie non vengono mai scritti nel browser perché verranno rifiutati a causa della violazione dei limiti di dimensione. –
Sì, Owin CookieMiddleware si occupa di trasformare il ClaimsIdentity in un cookie –
Come accennato in precedenza, i reclami provenienti da varie fonti possono essere mantenuti tra le sessioni tramite un cookie creato durante il processo di autenticazione di default con OWIN. Questo è solitamente configurato in \ App_Start \ Startup.Auth.cs. È possibile impostare le cose come quando scade il cookie, se si desidera una scadenza di scorrimento (il timeout del cookie viene aggiornato sulle visite di ritorno), dove si trova l'endpoint di autenticazione/autorizzazione, ecc. La parte successiva consente di agganciarsi alla fornitura di ulteriori attestazioni durante ClaimsPrincipal e ClaimsIdentity processo di creazione. Con una scadenza decente, devi farlo solo una volta per la sessione degli utenti. Nei successivi viaggi di ritorno al tuo sito, il middleware OWIN analizzerà il cookie e ricrea tutti i reclami da questo passaggio.
Non dovresti preoccuparti delle dimensioni dei cookie e il nuovo middleware OWIN auth implementa il chunking dei cookie (è attualmente disponibile nelle fonti di pre-release - la versione stabile non è un chunk).
Abbiamo implementato questo nella nostra azienda e abbiamo diverse fonti di reclami: il nostro servizio di single signon interno, la directory attiva e il database della nostra applicazione (per i ruoli e le proprietà aggiuntive sull'utente che ci interessa monitorare).
Bummer, quindi come gestisci i ruoli provenienti da Active Directory, che potrebbero essere 20 o 30 a causa di ambienti aziendali? Immagino che dovresti creare un ClaimsIdentity ibrido che era in qualche modo collegato ad Active Directory? –
Non li memorizzi nel cookie? – leastprivilege
Oppure utilizzare l'autenticazione di Windows: in questo modo si ottiene WindowsIdentity. – leastprivilege