Cutting Edge - Cookie, attestazioni e autenticazione in ASP.NET Core

2017-10-04

Settembre 2017

Volume 32 Numero 9

Il presente articolo è stato tradotto automaticamente.

Da Dino Esposito | 2017 settembre

Dino Esposito La maggior parte della documentazione di riguardanti il tema di autenticazione in ASP.NET Core è incentrata sull'utilizzo del framework ASP.NET Identity. In tale contesto, operazioni non sembrano avere modificato la maggior parte o, più precisamente, tutte le modifiche che si sono verificati nell'infrastruttura di avranno stato nascosto all'interno del framework in modo che risulti quasi identica nell'area di.

Se si esamina l'autenticazione utente in ASP.NET Core di fuori di preferisci territorio di ASP.NET Identity, potrebbe essere piuttosto diverso da quello nelle versioni precedenti. ASP.NET Identity è un framework flessibile, completo, big è inutile se è sufficiente per autenticare gli utenti tramite le credenziali di normale da una semplice tabella di database. In questo caso, si noterà che l'approccio generale per l'autenticazione rimane basata su concetti comuni, ad esempio entità, i form di accesso, gli attributi di richiesta di verifica e autorizzazione, ad eccezione del fatto che la modalità di implementazione di essi è completamente diversa. In mese questo, l'API di autenticazione cookie verrà esaminato come resi disponibili in ASP.NET di base, inclusi i fatti di base di autenticazione esterno.

Foundation di autenticazione ASP.NET

In ASP.NET, l'autenticazione utente prevede l'utilizzo di cookie. Tutti gli utenti che tentano di visitare una pagina privata vengono reindirizzati a una pagina di accesso se non dispone di un cookie di autenticazione valido. Pagina di accesso, dopo aver verificato fornito creden-tials, genera il cookie, che quindi viene trasferita con le successive richieste da tale utente tramite il browser stesso fino alla scadenza. Questo è lo stesso flusso di lavoro di base che è possibile conoscere dalle versioni precedenti di ASP.NET. In ASP.NET Core, solo risulta diverso a causa di middleware di diversi e la configurazione dell'ambiente di runtime diversi.

Esistono due modifiche principali in ASP.NET Core per quelle provenienti da uno sfondo a ASP.NET MVC e Web Form ASP.NET. Innanzitutto, non è più un file Web. config, vale a dire che la configurazione del percorso di accesso, nome del cookie e scadenza viene recuperata in modo diverso. In secondo luogo, l'oggetto IPrincipal: l'oggetto utilizzato per l'identità dell'utente del modello, è ora basata su attestazioni, anziché il nome di utente normale. Per abilitare l'autenticazione dei cookie in un'applicazione di 1. x di ASP.NET Core completamente nuova, è prima di fare riferimento il pacchetto Microsoft.AspNetCore.Authentication.Cookies e quindi aggiungere il frammento di codice in figura 1.

Figura 1, la registrazione di Middleware di autenticazione dei Cookie

// This code is for ASP.NET Core 1.x
public void Configure(IApplicationBuilder app)
{
  app.UseCookieAuthentication(new CookieAuthenticationOptions
  {
    AutomaticAuthenticate = true,
    AutomaticChallenge = true,
    AuthenticationScheme = "Cookies",
    CookieName = "YourAppCookieName",
    LoginPath = new PathString("/Account/Login"),
    ExpireTimeSpan = TimeSpan.FromMinutes(60),
    SlidingExpiration = true,
    ReturnUrlParameter = "original",
    AccessDeniedPath = new PathString("/Account/Denied")
  });
}

Maggior parte delle informazioni che le applicazioni ASP.NET MVC classiche memorizzate nella sezione < authentication > del file Web. config siano configurate come opzioni del middleware. Frammento di in figura 1 comprehends opzioni canoniche, è possibile scegliere. Figura 2 viene spiegata ciascuna in modo più dettagliato.

Figura 2 opzioni di autenticazione Cookie

