Partager via

Présentation de ASP.NET Identity

  • Article

Le système d’appartenance ASP.NET a été introduit avec ASP.NET 2.0 en 2005, et depuis lors, il y a eu de nombreuses modifications dans les façons dont les applications web gèrent généralement l’authentification et l’autorisation. ASP.NET Identity est un aperçu de ce que doit être le système d’appartenance lorsque vous créez des applications modernes pour le web, le téléphone ou la tablette.

Nous vous recommandons d’utiliser l’option d’authentification sécurisée la plus sécurisée. Pour les applications .NET déployées sur Azure, consultez :

Azure Key Vault et .NET Aspire offrent le moyen le plus sécurisé de stocker et de récupérer des secrets. Azure Key Vault est un service cloud qui protège les clés de chiffrement et les secrets tels que les certificats, les chaînes de connexion et les mots de passe. Pour .NET Aspire, consultez Communication sécurisée entre l’hébergement et les intégrations clientes.

Évitez le Resource Owner Password Credentials Grant car il :

  • Expose le mot de passe de l’utilisateur au client.
  • Est un risque de sécurité important.
  • Doit être utilisé uniquement lorsque d’autres flux d’authentification ne sont pas possibles.

Lorsque l’application est déployée sur un serveur de test, une variable d’environnement peut être utilisée pour définir la chaîne de connexion sur un serveur de base de données de test. Les variables d’environnement sont généralement stockées en texte brut et non chiffré. Si l’ordinateur ou le processus est compromis, les variables d’environnement sont accessibles par des parties non approuvées. Nous vous déconseillons d'utiliser des variables d'environnement pour stocker une chaîne de connexion de production, car ce n’est pas l’approche la plus sécurisée.

Recommandations en matière de données de configuration :

  • Ne stockez jamais de mots de passe ou d’autres données sensibles dans le code du fournisseur de configuration ou dans des fichiers de configuration en texte brut.
  • N’utilisez pas de secrets de production dans des environnements de développement ou de test.
  • Spécifiez des secrets en dehors du projet afin qu’ils ne puissent pas être validés accidentellement dans un référentiel de code source.

Contexte : Appartenance à ASP.NET

appartenance à ASP.NET

ASP.NET Membership a été conçu pour résoudre les exigences de gestion des membres des sites en 2005, qui impliquaient l'authentification par formulaire et une base de données SQL Server pour les noms d'utilisateur, les mots de passe et les données de profil. Aujourd’hui, il existe un large éventail d’options de stockage de données pour les applications web, et la plupart des développeurs souhaitent permettre à leurs sites d’utiliser des fournisseurs d’identité sociale pour les fonctionnalités d’authentification et d’autorisation. Les limitations de la conception d’ASP.NET Membership rendent cette transition difficile :

  • Le schéma de base de données a été conçu pour SQL Server et vous ne pouvez pas le modifier. Vous pouvez ajouter des informations de profil, mais les données supplémentaires sont regroupées dans une autre table, ce qui rend difficile l’accès par n’importe quel moyen, sauf par le biais de l’API fournisseur de profils.
  • Le système du fournisseur vous permet de modifier le magasin de données sous-jacent, mais il est conçu sur la base d’hypothèses adaptées à une base de données relationnelle. Vous pouvez écrire un fournisseur pour stocker des informations d’appartenance dans un mécanisme de stockage non relationnel, comme les tables de stockage Azure, mais vous devez ensuite contourner la conception relationnelle en écrivant beaucoup de code et beaucoup d’exceptions System.NotImplementedException pour les méthodes qui ne s’appliquent pas aux bases de données NoSQL.
  • Étant donné que la fonctionnalité de connexion/déconnexion est basée sur l’authentification par formulaire, le système d’appartenance ne peut pas utiliser OWIN . OWIN inclut des composants middleware pour l’authentification, notamment la prise en charge des connexions à l’aide de fournisseurs d’identité externes (tels que les comptes Microsoft, Facebook, Google, Twitter) et les connexions à l’aide de comptes organisationnels à partir d’Active Directory local ou d’Azure Active Directory. OWIN inclut également la prise en charge d’OAuth 2.0, JWT et CORS.

ASP.NET Simple Membership

