Introduction

La sécurité d’un système d’information est primordiale afin d’assurer la confidentialité des données exposées à l’utilisateur, et éviter ainsi qu’une personne mal attentionnée opère sur le système en mettant à mal l’intégrité des données de l’entreprise. L’accès aux pages, l’accès aux données et la protection des données sont des sujets sensibles auxquels le développeur doit faire attention lors du développement du site.

Plusieurs problématiques peuvent intervenir dans la sécurité du système : qui a accès à telle ou telle page ? Une fois la page rendue, qui a le droit de voir les données ? L’utilisateur travaille-t-il sur une plage de données qui lui est propre ? Est-ce qu’un utilisateur a le droit de voir les données d’un autre ? Comment stocker des données sensibles sur le poste de l’utilisateur de manière sécurisée ? ASP.NET Core apporte une réponse élaborée sur ce sujet, tout en gardant à l’esprit le caractère modulaire du framework, via plusieurs API.

Le premier volet traité par ce chapitre concerne l’authentification via Identity. Il permet de répondre à...

L’authentification et l’API Identity

ASP.NET Core Identity est un framework d’authentification extrêmement complet et ouvert embarquant d’innombrables mécanismes de login d’utilisateur, d’envoi d’e-mail de validation, d’inscription au site, de vérification par SMS et ainsi de suite. Identity s’articule autour de trois points majeurs :

fournir une couche d’abstraction entre l’application et le stockage des utilisateurs ;
fournir des mécanismes prêts à l’emploi et simples afin d’alléger le travail du développeur dans la gestion de l’authentification ;
ouvrir à des systèmes d’authentification externes comme Facebook ou Google.

Identity doit être l’interface privilégiée entre le système d’information et l’authentification des utilisateurs. ASP.NET Core Identity en est à la troisième version, et a complètement été repensée afin d’offrir une ouverture inégalée. Dans la configuration par défaut des templates Visual Studio, Identity s’utilise avec Entity Framework Core et SQL Server. Voici comment ceci est configuré dans la classe Startup :

services.AddIdentity<ApplicationUser, IdentityRole>() 
        .AddEntityFrameworkStores<ApplicationDbContext>() 
        .AddDefaultTokenProviders();

De plus, Identity s’appuie sur un middleware permettant d’authentifier chaque requête HTTP entrante :

app.UseIdentity();

La dépendance importante pour utiliser Identity est Microsoft.AspNetCore.Identity. Cette dernière permet d’utiliser toutes les méthodes d’extensions nécessaires afin de configurer au mieux Identity.

La première classe importante avec Identity est la classe UserManager<TUser>. Elle permet une gestion de haut niveau des utilisateurs du système d’information, embarquant ainsi :

Une gestion des utilisateurs classique (recherche, insertion, mise à jour…) via des méthodes telles que Create, Update ou FindByName. Selon la méthode, un résultat sous la forme d’un objet de type IdentityResult est retourné, permettant de savoir si l’opération s’est bien déroulée....

Les autorisations

Les autorisations sont les processus qui permettent de déterminer si un utilisateur a le droit ou non d’exécuter telle ou telle action. Le système d’autorisation est complètement indépendant du système d’authentification, ce qui permet de découpler facilement les modules du système web. L’espace de noms important ici est Microsoft.AspNetCore.Authorization.

ASP.NET Core distingue plusieurs concepts d’autorisations au sein de son framework :

L’autorisation simple, permettant tout juste de répondre à la question : suis-je connecté au site ?
L’autorisation basée sur des rôles.
L’autorisation basée sur des revendications. Par exemple, l’utilisateur doit être un employé de l’entreprise (et non un client, par exemple) avant d’accéder à certaines pages.
L’autorisation basée sur des policy. Un exemple serait l’âge minimum requis pour accéder à la page demandée.
L’autorisation basée sur des ressources : ai-je le droit de visualiser ce document ? ai-je le droit de modifier ce document ?
L’autorisation basée sur les vues : ai-je le droit d’accéder au bouton qui me permet de modifier cet enregistrement ?

La suite de la partie va détailler et illustrer chacun des concepts avec des exemples de code.

L’autorisation simple est le mode d’autorisation le plus simple : il va simplement vérifier que l’utilisateur est authentifié pour accéder à la page. Pour ce faire, il suffit au développeur d’utiliser l’attribut [Authorize] sur ses contrôleurs ou ses actions (ou les deux).

[Authorize] 
public class MyController : Controller 
{ 
    public ActionResult Index(){} 
    public ActionResult Create(){} 
    public ActionResult Update(){} 
    public ActionResult GetSingle(){} 
}

L’intérêt de mettre des attributs sur les contrôleurs et les actions est de pouvoir jouer sur les autorisations de manière plus fine. Il existe un autre attribut permettant de laisser n’importe quel utilisateur accéder à la page :...