Proprietà	Descrizione
AccessDeniedPath	Indica il percorso in cui un utente autenticato verrà reindirizzato se l'identità specificata non dispone dell'autorizzazione per visualizzare la risorsa richiesta. Lo stesso come ottenere un codice di stato HTTP 403.
AutomaticAuthenticate	Indica il middleware viene eseguito in ogni richiesta e tenta di convalidare i cookie e creare un oggetto identità dal contenuto.
AutomaticChallenge	Indica che se l'utente non è autenticato o per l'accesso negato pagina se l'utente è autenticato ma non autorizzato per la risorsa richiesta, il middleware reindirizza il browser a una pagina di accesso.
AuthenticationScheme	Nome del middleware. Questa proprietà viene utilizzata in combinazione con AutomaticChallenge in modo selettivo prelevare il middleware di autenticazione in base a una richiesta.
CookieName	Nome del cookie di autenticazione da creare.
ExpireTimeSpan	Imposta l'ora di scadenza del cookie di autenticazione. Se l'ora deve essere inteso come assoluta o relativa è determinato dal valore della proprietà SlidingExpiration.
LoginPath	Indica il percorso in cui un utente anonimo verrà reindirizzato accedere con le proprie credenziali.
ReturnUrlParameter	Nome del parametro viene utilizzato per passare l'URL richiesto originariamente che ha causato il reindirizzamento alla pagina di accesso in caso di utenti anonimi.
SlidingExpiration	Indica se il valore ExpireTimeSpan è assoluto o relativo. In quest'ultimo caso, il valore viene considerato come un intervallo e il middleware verrà eseguire nuovamente il cookie se più della metà l'intervallo è trascorso.

Si noti che le proprietà del percorso non sono di tipo stringa. LoginPath e AccessDeniedPath sono di tipo valore PathString, che, rispetto al tipo di stringa semplice, fornisce il corretto escape durante la compilazione di un URL della richiesta.

Il principio generale del flusso di lavoro di autenticazione utente in ASP.NET Core offre una quantità di flessibile bilità senza precedenti. È possibile personalizzare tutti gli aspetti quando è necessario. Ad esempio, di seguito viene illustrato come sia possibile controllare il flusso di lavoro autenticazione in uso in base a una richiesta.

Gestione di più schemi di autenticazione

Impostando AutomaticChallenge su false indicare al middleware non di rispondere alle sfide [Authorize] da ogni formando, ad esempio, un reindirizzamento. Se nessun middleware gestirà la richiesta di verifica, viene generata un'eccezione. Richiesta di verifica automatica è stata la norma nelle versioni precedenti di ASP.NET ed è stata quasi nulla, è possibile eseguire su di esso.

In ASP.NET Core, è possibile registrare più e distinct pezzi di middleware di autenticazione e determinare modo algoritmico o tramite configurazione quale middleware deve essere utilizzata per ogni richiesta. Quando viene utilizzato più di middleware di autenticazione, l'autenticazione automatica può essere true in più middleware. AutomaticChallenge, invece, deve essere abilitata solo su zero o più middleware. Per ulteriori informazioni, vedere bit.ly/2tS07Sm.

Esempi comuni di middleware di autenticazione sono basati su cookie di autenticazione, l'autenticazione della connessione, l'autenticazione tramite social network, o un server di identità e qualsiasi altra cosa può mai essere considerato implementare. Si supponga di che avere il seguente codice nel metodo di configurazione della classe di avvio:

app.UseCookieAuthentication(new CookieAuthenticationOptions()
{
  AuthenticationScheme = "Cookies",
  LoginPath = new PathString("/Account/Login/"),
  AutomaticAuthenticate = true
});
app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
{
  AuthenticationScheme = "Bearer",
  AutomaticAuthenticate = true 
}

Tenere presente che non vi siano costanti da utilizzare al posto di magiche stringhe come "Cookie" solo per limitare gli errori di battitura. In particolare, è possibile sostituire la stringa "Cookie" come indicato di seguito:

AuthenticationScheme = CookieAuthenticationDefaults.AuthenticationScheme

Si noti che UseIdentityServerAuthentication non fa parte del framework ASP.NET Core, ma appartiene a framework Identity Server (vedere github.com/IdentityServer). Per scegliere lo schema di autenticazione in base a una richiesta, utilizzare un nuovo attributo all'attributo Authorize che, in ASP.NET MVC, contrassegna azioni come l'autenticazione e autorizzazione:

[Authorize(ActiveAuthenticationSchemes = "Bearer")]
public class ApiController : Controller
{
  // Your API action methods here
  ...
}

L'effetto del frammento di codice consiste nel fatto che tutti gli endpoint pubblici della classe di esempio ApiController sono soggetti all'identità dell'utente autenticato dal token di connessione.

L'identità dell'utente di modellazione

In ASP.NET, l'interfaccia IPrincipal definisce il contratto di software che definisce il nucleo dell'identità dell'utente. L'utente connesso viene esposto tramite la proprietà utente della proprietà controller HttpContext. IPrincipal ha la stessa implementazione in ASP.NET 4. x (incluso ASP.NET MVC) e ASP.NET Core. Tuttavia, in ASP.NET Core l'oggetto principal predefinito non GenericPrincipal, ma il nuovo tipo ClaimsPrincipal. La differenza è rilevante.