ASP.NET simple membership a été développé comme système d’adhésion pour ASP.NET Web Pages. Il a été publié avec WebMatrix et Visual Studio 2010 SP1. L’objectif de l’appartenance simple était de faciliter l’ajout de fonctionnalités d’appartenance à une application Pages web.

L’appartenance simple a facilité la personnalisation des informations de profil utilisateur, mais elle partage toujours les autres problèmes liés à l’appartenance à ASP.NET et présente certaines limitations :

  • Il était difficile de conserver les données du système d’appartenance dans un magasin non relationnel.
  • Vous ne pouvez pas l’utiliser avec OWIN.
  • Il ne fonctionne pas correctement avec les fournisseurs d’appartenance ASP.NET existants, et il n’est pas extensible.

fournisseurs universels ASP.NET

ASP.NET fournisseurs universels ont été développés pour rendre possible la persistance des informations d’appartenance dans Microsoft Azure SQL Database, et ils fonctionnent également avec SQL Server Compact. Les fournisseurs universels ont été créés sur Entity Framework Code First, ce qui signifie que les fournisseurs universels peuvent être utilisés pour conserver des données dans n’importe quel magasin pris en charge par EF. Avec les fournisseurs universels, le schéma de base de données a également été beaucoup nettoyé.

Les fournisseurs universels sont basés sur l’infrastructure d’appartenance ASP.NET, de sorte qu’ils présentent toujours les mêmes limitations que le fournisseur SqlMembership. Autrement dit, ils ont été conçus pour les bases de données relationnelles et il est difficile de personnaliser les informations de profil et d’utilisateur. Ces fournisseurs utilisent également l’authentification par formulaire pour la connexion et la fonctionnalité de déconnexion.

ASP.NET Identity

Comme l’histoire de l’appartenance à ASP.NET a évolué au fil des années, l’équipe ASP.NET a beaucoup appris des commentaires des clients.

L’hypothèse que les utilisateurs se connectent en entrant un nom d’utilisateur et un mot de passe qu’ils ont inscrits dans votre propre application n’est plus valide. Le web est devenu plus social. Les utilisateurs interagissent entre eux en temps réel via des canaux sociaux tels que Facebook, Twitter et d’autres sites web sociaux. Les développeurs veulent que les utilisateurs puissent se connecter avec leurs identités sociales afin qu’ils puissent avoir une expérience riche sur leurs sites web. Un système d’appartenance moderne doit activer les connexions basées sur la redirection vers des fournisseurs d’authentification tels que Facebook, Twitter et d’autres.

Au fur et à mesure que le développement web évoluait, les modèles de développement web évoluaient également. Le test unitaire du code d’application est devenu une préoccupation essentielle pour les développeurs d’applications. En 2008, ASP.NET a ajouté une nouvelle infrastructure basée sur le modèleView-Controller (MVC), en partie pour aider les développeurs à créer des applications ASP.NET testables par unités. Les développeurs qui souhaitaient tester unitairement leur logique d’application voulaient également pouvoir le faire avec le système d’appartenance.