La protection des données

Un site web doit avoir la possibilité de stocker des données sensibles sur la machine du client, et évidemment cela pose plusieurs problèmes de sécurité : comment chiffrer correctement les données ? Comment s’assurer que les données retransmises par le client n’ont pas été altérées ? Ces questions tournent autour de trois problématiques clés :

l’authenticité des données transmises au client ;
la confidentialité des données ;
l’isolement des données afin d’éviter au maximum qu’elles soient altérées.

L’équipe d’ASP.NET Core en charge de l’API pour la protection des données a complètement revu l’implémentation de cette dernière en gardant à l’esprit :

la simplicité de configuration de l’API. Elle doit être utilisable sans configuration préalable ;
la simplicité d’utilisation ;
la non-complexité des principes utilisés au sein de l’API. Le développeur doit pouvoir utiliser les systèmes de sécurité sans avoir à connaître les algorithmes de chiffrage.

Ainsi est née une toute nouvelle API de protection des données, ultra modulaire et paramétrable à plusieurs niveaux selon les besoins du développeur. Les différentes API sont désignées de la sorte :

Consumer API : API de haut niveau permettant une utilisation facile du système de protection des données avec un paramétrage par défaut.
Configuration API : API de configuration du système de protection permettant d’affiner le mécanisme.
Extensibility API : API de bas niveau permettant de remplacer et de réimplémenter la majorité du mécanisme de protection des données.

Au sein de tout ce système se trouvent plusieurs espaces de noms. Tout d’abord, on retrouve Microsoft.AspNetCore.DataProtection. Abstractions contenant toutes les abstractions et interfaces que le développeur peut utiliser via injection de dépendances, ou qu’il peut implémenter afin de proposer son propre système de protection. Ensuite, on retrouve...

La gestion de CORS

CORS est un acronyme signifiant Cross Origin Resource Sharing. Pour bien comprendre ce concept, il faut tout d’abord rappeler que les navigateurs n’ont pas le droit de faire des appels AJAX sur d’autres domaines que les leurs, et ceci pour des raisons de sécurité. On appelle cela la same-origin policy. En effet, cela évite que des sites Internet malicieux puissent lire des données sensibles sur d’autres sites, notamment via Web API. Cependant, dans le cadre de communication intersystème web, cela pose un problème. Comment un site web, censé communiquer avec un autre système web pour un échange de données, peut-il récupérer des informations si le navigateur n’autorise pas ce genre d’appel ? Le standard W3C a tout prévu avec CORS.

Cette problématique rentre clairement en compte de nos jours avec l’interconnexion des systèmes web. Afin de faciliter l’échange de données, les sites web s’appellent mutuellement via des web services et autres API de manière automatique, et font ainsi face à cette interdiction.

Mais au final, qu’appelle-t-on "la même origine" ? Deux ressources ont la même origine si le schéma de l’URL, l’hôte et le port sont les mêmes. Par exemple, les URL suivantes ont la même origine :

http://monsite.com/ressource1.html....

La sécurisation via OAuth 2.0

OAuth 2.0 est un protocole d’autorisation qui a été développé par le groupe de travail OAuth de l’Internet Engineering Task Force (IETF). OAuth 2.0 a été publié en octobre 2012 en tant que mise à jour de la première version du protocole OAuth, qui a été publiée en avril 2010.

Le but d’OAuth 2.0 est de fournir un moyen pour les utilisateurs de donner à un tiers l’accès limité à leurs ressources en ligne, sans partager leurs informations d’identification. Cela permet aux utilisateurs de donner à des applications tierces l’accès à leurs données, telles que les contacts, les photos et les calendriers, sur des services en ligne tels que Google et Facebook, sans partager leurs mots de passe avec ces applications.

Il y a plusieurs parties prenantes dans un processus d’authentification OAuth 2.0 :

L’utilisateur : l’utilisateur est la personne qui souhaite accéder à une ressource en ligne protégée par OAuth 2.0.
Le client : le client est l’application qui demande l’accès à la ressource de l’utilisateur. Le client peut être une application web, une application mobile ou toute autre application qui souhaite accéder à la ressource de l’utilisateur.
Le serveur d’identité : le serveur d’identité est le service qui protège la ressource de l’utilisateur et qui gère les demandes d’accès du client. C’est également lui qui gère les demandes d’autorisation du client et qui délivre un jeton d’accès au client lorsqu’une autorisation est accordée par l’utilisateur.
La ressource : la ressource est la donnée ou le service que le client souhaite accéder et qui est protégé par OAuth 2.0. En général, c’est l’API protégée par le serveur d’identité.

Au sein du protocole OAuth 2.0, il existe plusieurs flux d’authentification selon la situation : est-ce que le client est une application web ou mobile ? Faut-il sécuriser une communication machine à machine ? L’API est-elle publique ou privée ?...

La sécurité