GenericPrincipal esegue il wrapping di una chiave parte delle informazioni utente, ovvero il nome utente, anche se è possibile aggiungere dati personalizzati dell'utente per il ticket di autenticazione crittografato nel cookie. Nel corso degli anni, il nome utente unico è diventato troppo piccolo per le esigenze di applicazioni moderne. Il ruolo dell'utente, nonché come alcuni altri blocchi di informazioni, la maggior parte notevolmente l'immagine e nome visualizzato, vengono visualizzati assolutamente necessarie oggi imposizione ogni applicazione realistico per creare le proprie informazioni di utente tipo o la query principale personalizzate per ogni e ogni richiesta utilizzando il nome utente come chiave. ClaimsPrincipal solo Vista risolve il problema.

Un'attestazione è una coppia chiave/valore che descrive una proprietà dell'utente connesso. L'elenco di proprietà è compito dell'applicazione, ma include nome e il ruolo minimo. Le attestazioni, sono in altre parole, il modo di ASP.NET Core per informazioni sul modello di identità. Le attestazioni possono essere letti da qualsiasi origine, se i database, cloud o l'archiviazione locale, anche hardcoded. La classe di attestazione è semplice come questa:

public class Claim
{
  public string Type { get; }
  public string Value { get; }
  
  // More properties ...
}

Il processo di accesso di ASP.NET Core passa attraverso tre classi: Attestazione, ClaimIdentity e ClaimsPrincipal.
La raccolta dell'elenco di attestazioni è sufficiente del popolamento di una matrice di oggetti di attestazione:

public Claims[] LoadClaims(User user)
{
  var claims = new[]
  {
    new Claim(ClaimTypes.Name, user.UserName),
    new Claim(ClaimTypes.Role, user.Role),
    new Claim("Picture", user.Picture)
  };
  return claims;
}

Il nome dell'attestazione è un normale nome descrittivo visualizzato come una stringa. Tuttavia, i tipi di attestazione più comuni sono stati raggruppati come costanti nella classe ClaimType. Prima di creare l'entità, che è necessaria per chiamare il flusso di lavoro autenticazione completata, è necessario ottenere l'attesa di un oggetto identità:

var identity = new ClaimsIdentity(claims, "Password");

Il primo argomento è Auto-descrittivo, ovvero l'elenco delle attestazioni associato all'identità da creare. Il secondo argomento è una stringa che fa riferimento allo schema di autenticazione necessario per verificare l'identità. La stringa "Password" è un promemoria di ciò che verrà richiesto dal sistema per un utente dimostrare la propria identità. La stringa "Password" è informativo e non un elemento di sintassi.

Un altro aspetto interessante dell'esempio precedente è che un nome utente esplicita non è strettamente necessario. Tutte le attestazioni, indipendentemente dal tipo dichiarato, utilizzabile per assegnare un nome utente. Frammento di codice seguente viene illustrato un altro modo equivalente, un nuovo oggetto di identità:

var identity = new ClaimsIdentity(claims,
  CookieAuthenticationDefaults.AuthenticationScheme,
  "Nickname",
  ClaimTypes.Role);

La nuova identità è "Cookie" come schema di autenticazione e nome alternativo è il nome dell'attestazione dall'elenco fornito da utilizzare per fornire il nome dell'utente. Ruolo, è invece il nome dell'attestazione nello stesso elenco di definizione del ruolo. Se non specificato, per impostazione predefinita gli ultimi due parametri ClaimTypes.Name e ClaimTypes.Role. Infine, creare l'entità dall'identità. Vale la pena notare, tuttavia, un'entità può disporre di più identità. Se sembra strano, considerare che aree diverse della stessa applicazione potrebbe essere necessario informazioni diverse per autenticare l'utente in modo molto simile a un ID è necessario per identificare se stessi alcuni desk hotel e una chiave electronic per inserire l'elevazione. La classe ClaimsPrincipal include una proprietà di identità (insieme) e una proprietà Identity. Quest'ultimo è solo un riferimento al primo elemento nella raccolta.

Autenticazione esterna

ASP.NET Core supporta l'autenticazione esterna tramite provider di identità da zero backup. La maggior parte dei casi, non è installato il pacchetto NuGet appropriato per l'attività. Per si basano su Twitter per l'autenticazione degli utenti, è possibile importare il pacchetto Microsoft.AspNetCore.Authentication.Twitter e installare il middleware correlato:

