Che cosa si intende per CookieAuthenticationOptions.AuthenticationType?

Question

In configurazione middleware Asp.Net Identità Auth della mia domanda ho

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
    LoginPath = new PathString("/Login/"), 
    //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    Provider = new CookieAuthenticationProvider { 
    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
         TimeSpan.FromMinutes(30), 
         (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie) 
        ), 
    }, 
}); 

avevo copiato questo da un altro app e ho notato che se togliere il commento alla linea di AuthenticationType, login riesce (ricevo un messaggio di successo nel mio logger scritto dal mio controller) ma reindirizza sempre alla schermata di login.

Nel documentation for CookieAuthenticationOptions si dice

L'AuthenticationType nelle opzioni corrisponde alla proprietà IIdentity AuthenticationType. Un valore diverso può essere assegnato in modo da utilizzare lo stesso tipo di autenticazione middleware più di una volta in una pipeline. (Ereditato da AuthenticationOptions.)

Io non capisco cosa significa, perché questo causerebbe il mio login richiesta di essere reindirizzato (dopo un login di successo non meno), né quale sia questa opzione essere utile per.

Answer 1

Questa è una stringa e può essere qualsiasi cosa. Ma questo è un identificatore per il tipo di autenticazione. E puoi avere più tipi di autenticazione: il tuo DB con utenti, Google, Facebook, ecc. Per quanto mi ricordo, questo viene aggiunto come reclamo al cookie generato all'accesso.

È necessario conoscere il provider di autenticazione quando si firma l'utente. Se il middleware di autenticazione è definita in questo modo:

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
     LoginPath = new PathString("/Login/"), 
     AuthenticationType = "My-Magical-Authentication", 
     // etc... 
     }, 
    }); 

poi a firmare all'utente fuori è necessario la stessa stringa magica: AuthenticationManager.SignOut("My-Magical-Authentication")

Anche questa stringa è passato attraverso ClaimsIdentity quando viene creata principale.E senza AuthenticationType principale non può essere autenticata because:

/// <summary> 
/// Gets a value that indicates whether the identity has been authenticated. 
/// </summary> 
/// 
/// <returns> 
/// true if the identity has been authenticated; otherwise, false. 
/// </returns> 
public virtual bool IsAuthenticated 
{ 
    get 
    { 
    return !string.IsNullOrEmpty(this.m_authenticationType); 
    } 
} 

Questo metodo viene utilizzato IsAuthenticated attraverso tutta MVC codice di base, con tutti i meccanismi di autenticazione basandosi su questo.

Inoltre, in teoria, è possibile accedere tramite più provider e disconnetterne solo uno alla volta, lasciando il resto dei provider ancora autenticato. Anche se non l'ho mai provato.

Un altro uso Ho appena trovato - se non si forniscono CookieName nella configurazione middleware, quindi Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; (see second if statement in constructor).

Sono sicuro che ci sono più posti dove è usato. Ma la cosa più importante è fornirla ed essere coerenti con il nome o otterrai dei bug sottili nel sistema di autenticazione.

Answer 2

Non conosco l'intera risposta, ma ho un esempio su ciò che sarebbe essere utile per.

Possiedo un sito Web multi-tenant: il sito Web viene eseguito come una singola istanza. Più domini sono collegati ad esso. Ogni dominio è un titolare separato (con un insieme separato di utenti). Per implementare un login di Facebook per inquilino, avevo bisogno di un'app per Facebook per inquilino. Per configurare questo, ho dovuto impostare un CallbackPath unico e un AuthenticationType univoco per ogni inquilino:

var facebookOptions = new FacebookAuthenticationOptions 
{ 
    AuthenticationType = "Facebook-{tenantID}", 
    CallbackPath = new PathString($"/signin-facebook-{tenantID}") 
} 

ho pensato che è stato utilizzato anche come nome del cookie, ma non è il caso di un account di accesso esterno come FacebookAuthentication. Quello che ho notato è che questo valore del AuthenticationType spuntato quando si richiede:

1. l'IdentityUserLogin.LoginProvider via authenticationManager.GetExternalLoginInfoAsync()
2. l'AuthenticationDescription.AuthenticationType via authenticationManager.GetExternalAuthenticationTypes() (sembra logico ;-))
3. L'IdentityUserLogin.LoginProvider per ogni user.Logins (simili a 1)

e, ultimo ma non meno importante: il valore di AuthenticationType viene memorizzato nella colonna di database AspNetU serLogins.LoginProvider.

Answer 3

Se si imposta una soluzione asp.net fresca, il codice di set-up standard (in contrasto con il codice copiato da un'altra applicazione) in Startup.Auth includete la linea AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

Questo crea un cookie (con un nome predefinito di .AspNet.ApplicationCookie), che è possibile vedere se si guarda nell'elenco dei cookie attivi del browser, utilizzato (tra le altre cose) per verificare se l'utente è autenticato o meno per ogni richiesta. Se il cookie non è lì (o l'utente non è in qualche modo autenticato), il middleware reindirizza alla route specificata nella linea LoginPath = new PathString("/Login/"),

Il fatto che questa riga sia commentata nel codice e l'app della tua app suggerisce che c'è qualche altra configurazione non standard nel codice per autenticare l'utente. Se decommentate questa riga e l'accesso ha esito positivo ma reindirizza al login, ciò suggerisce che esiste un conflitto tra il codice non standard e il middleware che risulta nel middleware che determina che l'utente non è autenticato e viene reindirizzato al LoginPath .

Vorrei verificare se nell'app è presente un codice di autenticazione non standard e determinare ciò che fa specificamente e la risposta per il conflitto deve presentarsi. Il consiglio generale non è quello di cambiare il codice di autenticazione standard a meno che non si sappia esattamente quali sono le implicazioni di ciò (e può essere complicato, con molte trappole per gli sprovveduti).

In particolare per la tua domanda, questa opzione non è solo utile, è fondamentale per il funzionamento standard del middleware Identity. Sembra che tu abbia un codice non standard nella tua app. In tal caso, dovresti determinare appieno cosa fa (e le sue implicazioni) per quanto riguarda la sicurezza di accesso, o ripristinare di nuovo il codice di identità standard, se possibile.