Compte tenu de ces changements dans le développement d’applications web, ASP.NET Identity a été développé avec les objectifs suivants :

  • Système d'identité One ASP.NET

    • ASP.NET Identity peut être utilisée avec toutes les infrastructures de ASP.NET, telles que ASP.NET MVC, Web Forms, Web Pages, API Web et SignalR.
    • ASP.NET Identity peut être utilisé lorsque vous créez des applications web, téléphoniques, de magasin ou hybrides.

  • Facilité de connexion des données de profil sur l’utilisateur

    • Vous avez le contrôle sur le schéma des informations utilisateur et de profil. Par exemple, vous pouvez facilement autoriser le système à stocker les dates de naissance entrées par les utilisateurs lorsqu’ils inscrivent un compte dans votre application.

  • Contrôle de persistance

    • Par défaut, le système ASP.NET Identity stocke toutes les informations utilisateur dans une base de données. ASP.NET Identity utilise Entity Framework Code First pour implémenter tout son mécanisme de persistance.
    • Étant donné que vous contrôlez le schéma de base de données, les tâches courantes telles que la modification des noms de tables ou la modification du type de données des clés primaires sont simples à effectuer.
    • Il est facile de brancher différents mécanismes de stockage tels que SharePoint, Azure Storage Table Service, les bases de données NoSQL, etc., sans avoir à générer d'exceptions System.NotImplementedExceptions.

  • Testabilité unitaire

    • ASP.NET Identity permet de tester l'application web plus facilement par unités. Vous pouvez écrire des tests unitaires pour les parties de votre application qui utilisent ASP.NET Identity.

  • Fournisseur de rôles

    • Il existe un fournisseur de rôles qui vous permet de restreindre l’accès aux parties de votre application par rôles. Vous pouvez facilement créer des rôles tels que « Administrateur » et ajouter des utilisateurs à des rôles.

  • Basé sur les revendications

    • ASP.NET Identity prend en charge l’authentification basée sur les revendications, où l’identité de l’utilisateur est représentée sous la forme d’un ensemble de revendications. Les revendications permettent aux développeurs d'être bien plus expressifs lorsqu'ils décrivent l'identité d'un utilisateur que ne le permettent les rôles. Alors que l’appartenance au rôle n’est qu’une valeur booléenne (membre ou non membre), une revendication peut inclure des informations complètes sur l’identité et l’appartenance de l’utilisateur.

  • Fournisseurs de Connexion Sociale

    • Vous pouvez facilement ajouter des connexions sociales telles que le compte Microsoft, Facebook, Twitter, Google et d’autres personnes à votre application, et stocker les données spécifiques à l’utilisateur dans votre application.

  • Intégration OWIN

    • L'authentification ASP.NET est désormais basée sur le middleware OWIN, qui peut être utilisé sur n’importe quel hôte basé sur OWIN. ASP.NET Identity n’a aucune dépendance sur System.Web. Il s’agit d’une infrastructure OWIN entièrement conforme et peut être utilisée dans n’importe quelle application hébergée par OWIN.
    • ASP.NET Identity utilise l’authentification OWIN pour la connexion/déconnexion des utilisateurs du site web. Cela signifie qu’au lieu d’utiliser FormsAuthentication pour générer le cookie, l’application utilise OWIN CookieAuthentication pour le faire.

  • Package NuGet

    • ASP.NET Identity est redistribuée sous la forme d’un package NuGet installé dans les modèles DVC, Web Forms et API web ASP.NET fournis avec Visual Studio 2017. Vous pouvez télécharger ce package NuGet à partir de la galerie NuGet.
    • La publication de ASP.NET Identity en tant que package NuGet facilite l’itération de l’équipe ASP.NET sur les nouvelles fonctionnalités et les correctifs de bogues, et de les fournir aux développeurs de manière agile.

Bien démarrer avec ASP.NET Identity

ASP.NET Identity est utilisé dans les modèles de projet Visual Studio 2017 pour ASP.NET MVC, Web Forms, API web et SPA. Dans cette procédure pas à pas, nous allons illustrer comment les modèles de projet utilisent ASP.NET Identity pour ajouter des fonctionnalités pour inscrire, connecter et déconnecter un utilisateur.

