Authentification à distance

Article
11/30/2023

La fonctionnalité d’authentification à distance des adaptateurs System.Web permet à une application ASP.NET Core de déterminer l’identité d’un utilisateur (authentifier une requête HTTP) en s’en remettant à une application ASP.NET. L’activation de la fonctionnalité ajoute un point de terminaison à l’application ASP.NET qui retourne un ClaimsPrincipal sérialisé représentant l’utilisateur authentifié pour toutes les requêtes adressées au point de terminaison. L’application ASP.NET Core inscrit alors un gestionnaire d’authentification personnalisé qui (pour les points de terminaison avec l’authentification à distance activée) détermine l’identité d’un utilisateur en appelant ce point de terminaison sur l’application ASP.NET, puis en transmettant les en-têtes et les cookies sélectionnés depuis la requête d’origine reçue par l’application ASP.NET Core.

Configuration

Seules quelques petites modifications de code sont nécessaires pour activer l’authentification à distance dans une solution déjà configurée en fonction des instructions du chapitre Prise en main.

Commencez par suivre les instructions de configuration d’application distante pour connecter les applications ASP.NET Core et ASP.NET. Il ne reste ensuite que quelques méthodes d’extension supplémentaires à appeler pour activer l’authentification d’applications à distance.

Configuration de l’application ASP.NET

Il faut configurer l’application ASP.NET pour ajouter le point de terminaison d’authentification. L’ajout du point de terminaison d’authentification est effectué en appelant la méthode d’extension AddAuthenticationServer pour configurer le module HTTP qui surveille les requêtes adressées au point de terminaison d’authentification. Veuillez noter que les scénarios d’authentification à distance nécessitent généralement également l’ajout du support de proxy pour que toutes les redirections liées à l’authentification soient correctement acheminées vers l’application ASP.NET Core plutôt que vers l’application ASP.NET.

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

Configuration de l’application ASP.NET Core

Ensuite, l’application ASP.NET Core doit être configurée pour activer le gestionnaire d’authentification qui authentifiera les utilisateurs en adressant une requête HTTP à l’application ASP.NET. Là encore, pour ce faire, appelez AddAuthenticationClient lors de l’inscription des services d’adaptateurs 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);

L’expression booléenne transmise à l’appel AddAuthenticationClient spécifie si l’authentification d’application distante doit être le schéma d’authentification par défaut. La transmission de true entraîne l’authentification de l’utilisateur via l’authentification d’application distante pour toutes les requêtes, tandis que la transmission de false signifie que l’utilisateur ne sera authentifié avec l’authentification d’application distante que si le schéma d’application distante est spécifiquement demandé (avec [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] sur un contrôleur ou une méthode d’action, par exemple). La transmission de false pour ce paramètre offre l’avantage d’adresser uniquement des requêtes HTTP à l’application ASP.NET d’origine pour l’authentification des points de terminaison qui nécessitent une authentification d’application distante, mais présente l’inconvénient d’exiger l’annotation de tous ces points de terminaison pour indiquer qu’ils utiliseront l’authentification d’application distante.

En plus de l’expression booléenne obligatoire, un rappel facultatif peut être transmis à AddAuthenticationClient pour modifier certains autres aspects du comportement du processus d’authentification à distance :

RequestHeadersToForward : cette propriété contient des en-têtes qui doivent être transférés depuis une requête lors de l’appel de l’API d’authentification. Par défaut, les seuls en-têtes transférés sont Authorization et Cookie. Vous pouvez transférer des en-têtes supplémentaires en les ajoutant à cette liste. Sinon, si la liste est effacée (de sorte qu’aucun en-tête n’est spécifié), tous les en-têtes sont transférés.
ResponseHeadersToForward : cette propriété répertorie les en-têtes de réponse qui doivent être propagés de la requête d’authentification à l’appel d’origine qui a demandé l’authentification dans les scénarios où l’identité est remise en question. Par défaut, cela inclut les en-têtes Location, Set-Cookie et WWW-Authenticate.
AuthenticationEndpointPath : point de terminaison sur l’application ASP.NET où les demandes d’authentification doivent être effectuées. Ce point de terminaison prend la valeur /systemweb-adapters/authenticate par défaut et doit correspondre au point de terminaison spécifié dans la configuration de point de terminaison d’authentification ASP.NET.

Enfin, si l’application ASP.NET Core n’incluait pas d’intergiciel d’authentification auparavant, vous devrez activer l’intergiciel (après l’intergiciel de routage, mais avant l’intergiciel d’autorisation) :

app.UseAuthentication();

Création

