Partager des cookies d’authentification entre des applications ASP.NET

Par Rick Anderson

Les sites Web sont souvent constitués d’applications Web individuelles qui fonctionnent ensemble. Pour offrir une expérience d’authentification unique (SSO), les applications Web d’un site doivent partager des cookies d’authentification. Pour prendre en charge ce scénario, la pile de protection des données permet de partager les tickets d’authentification Katana cookie et ASP.NET Core cookie.

Dans les exemples qui suivent :

Le nom d’authentification cookie est défini sur une valeur commune, .AspNet.SharedCookie.
AuthenticationType est défini sur Identity.Application de manière explicite ou par défaut.
Un nom d’application commun, SharedCookieApp, est utilisé pour permettre au système de protection des données de partager les clés de protection des données.
Identity.Application est utilisé comme schéma d’authentification. Quel que soit le schéma utilisé, il doit être utilisé de manière cohérente au sein des applications cookie, soit comme schéma par défaut, soit en le définissant explicitement. Le schéma est utilisé lors du chiffrement et du déchiffrement des cookies. Il est donc important d’utiliser un schéma cohérent dans toutes les applications.
Un emplacement de stockage de clé de protection des données commun est utilisé.
- Dans les applications ASP.NET Core, PersistKeysToFileSystem est utilisé pour définir l’emplacement de stockage de la clé.
- Dans les applications .NET Framework, le middleware d’authentification Cookie utilise une implémentation de DataProtectionProvider. DataProtectionProviderfournit des services de protection des données pour le chiffrement et le déchiffrement des données de charge utile d’authentification cookie. L’instance DataProtectionProvider est isolée du système de protection des données utilisé par d’autres parties de l’application. DataProtectionProvider.Create(System.IO.DirectoryInfo, ActionI<DataProtectionBuilder>) accepte un DirectoryInfo pour spécifier l’emplacement de stockage de la clé de protection des données.
DataProtectionProvidernécessite le package NuGet Microsoft.AspNetCore.DataProtection.Extensions :
- Dans les applications .NET Framework, ajoutez une référence de package à Microsoft.AspNetCore.DataProtection.Extensions.
SetApplicationNamedéfinit le nom commun de l’application.

Lorsque vous utilisez ASP.NET Core Identity :

Les clés de protection des données et le nom de l’application doivent être partagés entre les applications. Un emplacement de stockage de clés commun est fourni à la méthode PersistKeysToFileSystem dans les exemples suivants. Utilisez SetApplicationName pour configurer un nom d’application partagé commun (SharedCookieApp dans les exemples suivants). Pour plus d’informations, consultez Configurer la protection des données ASP.NET Core.
Utilisez la méthode d’extension ConfigureApplicationCookie pour configurer le service de protection des données pour les cookies.
Le type d’authentification par défaut est Identity.Application.

Dans Program.cs :

using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"c:\PATH TO COMMON KEY RING FOLDER"))
    .SetApplicationName("SharedCookieApp");

builder.Services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
});

var app = builder.Build();

Remarque : les instructions précédentes ne fonctionnent pas avec ITicketStore (CookieAuthenticationOptions.SessionStore). Pour plus d’informations, consultez ce problème GitHub.

Pour des raisons de sécurité, les cookies d’authentification ne sont pas compressés dans ASP.NET Core. Lorsqu’ils utilisent des cookies d’authentification, les développeurs doivent réduire au minimum le nombre d’informations de revendication incluses pour se limiter à celles qui sont nécessaires à leurs besoins.

Lorsque vous utilisez des cookies directement sans ASP.NET Core Identity, configurez la protection des données et l’authentification. Dans l’exemple suivant, le type d’authentification est défini sur Identity.Application :

using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"c:\PATH TO COMMON KEY RING FOLDER"))
    .SetApplicationName("SharedCookieApp");

builder.Services.AddAuthentication("Identity.Application")
    .AddCookie("Identity.Application", options =>
    {
        options.Cookie.Name = ".AspNet.SharedCookie";
    });

var app = builder.Build();

Une authentification cookie utilise HttpRequest.PathBase comme Cookie.Path par défaut. Si le cookie de l’application doit être partagée entre différents chemins de base, Path doit être remplacé :