ASP.NET Identity est implémenté à l’aide de la procédure suivante. L’objectif de cet article est de vous donner une vue d’ensemble générale de ASP.NET Identity ; vous pouvez le suivre pas à pas ou simplement lire les détails. Pour obtenir des instructions plus détaillées sur la création d’applications à l’aide de ASP.NET Identity, notamment l’utilisation de la nouvelle API pour ajouter des utilisateurs, des rôles et des informations de profil, consultez la section Étapes suivantes à la fin de cet article.

  1. Créez une application MVC ASP.NET avec des comptes individuels. Vous pouvez utiliser ASP.NET Identity dans ASP.NET MVC, Web Forms, API Web, SignalR, etc. Dans cet article, nous allons commencer par une application MVC ASP.NET.

    image de la nouvelle fenêtre de projet ASP dot Net

  2. Le projet créé contient les trois packages suivants pour ASP.NET Identity.

    • Microsoft.AspNet.Identity.EntityFramework
      Ce package a l’implémentation Entity Framework de ASP.NET Identity qui conservera les données et le schéma ASP.NET Identity sur SQL Server.
    • Microsoft.AspNet.Identity.Core
      Ce package a les interfaces principales pour ASP.NET Identity. Ce package peut être utilisé pour écrire une implémentation d'ASP.NET Identity qui cible différents magasins de persistance, tels que le Stockage Table d'Azure, les bases de données NoSQL, etc.
    • Microsoft.AspNet.Identity.OWIN
      Ce package contient des fonctionnalités utilisées pour brancher l’authentification OWIN avec ASP.NET Identity dans ASP.NET applications. Cela est utilisé lorsque vous ajoutez des fonctionnalités de connexion à votre application et appelez le middleware OWIN Cookie Authentication pour générer un cookie.

  3. Création d’un utilisateur.
    Lancez l’application, puis cliquez sur le lien Inscrire pour créer un utilisateur. L’image suivante montre la page Inscrire qui collecte le nom d’utilisateur et le mot de passe.

    image Image de création d’un nouveau compte

    Lorsque l’utilisateur sélectionne le bouton Inscrire, l’action Register du contrôleur de compte crée l’utilisateur en appelant l’API d’identité ASP.NET, comme indiqué ci-dessous :

    [HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser() { UserName = model.UserName };
        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
            await SignInAsync(user, isPersistent: false);
            return RedirectToAction("Index", "Home");
        }
        else
        {
            AddErrors(result);
        }
    }

    // If we got this far, something failed, redisplay form
    return View(model);
}

  4. Connectez-vous.
    Si l’utilisateur a été créé avec succès, elle est connectée par la méthode SignInAsync.

     [HttpPost]
 [AllowAnonymous]
 [ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser { UserName = model.Email, Email = model.Email };
        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
             await SignInManager.SignInAsync(user, isPersistent:false, rememberBrowser:false);
                    
             // For more information on how to enable account confirmation and password reset please visit https://go.microsoft.com/fwlink/?LinkID=320771
             // Send an email with this link
             // string code = await UserManager.GenerateEmailConfirmationTokenAsync(user.Id);
             // var callbackUrl = Url.Action("ConfirmEmail", "Account", new { userId = user.Id, code = code }, protocol: Request.Url.Scheme);
             // await UserManager.SendEmailAsync(user.Id, "Confirm your account", "Please confirm your account by clicking <a href=\"" + callbackUrl + "\">here</a>");

             return RedirectToAction("Index", "Home");
         }
         AddErrors(result);
     }

    // If we got this far, something failed, redisplay form
     return View(model);
 }

    La méthode SignInManager.SignInAsync génère un ClaimsIdentity. Étant donné que ASP.NET identité et l’authentification des cookies OWIN sont un système basé sur les revendications, l’infrastructure exige que l’application génère un ClaimsIdentity pour l’utilisateur. ClaimsIdentity contient des informations sur toutes les revendications de l’utilisateur, telles que les rôles auquel appartient l’utilisateur.

  5. Fermez la session.
    Sélectionnez le lien Déconnecter pour appeler l’action LogOff dans le contrôleur de compte.

    // POST: /Account/LogOff
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult LogOff()
{
    AuthenticationManager.SignOut();
    return RedirectToAction("Index", "Home");
}

    Le code mis en surbrillance ci-dessus montre la méthode AuthenticationManager.SignOut OWIN. C'est similaire à la méthode FormsAuthentication.SignOut utilisée par le module FormsAuthentication dans les formulaires Web.

Composants de ASP.NET Identity

Le schéma ci-dessous présente les composants du système ASP.NET Identity (sélectionnez sur ceci ou sur le schéma pour l’agrandir). Les packages en vert composent le système ASP.NET Identity. Tous les autres packages sont des dépendances nécessaires pour utiliser le système ASP.NET Identity dans ASP.NET applications.

diagramme montrant les composants du système d’identité A S P dot Net

Voici une brève description des packages NuGet non mentionnés précédemment :

  • Microsoft.Owin.Security.Cookies
    Middleware qui permet à une application d’utiliser l’authentification basée sur les cookies, similaire à l'authentification par formulaire d'ASP.NET.
  • EntityFramework
    Entity Framework est la technologie d’accès aux données recommandée par Microsoft pour les bases de données relationnelles.

Migration de membership vers ASP.NET Identityontrôle de persistance

Nous espérons pouvoir bientôt fournir des conseils sur la migration de vos applications existantes utilisant ASP.NET Membership ou Simple Membership vers le nouveau système ASP.NET Identity.

Étapes suivantes