Lorsque l’application ASP.NET Core traite les requêtes, si l’authentification d’application distante est le schéma par défaut ou est spécifiée par le point de terminaison de la requête, le RemoteAuthenticationAuthHandler tente d’authentifier l’utilisateur.
1. Le gestionnaire adresse une requête HTTP au point de terminaison d’authentification de l’application ASP.NET. Il copie les en-têtes configurés de la requête actuelle sur cette nouvelle requête pour transférer les données pertinentes pour l’authentification. Comme mentionné ci-dessus, le comportement par défaut consiste à copier les en-têtes Authorize et Cookie. L’en-tête de clé API est également ajouté à des fins de sécurité.
L’application ASP.NET traite les requêtes envoyées au point de terminaison d’authentification. Tant que les clés API correspondent, l’application ASP.NET renvoie soit le ClaimsPrincipal sérialisé de l’utilisateur actuel dans le corps la réponse, soit un code d’état HTTP (comme 401 ou 302) et des en-têtes de réponse indiquant une défaillance.
Lorsque le RemoteAuthenticationAuthHandler de l’application ASP.NET Core reçoit la réponse de l’application ASP.NET :
1. Si un ClaimsPrincipal a été renvoyé avec succès, le gestionnaire d’authentification le désérialise, puis l’utilise comme identité de l’utilisateur actuel.
2. Si un ClaimsPrincipal n’a pas été renvoyé avec succès, le gestionnaire stocke le résultat, puis, si l’authentification est contestée (parce que l’utilisateur accède à une ressource protégée, par exemple), la réponse de la requête est mise à jour avec le code d’état et les en-têtes de réponse sélectionnés depuis la réponse du point de terminaison d’authentification. Cela permet de propager les réponses à la contestation (comme les redirections vers une page de connexion) aux utilisateurs finaux.
  1. Puisque les résultats du point de terminaison d’authentification de l’application ASP.NET peuvent inclure des données spécifiques à ce point de terminaison, les utilisateurs peuvent inscrire des implémentations IRemoteAuthenticationResultProcessor auprès de l’application ASP.NET Core qui s’exécutera sur tous les résultats d’authentification leur utilisation. Par exemple, le seul IRemoteAuthenticationResultProcessor intégré est RedirectUrlProcessor qui recherche les en-têtes de réponse Location renvoyés depuis le point de terminaison d’authentification, puis garantit leur renvoi à l’hôte de l’application ASP.NET Core, et non à l’application ASP.NET directement.

Limitations connues

Cette approche d’authentification à distance présente deux limitations connues :

Puisque l’Authentification Windows dépend d’un descripteur d’identité Windows, cette fonctionnalité ne la prend pas en charge. Des travaux futurs sont prévus pour explorer le fonctionnement de l’Authentification Windows partagée. Si vous souhaitez en savoir plus, veuillez consulter la rubrique dotnet/systemweb-adapters#246.
Cette fonctionnalité permet à l’application ASP.NET Core d’utiliser une identité authentifiée par l’application ASP.NET, mais toutes les actions liées aux utilisateurs (connexion, déconnexion, et bien plus encore) doivent toujours être acheminées via l’application ASP.NET.

Alternatives

Si l’authentification dans l’application ASP.NET est effectuée à l’aide de l’intergiciel d’authentification Microsoft.OwinCookie, une solution de substitution au partage d’identité consiste à configurer les applications ASP.NET et ASP.NET Core pour qu’elles puissent partager un cookie d’authentification. Le partage d’un cookie d’authentification permet :

Aux deux applications de déterminer l’identité de l’utilisateur depuis le même cookie.
La connexion à une application ou la déconnexion d’une application connecte l’utilisateur à l’autre application ou l’en déconnecte.

Veuillez noter que, puisque la connexion dépend généralement d’une base de données spécifique, les fonctionnalités d’authentification ne fonctionnent pas toutes dans les deux applications :

Les utilisateurs ne doivent se connecter que via une seule des applications, ASP.NET ou ASP.NET Core, suivant celle avec laquelle la base de données est configurée pour fonctionner.
Les deux applications peuvent voir l’identité et les revendications des utilisateurs.
Les deux applications peuvent déconnecter l’utilisateur.

Si vous souhaitez en savoir plus sur la configuration du partage de cookies d’authentification entre les applications ASP.NET et ASP.NET Core, veuillez consulter la documentation sur le partage de cookies. Les exemples suivants dans le référentiel GitHub des adaptateurs System.Web illustrent l’authentification des applications distantes avec une configuration de cookie partagé, configuration permettant aux deux applications de connecter, puis de déconnecter des utilisateurs :

Le partage de l’authentification est une bonne option si les deux conditions suivantes sont remplies :

L’application ASP.NET utilise déjà l’authentification de cookieMicrosoft.Owin.
Il est possible de mettre à jour les applications ASP.NET et ASP.NET Core pour utiliser la mise en correspondance des paramètres de protection des données. La mise en correspondance des paramètres de protection des données partagées incluent un chemin d’accès aux fichiers partagés, un cache Redis ou un Stockage Blob Azure pour stocker des clés de protection des données.

Pour d’autres scénarios, l’approche d’authentification à distance décrite précédemment dans ce document est plus flexible et probablement mieux adaptée.