using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"c:\PATH TO COMMON KEY RING FOLDER"))
    .SetApplicationName("SharedCookieApp");

builder.Services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
    options.Cookie.Path = "/";
});

var app = builder.Build();

Lorsque vous hébergez des applications qui partagent des cookies entre sous-domaines, spécifiez un domaine commun dans la propriété Cookie.Domain. Pour partager des cookies entre des applications au niveau de contoso.com, telles que first_subdomain.contoso.com et second_subdomain.contoso.com, spécifiez Cookie.Domain comme .contoso.com :

options.Cookie.Domain = ".contoso.com";

Chiffrer les clés de protection des données au repos

Pour les déploiements de production, configurez le DataProtectionProvider pour chiffrer les clés au repos avec DPAPI ou un X509Certificate. Pour plus d’informations, veuillez consulter la section Chiffrement des clés au repos dans Windows et Azure en utilisant ASP.NET Core. Dans l’exemple suivant, une empreinte digitale de certificat est fournie à ProtectKeysWithCertificate :

using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddDataProtection()
    .ProtectKeysWithCertificate("{CERTIFICATE THUMBPRINT}");

Utiliser une base de données utilisateur commune

Lorsque les applications utilisent le même schéma Identity (même version de Identity), vérifiez que le système Identity de chaque application pointe vers la même base de données utilisateur. Sinon, le système d’identité génère des échecs lors de l’exécution lorsqu’il tente de faire correspondre les informations de l’authentification cookie par rapport aux informations de sa base de données.

Lorsque le schéma Identity est différent entre les applications, généralement parce que les applications utilisent des versions Identity différentes, le partage d’une base de données commune basée sur la dernière version de Identity n’est pas possible sans remapper et ajouter des colonnes dans les schémas Identity des autres applications. Il est souvent plus efficace de mettre à niveau les autres applications afin qu’elles utilisent la dernière version Identity, de manière à ce qu’une base de données commune puisse être partagée par les applications.

Changement de nom de l’application

Dans .NET 6, WebApplicationBuilder normalise le chemin racine du contenu pour qu’il se termine par un DirectorySeparatorChar. La plupart des applications migrées depuis HostBuilder ou WebHostBuilder n’auront pas le même nom d’application, car elles ne sont pas normalisées. Si vous souhaitez en savoir plus, veuillez consulter la rubrique SetApplicationName.

Les applications ASP.NET 4.x qui utilisent le middleware d’authentification Cookie Microsoft.Owin peuvent être configurées pour générer des cookies d’authentification compatibles avec le middleware d’authentification Cookie ASP.NET Core. Cela peut être utile si une application Web se compose à la fois d’applications ASP.NET 4.x et d’applications ASP.NET Core qui doivent partager une expérience d’authentification unique. Un exemple spécifique d’un tel scénario est la migration progressive d’une application Web de ASP.NET vers ASP.NET Core. Dans de tels scénarios, il est courant que certaines parties d’une application soient fournies par l’application ASP.NET d’origine, tandis que d’autres sont fournies par la nouvelle application ASP.NET Core. Les utilisateurs ne doivent toutefois se connecter qu’une seule fois. Pour ce faire, vous pouvez utiliser l’une des approches suivantes :

Utilisation de la fonctionnalité d’authentification à distance des adaptateurs System.Web, qui utilise l’application ASP.NET pour connecter les utilisateurs.
Configuration de l’application ASP.NET pour utiliser le middleware d’authentification Microsoft.Owin Cookie afin que les cookies d’authentification soient partagés avec l’application ASP.NET Core.

Pour configurer le middleware d’authentification ASP.NET Microsoft.Owin Cookie afin qu’il partage les cookies avec une application ASP.NET Core, suivez les instructions précédentes pour configurer l’application ASP.NET Core afin qu’elle utilise un nom cookie et un nom d’application spécifiques, et pour conserver les clés de protection des données dans un emplacement connu. Pour plus d’informations sur la conservation des clés de protection des données, consultez la rubrique Configurer la protection des données ASP.NET Core.

Dans l’application ASP.NET, installez le package Microsoft.Owin.Security.Interop.

