Autenticazione remota

  • Articolo

La funzionalità di autenticazione remota degli adapter System.Web consente a un'app ASP.NET Core di determinare l'utente identity (autenticare una richiesta HTTP) rinviando a un'app ASP.NET. L'abilitazione della funzionalità aggiunge un endpoint all'app ASP.NET che restituisce un oggetto serializzato ClaimsPrincipal che rappresenta l'utente autenticato per tutte le richieste effettuate all'endpoint. L'app ASP.NET Core registra quindi un gestore di autenticazione personalizzato che (per gli endpoint con autenticazione remota abilitata) determina l'endpoint dell'utente identity chiamando tale endpoint nell'app ASP.NET e passando intestazioni e cookie selezionati dalla richiesta originale ricevuta dall'app ASP.NET Core.

Impostazione

Esistono solo alcune piccole modifiche al codice necessarie per abilitare l'autenticazione remota in una soluzione già configurata in base alle attività iniziali.

Prima di tutto, seguire le istruzioni di configurazione dell'app remota per connettere le app ASP.NET Core e ASP.NET. Esistono quindi solo un paio di metodi di estensione aggiuntivi da chiamare per abilitare l'autenticazione remota dell'app.

configurazione dell'app ASP.NET

L'app ASP.NET deve essere configurata per aggiungere l'endpoint di autenticazione. L'aggiunta dell'endpoint di autenticazione viene eseguita chiamando il AddAuthenticationServer metodo di estensione per configurare il modulo HTTP che controlla le richieste all'endpoint di autenticazione. Si noti che gli scenari di autenticazione remota in genere vogliono aggiungere anche il supporto proxy, in modo che qualsiasi autenticazione correlata reindirizzi correttamente all'app ASP.NET Core anziché al ASP.NET uno.

SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .AddProxySupport(options => options.UseForwardedHeaders = true)
    .AddRemoteAppServer(options =>
    {
        options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
    })
    .AddAuthenticationServer();

configurazione dell'app core ASP.NET

Successivamente, l'app ASP.NET Core deve essere configurata per abilitare il gestore di autenticazione che autentica gli utenti effettuando una richiesta HTTP all'app ASP.NET. Anche in questo caso, questa operazione viene eseguita chiamando AddAuthenticationClient quando si registrano i servizi di adapter System.Web:

builder.Services.AddSystemWebAdapters()
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration
            ["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true);

Il valore booleano passato alla AddAuthenticationClient chiamata specifica se l'autenticazione remota dell'app deve essere lo schema di autenticazione predefinito. true Il passaggio causerà l'autenticazione dell'utente tramite l'autenticazione remota dell'app per tutte le richieste, mentre il passaggio false significa che l'utente verrà autenticato solo con l'autenticazione remota dell'app se lo schema dell'app remota viene richiesto specificamente (con [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] su un controller o un metodo di azione, ad esempio). Il passaggio di false per questo parametro ha il vantaggio di effettuare solo richieste HTTP all'app di ASP.NET originale per l'autenticazione per gli endpoint che richiedono l'autenticazione remota dell'app, ma ha lo svantaggio di richiedere annotazioni a tutti questi endpoint per indicare che useranno l'autenticazione remota dell'app.

Oltre al valore booleano obbligatorio, è possibile passare un callback facoltativo a AddAuthenticationClient per modificare altri aspetti del comportamento del processo di autenticazione remota:

  • RequestHeadersToForward: questa proprietà contiene intestazioni che devono essere inoltrate da una richiesta quando si chiama l'API di autenticazione. Per impostazione predefinita, le uniche intestazioni inoltrate sono Authorization e Cookie. È possibile inoltrare intestazioni aggiuntive aggiungendole a questo elenco. In alternativa, se l'elenco viene cancellato (in modo che non siano specificate intestazioni), tutte le intestazioni verranno inoltrate.
  • ResponseHeadersToForward: questa proprietà elenca le intestazioni di risposta che devono essere propagate nuovamente dalla richiesta di autenticazione alla chiamata originale che ha richiesto l'autenticazione negli scenari in cui identity viene richiesta una richiesta di verifica. Per impostazione predefinita, sono incluse Locationle intestazioni , Set-Cookiee WWW-Authenticate .
  • AuthenticationEndpointPath: endpoint nell'app ASP.NET in cui devono essere effettuate le richieste di autenticazione. Questa impostazione predefinita è /systemweb-adapters/authenticate e deve corrispondere all'endpoint specificato nella configurazione dell'endpoint di autenticazione ASP.NET.

Infine, se l'app ASP.NET Core non includeva in precedenza il middleware di autenticazione, che dovrà essere abilitato (dopo il middleware di routing, ma prima del middleware di autorizzazione):

app.UseAuthentication();

Progettazione

  1. Quando le richieste vengono elaborate dall'app ASP.NET Core, se l'autenticazione remota dell'app è lo schema predefinito o specificato dall'endpoint della richiesta, tenterà RemoteAuthenticationAuthHandler di autenticare l'utente.
    1. Il gestore effettuerà una richiesta HTTP all'endpoint di autenticazione dell'app ASP.NET. Copierà le intestazioni configurate dalla richiesta corrente in questa nuova per inoltrare i dati rilevanti per l'autenticazione. Come accennato in precedenza, il comportamento predefinito consiste nel copiare le Authorize intestazioni e Cookie . L'intestazione della chiave API viene aggiunta anche a scopo di sicurezza.
  2. L'app ASP.NET gestisce le richieste inviate all'endpoint di autenticazione. Se le chiavi API corrispondono, l'app ASP.NET restituirà la serializzazione dell'utente corrente nel corpo della ClaimsPrincipal risposta oppure restituirà un codice di stato HTTP (ad esempio 401 o 302) e intestazioni di risposta che indicano un errore.
  3. Quando l'app RemoteAuthenticationAuthHandler ASP.NET Core riceve la risposta dall'app ASP.NET:
    1. Se è stato restituito correttamente un claimsPrincipal, il gestore di autenticazione lo deserializzerà e lo userà come oggetto dell'utente identitycorrente.
    2. Se un claimsPrincipal non è stato restituito correttamente, il gestore archivierà il risultato e se l'autenticazione viene richiesta (perché l'utente accede a una risorsa protetta, ad esempio), la risposta della richiesta verrà aggiornata con il codice di stato e le intestazioni di risposta selezionate dalla risposta dall'endpoint di autenticazione. Ciò consente la propagazione delle risposte di verifica (ad esempio i reindirizzamenti a una pagina di accesso) agli utenti finali.
      1. Poiché i risultati dell'endpoint di autenticazione dell'app ASP.NET possono includere dati specifici per tale endpoint, gli utenti possono registrare IRemoteAuthenticationResultProcessor implementazioni con l'app ASP.NET Core che verrà eseguita su tutti i risultati dell'autenticazione prima che vengano usati. Ad esempio, quello predefinito IRemoteAuthenticationResultProcessor è RedirectUrlProcessor che cerca Location le intestazioni di risposta restituite dall'endpoint di autenticazione e garantisce che vengano reindirizzate all'host dell'app ASP.NET Core e non direttamente all'app ASP.NET.