app.UseTwitterAuthentication(new TwitterOptions()
{
  AuthenticationScheme = "Twitter",
  SignInScheme = "Cookies",
  ConsumerKey = "...",
  ConsumerSecret = "..."
});

La proprietà SignInScheme è l'identificatore il middleware di autenticazione che verrà utilizzato per rendere permanente l'identità risulta. Nell'esempio, verrà utilizzato un cookie di autenticazione. Per visualizzare i relativi effetti, è innanzitutto necessario aggiungere un metodo controller chiamino Twitter:

public async Task TwitterAuth()
{
  var props = new AuthenticationProperties
  {
    RedirectUri = "/"  
  };
  await HttpContext.Authentication.ChallengeAsync("Twitter", props);
}

Successivamente, una volta Twitter correttamente ha autenticato l'utente, la proprietà SignInScheme indica all'applicazione sulle operazioni da eseguire in seguito. Un valore pari a "Cookie" è accettabile se si desidera un cookie fuori le attestazioni restituito dal provider esterno (Twitter, nell'esempio). Se si desidera esaminare e completare le informazioni tramite, ad esempio, un modulo intermedio, è necessario interrompere il processo in due, Introduzione a uno schema di accesso temporaneo. Oltre a middleware del cookie standard disporre di quanto segue:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
  AuthenticationScheme = "ExternalCookie",
  AutomaticAuthenticate = false
});
app.UseTwitterAuthentication(new TwitterOptions
{
  AuthenticationScheme = "Twitter",
  SignInScheme = "ExternalCookie"
});

Quando viene restituito il provider esterno, un cookie temporaneo viene creato utilizzando lo schema ExternalCookie. Con il reindirizzamento percorso impostato in modo appropriato, è la possibilità di controllare l'entità restituita da Twitter e modificarla ulteriormente:

var props = new AuthenticationProperties
  RedirectUri = "/account/external"  
};

Per completare il flusso di lavoro che è anche necessario accedere allo schema di cookie e disconnettersi da schema temporaneo (ExternalCookie):

public async Task<IActionResult> External()
  var principal = await HttpContext
    .Authentication
    .AuthenticateAsync("ExternalCookie");
  // Edit the principal
  ...

  await HttpContext.Authentication.SignInAsync("Cookies", principal);
  await HttpContext.Authentication.SignOutAsync("ExternalCookie ");
}

ExternalCookie, nonché i cookie, sono identificatori appena interni e possono essere rinominati come rimangono coerenti in tutta l'applicazione.

Conclusioni

In ASP.NET Core che molte operazioni sembrano essere completamente diverso, ma al termine, la maggior parte dei concetti che sanno da ASP.NET rimane invariato. È necessario avere creato un cookie di autenticazione e, è comunque possibile controllare il nome del cookie e la data di scadenza. Autenticazione esterna è supportata e pagine di accesso hanno la stessa struttura. Tuttavia, configurazione e funzionamento sottostante dell'infrastruttura di autenticazione sono diverse, mantenendo la flessibilità precedente.

Tutti gli elementi indicati in questo articolo si riferisce a ASP.NET di base 1. x. Ci sono alcuni aspetti che funzioneranno in modo diverso in ASP.NET 2.0 Core. In particolare, il middleware di autenticazione è ora esposta come servizi e deve essere configurato nella configurazione di servizi:

services.AddCookieAuthentication(options =>
{
  Options.LoginPath = new PathString("/Account/Login"),
    options.AutomaticAuthenticate = true,
    options.AutomaticChallenge = true,
    options.AuthenticationScheme = "Cookies", 
    ...
});

Nel metodo di configurazione della classe di avvio delle applicazioni ASP.NET Core 2.0, sufficiente dichiarare l'intenzione di utilizzare servizi di autenticazione senza altre opzioni:

app.UseAuthentication();

Si noti inoltre che il metodo SignInAsync utilizzato nel codice per creare il cookie di autenticazione viene esposto dall'oggetto HttpContext direttamente, anziché passare tramite una proprietà di autenticazione intermedia, come illustrato nel frammento di codice ultimo per ASP.NET Core 1. x.

Dino Esposito è l'autore di "Microsoft .NET: Architettura delle applicazioni per l'azienda"(Microsoft Press, 2014) e"Moderne applicazioni Web con ASP.NET"(Microsoft Press, 2016). Un technical evangelist per .NET le piattaforme Android in JetBrains e degli altoparlanti frequenti eventi del settore in tutto il mondo, Esposito condivide la sua visione del software in software2cents@wordpress.com e su Twitter: @ despos.

Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: Chris Ross

Viene illustrato in questo articolo nel forum di MSDN Magazine

Condividi tramite