Mettez à jour l’appel UseCookieAuthentication dans Startup.Auth.cs pour configurer un AspNetTicketDataFormat correspondant aux paramètres de l’application ASP.NET Core :

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    { 
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    },

    // Settings to configure shared cookie with ASP.NET Core app
    CookieName = ".AspNet.ApplicationCookie",
    AuthenticationType = "Identity.Application",                
    TicketDataFormat = new AspNetTicketDataFormat(
        new DataProtectorShim(
            DataProtectionProvider.Create(new DirectoryInfo(@"c:\PATH TO COMMON KEY RING FOLDER"),
            builder => builder.SetApplicationName("SharedCookieApp"))
            .CreateProtector(
                "Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationMiddleware",
                // Must match the Scheme name used in the ASP.NET Core app, i.e. IdentityConstants.ApplicationScheme
                "Identity.Application",
                "v2"))),
    CookieManager = new ChunkingCookieManager()
});

Les éléments importants configurés ici sont les suivants :

Le nom cookie est défini sur le même nom que dans l’application ASP.NET Core.
Un fournisseur de protection des données est créé à l’aide du même chemin d’accès au trousseau de clés. Notez que dans ces exemples, les clés de protection des données sont stockées sur le disque, mais d’autres fournisseurs de protection des données peuvent être utilisés. Par exemple, Redis ou Azure Blob Storage peuvent être utilisés comme fournisseurs de protection des données, à condition que la configuration corresponde entre les applications. Pour plus d’informations sur la conservation des clés de protection des données, consultez la rubrique Configurer la protection des données ASP.NET Core.
Le nom de l’application est défini sur le même nom que celui utilisé dans l’application ASP.NET Core.
Le type d’authentification est défini sur le nom du schéma d’authentification dans l’application ASP.NET Core.
System.Web.Helpers.AntiForgeryConfig.UniqueClaimTypeIdentifier est défini sur une revendication de l’identité ASP.NET Core qui sera unique à un utilisateur.

Comme le type d’authentification a été modifié pour correspondre au schéma d’authentification de l’application ASP.NET Core, il est également nécessaire de mettre à jour la manière dont l’application ASP.NET génère de nouvelles identités afin d’utiliser le même nom. Cela se fait généralement dans Models/IdentityModels.cs :

public class ApplicationUser : IdentityUser
{
    public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager)
    {
        // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
        var userIdentity = await manager.CreateIdentityAsync(this, "Identity.Application");
        
        // Add custom user claims here
        return userIdentity;
    }
}

Grâce à ces modifications, les applications ASP.NET et ASP.NET Core peuvent utiliser les mêmes cookies d’authentification, de sorte que les utilisateurs qui se connectent ou se déconnectent d’une application sont pris en compte dans l’autre application.

Veuillez noter qu’en raison des différences entre les schémas de base de données ASP.NET Identity et ASP.NET CoreIdentity, il est recommandé aux utilisateurs de se connecter uniquement à l’une des applications, soit l’application ASP.NET, soit l’application ASP.NET Core. Une fois les utilisateurs connectés, les étapes décrites dans cette section permettent à l’authentification cookie d’être utilisée par l’une ou l’autre des applications, et les deux applications devraient pouvoir déconnecter les utilisateurs.

Ressources supplémentaires

Dans les exemples qui suivent :

Le nom d’authentification cookie est défini sur une valeur commune, .AspNet.SharedCookie.
AuthenticationType est défini sur Identity.Application de manière explicite ou par défaut.
Un nom d’application commun est utilisé pour permettre au système de protection des données de partager les clés de protection des données (SharedCookieApp).
Identity.Application est utilisé comme schéma d’authentification. Quel que soit le schéma utilisé, il doit être utilisé de manière cohérente au sein des applications cookie, soit comme schéma par défaut, soit en le définissant explicitement. Le schéma est utilisé lors du chiffrement et du déchiffrement des cookies. Il est donc important d’utiliser un schéma cohérent dans toutes les applications.
Un emplacement de stockage de clé de protection des données commun est utilisé.
- Dans les applications ASP.NET Core, PersistKeysToFileSystem est utilisé pour définir l’emplacement de stockage de la clé.
- Dans les applications .NET Framework, le middleware d’authentification Cookie utilise une implémentation de DataProtectionProvider. DataProtectionProviderfournit des services de protection des données pour le chiffrement et le déchiffrement des données de charge utile d’authentification cookie. L’instance DataProtectionProvider est isolée du système de protection des données utilisé par d’autres parties de l’application. DataProtectionProvider.Create(System.IO.DirectoryInfo, ActionI<DataProtectionBuilder>) accepte un DirectoryInfo pour spécifier l’emplacement de stockage de la clé de protection des données.
DataProtectionProvidernécessite le package NuGet Microsoft.AspNetCore.DataProtection.Extensions :
- Dans les applications ASP.NET Core 2.x, référencez le méta-package Microsoft.AspNetCore.App.
- Dans les applications .NET Framework, ajoutez une référence de package à Microsoft.AspNetCore.DataProtection.Extensions.
SetApplicationNamedéfinit le nom commun de l’application.