Limitazioni note

Questo approccio di autenticazione remota presenta due limitazioni note:

  1. Poiché autenticazione di Windows dipende da un handle di Windowsidentity, autenticazione di Windows non è supportato da questa funzionalità. Il lavoro futuro è pianificato per esplorare il funzionamento delle autenticazione di Windows condivise. Per altre informazioni, vedere dotnet/systemweb-adapters#246 .
  2. Questa funzionalità consente all'app ASP.NET Core di usare un'app identity autenticata dall'app ASP.NET, ma tutte le azioni correlate agli utenti (accesso, disconnessione e così via) devono comunque essere indirizzate attraverso l'app ASP.NET.

Alternative

Se l'autenticazione nell'app ASP.NET viene eseguita usando Microsoft.OwinCookie il middleware di autenticazione, un'alternativa alla condivisione identity consiste nel configurare le app ASP.NET e ASP.NET Core in modo che possano condividere un'autenticazione cookie. La condivisione di un'autenticazione cookie abilita:

  • Entrambe le app per determinare l'utente identity dallo stesso cookieoggetto .
  • L'accesso o l'uscita da un'app consente all'utente di accedere o uscire dall'altra app.

Si noti che poiché l'accesso dipende in genere da un database specifico, non tutte le funzionalità di autenticazione funzioneranno in entrambe le app:

  • Gli utenti devono eseguire l'accesso solo tramite una delle app, ovvero l'app ASP.NET o ASP.NET Core, indipendentemente dal fatto che il database sia configurato per funzionare.
  • Entrambe le app sono in grado di visualizzare le attestazioni e gli utenti identity .
  • Entrambe le app sono in grado di disconnettere l'utente.

Informazioni dettagliate su come configurare la condivisione dei cookie di autenticazione tra ASP.NET e ASP.NET App Core sono disponibili nella cookie documentazione sulla condivisione. Gli esempi seguenti nel repository GitHub System.Web adapters illustrano l'autenticazione remota delle app con configurazione condivisa cookie che consente a entrambe le app di accedere e disconnettere gli utenti:

L'autenticazione di condivisione è un'opzione valida se sono soddisfatte entrambe le condizioni seguenti:

  • L'app ASP.NET usa Microsoft.Owincookie già l'autenticazione.
  • È possibile aggiornare l'app ASP.NET e le app core ASP.NET per usare le impostazioni di protezione dei dati corrispondenti. Le impostazioni di protezione dei dati condivise corrispondenti includono un percorso di file condiviso, una cache Redis o un Archiviazione BLOB di Azure per l'archiviazione delle chiavi di protezione dei dati.

Per altri scenari, l'approccio di autenticazione remota descritto in precedenza in questo documento è più flessibile ed è probabilmente più adatto.