Lorsque vous utilisez ASP.NET Core Identity :

Les clés de protection des données et le nom de l’application doivent être partagés entre les applications. Un emplacement de stockage de clés commun est fourni à la méthode PersistKeysToFileSystem dans les exemples suivants. Utilisez SetApplicationName pour configurer un nom d’application partagé commun (SharedCookieApp dans les exemples suivants). Pour plus d’informations, consultez Configurer la protection des données ASP.NET Core.
Utilisez la méthode d’extension ConfigureApplicationCookie pour configurer le service de protection des données pour les cookies.
Le type d’authentification par défaut est Identity.Application.

Dans Startup.ConfigureServices :

services.AddDataProtection()
    .PersistKeysToFileSystem("{PATH TO COMMON KEY RING FOLDER}")
    .SetApplicationName("SharedCookieApp");

services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
});

Remarque : les instructions précédentes ne fonctionnent pas avec ITicketStore (CookieAuthenticationOptions.SessionStore). Pour plus d’informations, consultez ce problème GitHub.

Lorsque vous utilisez directement des cookies sans ASP.NET Core Identity, configurez la protection des données et l’authentification dans Startup.ConfigureServices. Dans l’exemple suivant, le type d’authentification est défini sur Identity.Application :

services.AddDataProtection()
    .PersistKeysToFileSystem("{PATH TO COMMON KEY RING FOLDER}")
    .SetApplicationName("SharedCookieApp");

services.AddAuthentication("Identity.Application")
    .AddCookie("Identity.Application", options =>
    {
        options.Cookie.Name = ".AspNet.SharedCookie";
    });

services.AddDataProtection()
    .PersistKeysToFileSystem("{PATH TO COMMON KEY RING FOLDER}")
    .SetApplicationName("SharedCookieApp");

services.ConfigureApplicationCookie(options => {
    options.Cookie.Name = ".AspNet.SharedCookie";
    options.Cookie.Path = "/";
});

options.Cookie.Domain = ".contoso.com";

Chiffrer les clés de protection des données au repos

services.AddDataProtection()
    .ProtectKeysWithCertificate("{CERTIFICATE THUMBPRINT}");

Les applications ASP.NET 4.x qui utilisent le middleware d’authentification Katana Cookie peuvent être configurées pour générer des cookies d’authentification compatibles avec le middleware d’authentification ASP.NET Core Cookie. Pour plus d’informations, consultez Partager des cookies d’authentification entre des applications ASP.NET 4.x et ASP.NET Core (dotnet/AspNetCore.Docs #21987).

Partager des cookies d’authentification entre des applications ASP.NET

Partager les cookies d’authentification avec ASP.NET Core Identity

Partager des cookies d’authentification sans ASP.NET Core Identity

Partager des cookies entre différents chemins de base

Partager les cookies entre sous-domaines

Chiffrer les clés de protection des données au repos

Utiliser une base de données utilisateur commune

Changement de nom de l’application

Partager les cookies d’authentification entre les applications ASP.NET 4.x et ASP.NET Core

Ressources supplémentaires

Partager les cookies d’authentification avec ASP.NET Core Identity

Partager des cookies d’authentification sans ASP.NET Core Identity

Partager des cookies entre différents chemins de base

Partager les cookies entre sous-domaines

Chiffrer les clés de protection des données au repos

Partager les cookies d’authentification entre les applications ASP.NET 4.x et ASP.NET Core

Utiliser une base de données utilisateur commune

Ressources supplémentaires

Commentaires

Ressources supplémentaires