Module 2 : Modèle de sécurité pour les applications ASP.NET

Sur cette page

Dans ce module
Objectifs
S'applique à
Applications Web .NET
Technologies d'implémentation
Architecture de la sécurité
Présentation de la sécurité .NET Framework
Résumé

Dans ce module

Les applications ASP.NET reposent sur l'interaction entre de nombreux éléments et technologies. Les différents composants d'une même solution offrent des fonctionnalités de sécurité qui leur sont propres. Il ne suffit toutefois pas d'envisager les questions de sécurité composant par composant. Vous devez prendre en compte les interactions entre ces derniers pour offrir une sécurité optimale au niveau de la solution globale.

Le présent module fournit une introduction à l'architecture et à la sécurité des applications Web .NET. Ce point de départ est ensuite développé dans les autres modules du guide. Ce module offre une vue d'ensemble des fonctionnalités et des services de sécurité qui couvrent tous les niveaux d'une application Web .NET classique. Il présente également les fonctionnalités de sécurité de .NET Framework et les éléments les plus importants pour les développeurs d'applications Web ASP.NET.

Haut de page

Objectifs

Ce module vous permet d'effectuer les opérations suivantes :

• découvrir l'architecture des applications Web .NET et le concept des niveaux d'application logiques et physiques ;

• identifier les fonctionnalités de sécurité fournies par chacune des technologies d'implémentation mises en œuvre pour créer des applications Web .NET et leurs interactions ;

• commencer à appréhender les fonctionnalités de sécurité .NET Framework et déterminer les éléments essentiels dans le cadre de la sécurité des applications Web ;

• comparer les mécanismes d'autorisation et d'authentification disponibles pour votre application Web ;

• comprendre comment les objets Principal et Identity sont utilisés par les applications Web .NET ;

• identifier les opérateurs de contrôle d'appels et les passerelles que vous pouvez utiliser pour mettre en place des limites de confiance dans votre application.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

• Windows XP ou Windows 2000 Server et systèmes d'exploitation ultérieurs

• Services IIS (Internet Information Services)

• .NET Framework versions 1.0 et ultérieures

Haut de page

Applications Web .NET

Cette section constitue une brève introduction aux applications Web .NET et décrit leurs caractéristiques d'un point de vue logique et physique. Elle présente également les différentes technologies d'implémentation utilisées pour créer des applications Web .NET.

Niveaux logiques

L'architecture logique des applications considère tout système comme un ensemble de services qui coopèrent et qui sont regroupés dans les couches suivantes :

• Services d'utilisateurs

• Services métier

• Services de données

L'architecture logique permet d'identifier les types génériques de services invariablement présents dans un système afin de garantir une segmentation correcte et de gérer la définition des interfaces entre les niveaux. Cette segmentation vous permet d'opérer des choix plus prudents en termes d'architecture et de conception lors de l'implémentation de chaque couche et de créer une application plus facile à gérer.

Les couches peuvent être décrites comme suit :

• Les services d'utilisateurs sont chargés des interactions des clients avec le système et offrent un pont commun vers la logique métier encapsulée par les composants dans la couche des services métier. Les services d'utilisateurs sont généralement associés à des utilisateurs interactifs. Cependant, ils procèdent également au traitement initial des demandes par programmation émanant d'autres systèmes, qui n'implique aucune interface utilisateur visible. L'authentification et l'autorisation, dont la nature varie en fonction du type de client, sont généralement effectuées dans la couche des services d'utilisateurs.

• Les services métier fournissent les fonctionnalités clés du système et encapsulent la logique métier. Ils sont indépendants du canal de remise et des systèmes principaux ou des sources de données. Ils offrent la stabilité et la souplesse nécessaires à l'évolution du système afin de prendre en charge des canaux nouveaux et différents ainsi que des systèmes principaux. En principe, la gestion d'une demande métier implique plusieurs composants qui coopèrent au sein de la couche des services métier.

• Les services de données offrent un accès aux données (hébergées dans les limites du système) et aux autres systèmes (principaux) par l'intermédiaire d'interfaces génériques, faciles à utiliser à partir des composants dans la couche des services métier. Les services de données permettent de synthétiser la multitude de sources de données et de systèmes principaux et d'encapsuler des formats de données et des règles d'accès particulières.

Le classement logique des types de services dans un système peut être lié à la distribution physique possible des composants qui implémentent les services, mais il en est relativement indépendant.

Il est également important de savoir que les niveaux logiques peuvent être identifiés à tout niveau d'agrégation ; les niveaux peuvent ainsi être identifiés pour l'ensemble du système (dans le contexte de son environnement et des interactions externes) et pour tout sous-système contenu. Par exemple, chaque nœud distant qui héberge un service Web est composé de services d'utilisateurs (qui gèrent les demandes et les messages entrants), de services métier et de services de données.

Modèles de déploiement physique

Les trois couches de services logiques décrites précédemment n'impliquent en aucun cas des nombres spécifiques de niveaux physiques. Les trois services logiques peuvent être situés physiquement sur le même ordinateur ou être répartis sur plusieurs ordinateurs.

Serveur Web en tant que serveur d'applications

Un modèle de déploiement courant des applications Web .NET consiste à placer les composants métier et d'accès aux données sur le serveur Web. Cette solution minimise les tronçons réseau, ce qui peut permettre d'optimiser les performances. Ce modèle est présenté dans la figure 2.1.

Figure 2.1
Serveur Web en tant que serveur d'applications

Niveau d'application distante

Le niveau d'application distante représente un modèle de déploiement courant, particulièrement pour les scénarios Internet dans lesquels le niveau Web est contenu dans un réseau de périmètre (également appelé zone démilitarisée (DMZ) et sous-système filtré) et est séparé des utilisateurs finaux et du niveau d'application distante à l'aide de pare-feu de filtrage de paquets. Le niveau d'application distante est présenté dans la figure 2.2.

Figure 2.2
Introduction d'un niveau d'application distante

Haut de page

Technologies d'implémentation

Les applications Web .NET implémentent généralement un ou plusieurs services logiques à l'aide des technologies suivantes :

• ASP.NET
  La technologie ASP.NET est généralement utilisée pour implémenter des services d'utilisateurs. ASP.NET propose une architecture enfichable que vous pouvez utiliser pour créer des pages Web. La sécurité ASP.NET est présentée en détail dans le Module 8, « Sécurité ASP.NET ».

• Microsoft Enterprise Services
  Les services Microsoft Enterprise Services offrent aux applications des services déployés au niveau de l'infrastructure. Il s'agit, entre autres, des services de gestion de ressources et de transactions distribuées, par exemple le regroupement d'objets pour des composants .NET. La sécurité Microsoft Enterprise Services est présentée en détail dans le Module 9, « Sécurité des services Microsoft Enterprise Services ».

• Applications Web
  Les services Web permettent l'échange de données et l'invocation à distance de la logique d'application à l'aide d'échanges de messages SOAP pour déplacer les données au travers de pare-feu et entre des systèmes hétérogènes. La sécurité des services Web est présentée en détail dans le Module 10, « Sécurité des services Web ».

• .NET Remoting
  La technologie .NET Remoting offre une infrastructure pour l'accès aux objets distribués sur différents ordinateurs et processus. La sécurité .NET Remoting est présentée en détail dans le Module 11, « Sécurité .NET Remoting ».

• ADO.NET et Microsoft® SQL Server? 2000
  ADO.NET fournit des services d'accès aux données. Cette technologie est intégralement conçue pour les applications Web distribuées et gère les scénarios déconnectés associés aux applications Web. SQL Server propose une sécurité intégrée qui utilise les mécanismes d'authentification des systèmes d'exploitation (Kerberos ou NTLM). L'autorisation est assurée par des connexions et des permissions précises, qui peuvent être appliquées aux différents objets de la base de données. La sécurité de l'accès aux données est présentée en détail dans le Module 12, « Sécurité de l'accès aux données ».

• IPSec (Internet Protocol Security)
  La technologie IPSec propose des services point à point d'authentification et de cryptage au niveau du transport. Pour plus d'informations sur IPSec, consultez le Module 4, « Communication sécurisée ».

• SSL (Secure Sockets Layer)
  La technologie SSL propose un canal de communication point à point sécurisé. Les données envoyées sur le canal sont cryptées. Pour plus d'informations sur SSL, consultez le Module 4, « Communication sécurisée ».

Haut de page

Architecture de la sécurité

La figure 2.3 illustre le modèle de niveau d'application distante ainsi que les services de sécurité proposés par les différentes technologies présentées précédemment. L'authentification et l'autorisation ont lieu en de nombreux points dans les différents niveaux. Ces services sont fournis principalement par IIS (Internet Information Services), ASP.NET, Microsoft Enterprise Services et SQL Server. Les canaux de communication sécurisés sont également appliqués dans l'ensemble des niveaux et s'étendent du navigateur ou périphérique client jusqu'à la base de données. Les canaux sont sécurisés à l'aide de SSL (Secure Sockets Layer) et de IPSec.

Figure 2.3
Architecture de la sécurité

Sécurité dans les différents niveaux

Les fonctionnalités d'authentification, d'autorisation et de communication sécurisée fournies par les technologies traitées précédemment sont récapitulées dans le tableau 2.1.

Tableau 2.1 : Fonctionnalités de sécurité

Authentification

La technologie .NET Framework sur Windows 2000 propose les options d'authentification suivantes :

• Modes d'authentification ASP.NET

• Authentification Microsoft Enterprise Services

• Authentification SQL Server

Modes d'authentification ASP.NET

Les modes d'authentification ASP.NET comprennent l'authentification Windows, par formulaires, Passport et Aucune.

• Authentification Windows. Dans le cadre de ce mode d'authentification, ASP.NET s'appuie sur IIS pour authentifier les utilisateurs et créer un jeton d'accès Windows pour représenter l'identité authentifiée. IIS propose les systèmes d'authentification suivants :

  • Authentification de base. L'authentification de base implique que l'utilisateur fournisse les informations d'identification sous forme d'un nom d'utilisateur et d'un mot de passe pour prouver son identité. Il s'agit d'un standard Internet proposé qui repose sur le document RFC 2617 (en anglais) : http://www.faqs.org/rfcs/rfc2617.html. Les navigateurs Netscape Navigator et Microsoft Internet Explorer gèrent l'authentification de base. Les informations d'identification de l'utilisateur sont transmises du navigateur au serveur Web dans un format encodé Base64 et non crypté. Dans la mesure où il obtient les informations d'identification décryptées de l'utilisateur, le serveur Web peut émettre des appels distants (pour accéder aux ressources et ordinateurs distants, par exemple) à l'aide des informations d'identification de l'utilisateur.

    Remarque : l'authentification de base doit être utilisée uniquement en conjonction avec un canal sécurisé (défini en principe à l'aide de SSL). Dans le cas contraire, les noms d'utilisateurs et les mots de passe peuvent être facilement dérobés à l'aide d'un logiciel de surveillance du réseau. Si vous utilisez l'authentification de base, vous devez utiliser SSL sur toutes les pages (et pas uniquement sur une page de connexion), car les informations d'identification sont transmises pour toutes les demandes suivantes. Pour plus d'informations sur l'utilisation de l'authentification de base avec SSL, consultez le Module 8, « Sécurité ASP.NET ».

  • Authentification Digest. L'authentification Digest, présentée avec IIS 5.0, est similaire à l'authentification de base, la seule différence résidant dans le fait qu'elle transmet un hachage des informations d'identification au lieu de transmettre les informations de l'utilisateur non cryptées du navigateur au serveur Web. Elle est donc plus sûre, bien qu'elle nécessite un client Internet Explorer version 5.0 ou ultérieure et une configuration spécifique du serveur.

  • Authentification intégrée de Windows. L'authentification intégrée de Windows (Kerberos ou NTLM, selon la configuration du serveur et du client) utilise un échange cryptographique avec le navigateur Web Internet Explorer de l'utilisateur pour confirmer l'identité de ce dernier. Elle est gérée uniquement par Internet Explorer (et non par Netscape Navigator). Par conséquent, elle tend à être utilisée uniquement dans des scénarios intranet, dans lesquels le logiciel client peut être contrôlé. Elle est utilisée uniquement par le serveur Web si l'accès anonyme est désactivé ou si l'accès anonyme est refusé par l'intermédiaire des autorisations du système de fichiers Windows.

  • Authentification par certificats. L'authentification par certificats utilise les certificats clients pour identifier positivement les utilisateurs. Le certificat client est transmis par le navigateur (ou l'application cliente) de l'utilisateur au serveur Web. Dans le cas des services Web, le client des services Web transmet le certificat par l'intermédiaire de la propriété ClientCertificates de l'objet HttpWebRequest. Le serveur Web extrait ensuite l'identité de l'utilisateur à partir du certificat. Cette méthode repose sur l'installation d'un certificat client sur l'ordinateur de l'utilisateur et tend par conséquent à être utilisée principalement dans des scénarios intranet ou extranet, dans lesquels la population des utilisateurs est bien connue et contrôlée. Lorsque IIS reçoit un certificat client, il peut relier le certificat à un compte Windows.

  • Authentification anonyme. Si vous n'avez pas besoin d'authentifier vos clients (ou si vous implémentez un modèle d'authentification personnalisé), IIS peut être configuré pour l'authentification anonyme. Dans ce cas, le serveur Web crée un jeton d'accès Windows pour représenter tous les utilisateurs anonymes dans le même compte anonyme (ou invité). Le compte anonyme par défaut est IUSR_MACHINENAME, MACHINENAME correspondant au nom NetBIOS de votre ordinateur spécifié lors de l'installation.

• Authentification Passport. Dans le cadre de ce mode d'authentification, ASP.NET utilise les services d'authentification centralisés de Microsoft Passport. ASP.NET fournit un wrapper utile pour les fonctionnalités exposées par le Kit de développement Microsoft Passport (SDK), qui doit être installé sur le serveur Web.

• Authentification par formulaires. Cette méthode utilise la redirection côté client pour transférer les utilisateurs non authentifiés vers un formulaire HTML spécifié, qui leur permet d'entrer leurs informations d'identification (en principe le nom d'utilisateur et le mot de passe). Ces informations d'identification sont ensuite validées et un ticket d'authentification est généré et renvoyé au client. Le ticket d'authentification gère l'identité de l'utilisateur et éventuellement la liste des rôles dont l'utilisateur est membre pour la durée de la session de l'utilisateur.
  L'authentification par formulaires est parfois utilisée exclusivement pour la personnalisation du site Web. Dans ce cas, le code personnalisé à rédiger est limité, car ASP.NET gère une grande partie du processus automatiquement avec une configuration simple. Dans le cadre des scénarios de personnalisation, le cookie doit contenir uniquement le nom de l'utilisateur.

  Remarque : l'authentification par formulaires envoie le nom et le mot de passe de l'utilisateur au serveur Web en texte brut (en toutes lettres). Vous devez par conséquent utiliser l'authentification par formulaires en conjonction avec un canal sécurisé par SSL. Pour garantir la protection constante du cookie d'authentification transmis lors des demandes ultérieures, envisagez d'utiliser SSL pour toutes les pages de votre application et pas uniquement pour la page de connexion.

• Aucune. L'option Aucune indique que vous ne voulez pas authentifier les utilisateurs ou que vous faites appel à un protocole d'authentification personnalisé.

Informations supplémentaires

Pour plus d'informations sur l'authentification ASP.NET, consultez le Module 8, « Sécurité ASP.NET ».

Authentification Microsoft Enterprise Services

L'authentification Microsoft Enterprise Services est réalisée en utilisant l'infrastructure de transport RPC (Remote Procedure Call) sous-jacente, laquelle fait appel à son tour à l'interface SSPI (Security Service Provider Interface) du système d'exploitation. Les clients des applications Microsoft Enterprise Services peuvent être authentifiés à l'aide de l'authentification Kerberos ou NTLM.

Un composant desservi peut être hébergé dans une application de bibliothèque ou une application serveur. Les applications de bibliothèque sont hébergées dans les processus clients et adoptent par conséquent l'identité du client. Les applications serveur s'exécutent dans des processus serveur séparés sous leur propre identité. Pour plus d'informations sur l'identité, consultez la section « Objets Identity et Principal » plus loin dans ce module.

Les appels entrants vers un composant desservi peuvent être authentifiés aux niveaux suivants :

• Par défaut : le niveau d'authentification par défaut du package de sécurité est employé.

• Aucune : aucune authentification n'a lieu.

• Connexion : l'authentification a lieu uniquement lorsque la connexion est établie.

• Appel : l'authentification a lieu au début de chaque appel de procédure distante.

• Paquet : procède à l'authentification et vérifie que toutes les données d'appel sont reçues.

• Intégrité du paquet : procède à l'authentification des données et vérifie qu'aucune de ces données n'a été modifiée durant son transit.

• Confidentialité du paquet : procède à l'authentification et crypte le paquet, y compris les données et l'identité et la signature de l'expéditeur.

Informations supplémentaires

Pour plus d'informations sur l'authentification Microsoft Enterprise Services, consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

Authentification SQL Server

SQL Server peut authentifier des utilisateurs à l'aide de l'authentification Windows (NTLM ou Kerberos) ou utiliser son propre modèle d'authentification intégré, appelé authentification SQL. Les deux options suivantes sont disponibles :

• SQL Server et Windows. Les clients peuvent se connecter à une instance de Microsoft SQL Server au moyen de l'authentification SQL Server ou de l'authentification Windows. Cette option est parfois appelée authentification en mode mixte.

• Windows uniquement. L'utilisateur doit se connecter à l'instance de Microsoft SQL Server à l'aide de l'authentification Windows.

Informations supplémentaires

Les avantages de chaque méthode sont traités dans le Module 12, « Sécurité de l'accès aux données ».

Autorisation

La technologie .NET Framework sur Windows 2000 propose les options d'autorisation suivantes :

• Options d'autorisation ASP.NET

• Autorisation Microsoft Enterprise Services

• Autorisation SQL Server

Options d'autorisation ASP.NET

Les options d'autorisation ASP.NET peuvent être utilisées par les applications Web ASP.NET, les applications Web et les composants distants. ASP.NET fournit les options d'autorisation suivantes :

• Autorisation des URL. Il s'agit d'un mécanisme d'autorisation configuré par des paramètres dans les fichiers de configuration de l'application et de l'ordinateur. L'autorisation des URL permet de restreindre l'accès à des fichiers et à des dossiers spécifiques dans l'espace de noms de l'URI (Uniform Resource Identifier) de votre application. Vous pouvez par exemple refuser ou autoriser de manière sélective l'accès à des dossiers ou à des fichiers spécifiques (adressés au moyen d'une URL) pour les utilisateurs nommés. Vous pouvez également limiter l'accès en fonction des rôles dont l'utilisateur est membre et du type de verbe HTTP adopté pour émettre une demande (GET, POST, etc.).
  L'autorisation des URL nécessite une identité authentifiée. Celle-ci peut être obtenue par un modèle d'authentification Windows ou par tickets.

• Autorisation de fichiers. L'autorisation de fichiers s'applique uniquement si vous utilisez l'un des mécanismes d'authentification Windows fournis par IIS pour authentifier les appelants, et si ASP.NET est configuré pour l'authentification Windows.
  Vous pouvez l'utiliser pour limiter l'accès à des fichiers indiqués sur un serveur Web. Les autorisations d'accès sont déterminées par les listes de contrôle d'accès Windows associées aux fichiers.

• Demandes PrincipalPermission. Les demandes PrincipalPermission peuvent être utilisées (de manière déclarative ou par programmation) comme mécanisme de contrôle d'accès supplémentaire plus précis. Elles vous permettent de gérer l'accès aux classes, aux méthodes ou aux blocs de code individuels en fonction de l'identité des différents utilisateurs et des groupes auxquels ils appartiennent.

• .Rôles .NET. Les rôles .NET permettent de regrouper des utilisateurs qui bénéficient d'autorisations identiques dans votre application. En termes de concept, ils sont similaires aux précédentes implémentations s'appuyant sur les rôles, par exemple les groupes Windows et les rôles COM+. Toutefois, contrairement à ces méthodes antérieures, les rôles .NET ne nécessitent pas d'identités Windows authentifiées et peuvent être utilisés avec des modèles d'authentification par tickets, tels que l'authentification par formulaires.
  Les rôles .NET peuvent être utilisés pour gérer l'accès aux ressources et aux opérations et être configurés de manière déclarative ainsi que par programmation.

Informations supplémentaires

Pour plus d'informations sur l'autorisation ASP.NET, consultez le Module 8, « Sécurité ASP.NET ».

Autorisation Microsoft Enterprise Services

L'accès aux fonctionnalités contenues dans les composants desservis dans les applications Microsoft Enterprise Services est régi par l'appartenance aux rôles Microsoft Enterprise Services. Ces derniers sont différents des rôles .NET et peuvent contenir des comptes d'utilisateurs ou de groupes Windows. L'appartenance à un rôle est définie à partir du catalogue COM+ et sa gestion s'effectue à partir de l'outil Services de composants.

Informations supplémentaires

Pour plus d'informations sur l'autorisation Microsoft Enterprise Services, consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

Autorisation SQL Server

SQL Server permet d'utiliser des autorisations plus précises qui peuvent être appliquées aux différents objets de base de données. Les autorisations peuvent s'appuyer sur l'appartenance à des rôles (SQL Server fournit des rôles de base de données fixes, des rôles définis par l'utilisateur et des rôles d'applications) ou être accordées individuellement à des comptes d'utilisateurs ou de groupes Windows.

Informations supplémentaires

Pour plus d'informations sur l'autorisation SQL Server, consultez le Module 12, « Sécurité de l'accès aux données ».

Opérateurs de contrôle d'appels et passerelles

Dans la suite de ce guide, le terme opérateur de contrôle d'appels sera utilisé pour désigner la technologie responsable d'une passerelle. Une passerelle représente un point de contrôle d'accès (protégeant une ressource) dans une application. Par exemple, une ressource peut être une opération (représentée par une méthode sur un objet) ou une ressource de système de fichiers ou de base de données.

Toutes les technologies clés mentionnées ci-avant proposent des opérateurs de contrôle d'appels pour les autorisations d'accès. Les demandes doivent transiter par une série de passerelles avant d'être autorisées à accéder à l'opération ou à la ressource concernée. Les passerelles par lesquelles les demandes doivent transiter sont décrites ci-après :

• IIS fournit une passerelle lorsque vous authentifiez les utilisateurs (lorsque vous désactivez l'authentification anonyme). Les autorisations Web IIS peuvent être utilisées comme mécanisme de contrôle d'accès pour limiter la capacité des utilisateurs Web à accéder à des fichiers ou à des dossiers spécifiques. Contrairement aux autorisations de fichiers NTFS, les autorisations Web s'appliquent à tous les utilisateurs Web, et non à des utilisateurs ou à des groupes individuels. Les autorisations de fichiers NTFS offrent des restrictions supplémentaires sur les ressources Web, telles que des pages Web ou des fichiers image. Ces restrictions s'appliquent à des groupes ou à des utilisateurs individuels.
  IIS vérifie les autorisations Web, puis les autorisations de fichiers NTFS. Les deux mécanismes doivent accorder une autorisation à l'utilisateur pour qu'il soit en mesure d'accéder au fichier ou au dossier. En cas d'échec d'une autorisation Web, IIS renvoie une réponse HTTP 403 - Accès interdit. En revanche, si une vérification d'autorisation NTFS échoue, IIS renvoie une réponse HTTP 401 - Accès refusé.

• ASP.NET propose différentes passerelles configurables et par programmation. Il s'agit d'autorisations des URL, d'autorisations de fichiers, de demandes PrincipalPermission et de rôles .NET.

• La passerelle Microsoft Enterprise Services utilise les rôles Microsoft Enterprise Services pour autoriser l'accès aux fonctionnalités métier.

• SQL Server 2000 comprend une série de passerelles qui incluent les connexions d'accès aux serveurs, les connexions d'accès aux bases de données et les autorisations d'objets de base de données.

• Windows 2000 fournit des passerelles à l'aide de listes de contrôle d'accès associées aux ressources sécurisées.

En fait, les opérateurs de contrôle d'appels procèdent à l'autorisation en fonction de l'identité de l'utilisateur ou du service qui transmet un appel à la passerelle et qui tente d'accéder à une ressource spécifique. L'utilisation de plusieurs passerelles permet de garantir une sécurité renforcée, composée de plusieurs lignes de défense. Le tableau 2.2 résume les opérateurs de contrôle d'appels et identifie les passerelles dont ils sont responsables.

Tableau 2.2 : Responsabilités des opérateurs de contrôle d'appels et passerelles correspondantes

Lorsque vous utilisez les différentes passerelles dans les niveaux de votre application, vous pouvez filtrer les utilisateurs qui doivent être autorisés à accéder à vos ressources principales. L'accès est restreint par les passerelles successives qui deviennent de plus en plus précises au fur et à mesure que la demande avance dans l'application jusqu'aux ressources principales.

Prenons l'exemple de l'application Internet qui fait appel à IIS, présentée dans la figure 2.4.

Figure 2.4
Filtrage des utilisateurs à l'aide des opérateurs de contrôle d'appels

La figure 2.4 illustre les points suivants :

• Vous pouvez désactiver l'authentification anonyme dans IIS. Par conséquent, l'accès est autorisé uniquement pour les comptes que IIS est en mesure d'authentifier. Le nombre d'utilisateurs potentiels peut donc chuter à 10 000 utilisateurs.

• Ensuite, dans ASP.NET, vous utilisez l'autorisation des URL qui peut faire chuter le nombre d'utilisateurs à 1 000.

• Les autorisations de fichiers peuvent à leur tour limiter l'accès à 100 utilisateurs.

• Enfin, le code de votre application Web peut autoriser uniquement 10 utilisateurs à accéder à votre ressource limitée, en fonction de l'appartenance à des rôles spécifiques.

Haut de page

Présentation de la sécurité .NET Framework

La sécurité .NET Framework vient se placer au-dessus de la sécurité Windows. Elle n'est pas destinée à remplacer cette dernière, mais à fournir des fonctionnalités de sécurité supplémentaires. Tous les accès à des ressources effectués par vos applications .NET sont finalement soumis à la sécurité du système d'exploitation.

Si, par exemple, une application Web ASP.NET tente d'ouvrir un fichier, la tentative d'accès est vérifiée en fonction des listes de contrôle d'accès Windows associées à ce fichier. L'identité utilisée pour les accès aux ressources est soit l'identité du processus de l'application ASP.NET, soit l'identité empruntée si l'application fait actuellement appel à l'emprunt d'identité.

Sécurité d'accès au code

.NET Framework fournit un mécanisme de sécurité supplémentaire appelé sécurité d'accès au code (CAS). La sécurité traditionnelle fournie par Windows s'appuie sur des objets Principal et les décisions d'autorisation sont prises en fonction de l'identité d'un objet Principal authentifié (l'utilisateur qui exécute le code ou l'utilisateur ayant ouvert une session dans une application Web, par exemple).

Le mécanisme CAS vient renforcer la sécurité en prenant en charge les décisions d'autorisation prises en fonction de l'identité du code (et non de l'utilisateur qui exécute le code). Ce point est particulièrement important pour le code mobile (contrôles et applications téléchargés sur Internet par l'intermédiaire de Internet Explorer). Lorsque vous avez ouvert une session sur votre ordinateur en tant qu'administrateur, souhaitez-vous réellement qu'un code de ce type soit associé à des privilèges d'administration ? Probablement pas si vous souhaitez préserver l'intégrité et la sécurité de votre ordinateur.

Stratégie de preuve et de sécurité

Le code est authentifié et son identité est déterminée à l'aide d'attributs du code appelés « preuves ». Les preuves peuvent inclure la clé publique d'un assembly, qui fait partie de son nom fort, son URL de téléchargement, son répertoire d'installation d'application, etc. Une fois que l'identité du code a été établie, les preuves collectées sont transmises par l'intermédiaire de la stratégie de sécurité, qui régit en dernier lieu les fonctionnalités du code et les autorisations d'accès à des ressources sécurisées qui lui sont accordées.

La stratégie par défaut garantit que la totalité du code installé sur un ordinateur local est associée à un niveau de confiance suffisant et qu'un ensemble d'autorisations illimité lui est accordé pour accéder à des ressources sécurisées. Toute tentative d'accès à une ressource est par conséquent uniquement soumise à la sécurité du système d'exploitation. La totalité du code installé sur l'ordinateur local est associée à un niveau de confiance suffisant, partant du principe que l'administrateur a installé les logiciels concernés en toute connaissance de cause.

Mécanisme CAS et applications Web ASP.NET

Les applications Web ASP.NET sont installées sur le serveur Web local. Elles sont par conséquent associées à un niveau de confiance suffisant sur ce dernier par la stratégie par défaut. Pour les développeurs d'applications Web côté serveur, le mécanisme CAS présente ainsi certaines limitations. En fait, les applications Web ASP.NET créées avec .NET Framework version 1 doivent être exécutées en tant qu'applications associées à un niveau de confiance suffisant.

Remarque : .NET Framework version 1.1 prend en charge les applications Web associées à un niveau de confiance partiel, ce qui permet de faire appel au mécanisme CAS dans les applications Web côté serveur. Le principal avantage réside dans la possibilité d'isoler plus facilement les applications les unes des autres et des ressources systèmes stratégiques, ce qui est un point important pour les fournisseurs de services Internet et les fournisseurs de services applicatifs, qui hébergent de nombreuses applications Web développées par diverses sociétés.

Objets Identity et Principal

Si le système CAS est axé sur le code, d'autres éléments de .NET Framework s'appuient sur les objets Principal. Cette caractéristique de .NET Framework est primordiale pour la sécurité des applications ASP.NET.

La sécurité Windows axée sur les utilisateurs repose sur le contexte de sécurité fourni par une ouverture de session, tandis que la sécurité .NET repose sur les objets Principal et Identity.

Dans le cadre de la programmation Windows classique, lorsque vous voulez connaître le contexte de sécurité sous lequel le code est exécuté, vous déterminez l'identité du propriétaire du processus ou du thread en cours d'exécution. Dans le cadre de la programmation .NET, si vous souhaitez récupérer le contexte de sécurité de l'utilisateur actif, vous extrayez l'objet Principal actuel qui associé au thread en cours d'exécution et auquel vous accédez par l'intermédiaire de Thread.CurrentPrincipal.

.NET Framework utilise des objets Principal, qui contiennent des objets Identity, pour représenter les utilisateurs lorsque le code .NET est exécuté. Ensemble, ces objets fournissent la structure sur laquelle repose l'autorisation par rôle .NET. Dans le cas des applications Web ASP.NET, l'utilisateur authentifié est représenté par des objets Principal et Identity associés au thread et à la demande Web en cours.

Interfaces IPrincipal et IIdentity

Les objets Identity et Principal doivent respectivement implémenter les interfaces IIdentity et IPrincipal. Ces interfaces sont définies dans l'espace de noms System.Security.Principal. Des interfaces communes permettent à .NET Framework de traiter les objets Identity et Principal de manière polymorphe, indépendamment des détails d'implémentation sous-jacents.

L'interface IPrincipal permet de tester l'appartenance aux rôles par l'intermédiaire d'une méthode IsInRole et offre la possibilité d'accéder à un objet IIdentity associé.

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

L'interface IIdentity offre des informations d'authentification supplémentaires, tels que le nom et le type d'authentification.

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

.NET Framework fournit plusieurs implémentations concrètes de IPrincipal et de IIdentity , illustrées dans la figure 2.5 et décrites dans les sections suivantes.

Figure 2.5
Classes d'implémentation IPrincipal et IIdentity

WindowsPrincipal et WindowsIdentity

La version .NET d'un contexte de sécurité Windows est divisée en deux classes :

• WindowsPrincipal. Cette classe stocke les rôles associés à l'utilisateur Windows actif. L'implémentation WindowsPrincipal traite les groupes Windows en tant que rôles. La méthode IPrncipal.IsInRole renvoie la valeur « true » ou « false » pour indiquer si l'utilisateur appartient à des groupes Windows.

• WindowsIdentity. Cette classe contient la partie Identity du contexte de sécurité de l'utilisateur actif et peut être obtenue à partir de la méthode WindowsIdentity.GetCurrent(). Elle renvoie un objet WindowsIdentity doté d'une propriété Token qui renvoie la valeur IntPtr représentant un descripteur Windows du jeton d'accès associé au thread d'exécution actif. Ce jeton peut ensuite être transmis aux fonctions des API (Application Programming Interface) Win32® natives telles que GetTokenInformation, SetTokenInformation, CheckTokenMembership , etc., pour extraire les informations de sécurité concernant le jeton.

  Remarque : la méthode WindowsIdentity.GetCurrent() statique renvoie l'identité du thread en cours d'exécution, qui peut utiliser, ou non, l'emprunt d'identité. Cette méthode est similaire à l'API GetUserName Win32.

Classe GenericPrincipal et objets Identity associés

Ces implémentations très simples sont utilisées par les applications qui ne font pas appel à l'authentification Windows, et lorsque l'application n'a pas besoin de représentations complexes d'un objet Principal. Elles peuvent être créées très facilement dans le code. Un certain degré de confiance est par conséquent nécessaire lorsqu'une application gère un objet GenericPrincipal.

Si vous faites appel à la méthode IsInRole sur GenericPrincipal pour prendre des décisions en matière d'autorisation, vous devez approuver l'application qui vous envoie l'objet GenericPrincipal. Cette approche s'oppose à l'utilisation des objets WindowsPrincipal dans le cadre de laquelle vous chargez le système d'exploitation de fournir un objet WindowsPrincipal valide doté d'une identité authentifiée et de noms de groupes/rôles valides.

Les types d'objets Identity suivants peuvent être associés à la classe GenericPrincipal :

• FormsIdentity. Cette classe représente une identité qui a été authentifiée à l'aide de l'authentification par formulaires. Elle contient FormsAuthenticationTicket , qui inclut des informations concernant la session d'authentification de l'utilisateur.

• PassportIdentity. Cette classe représente une identité qui a été authentifiée à l'aide de l'authentification Passport et qui contient des informations concernant le profil Passport.

• GenericIdentity. Cette classe représente un utilisateur logique qui n'est lié à aucune technologie de système d'exploitation particulière. Elle est généralement utilisée avec des mécanismes d'authentification et d'autorisation personnalisés.

ASP.NET et HttpContext.User

En principe, Thread.CurrentPrincipal est vérifié dans le code .NET avant que des décisions en matière d'autorisation soient prises. ASP.NET fournit toutefois le contexte de sécurité de l'utilisateur authentifié à l'aide de HttpContext.User.

Cette propriété accepte et renvoie une interface IPrincipal. Elle contient un utilisateur authentifié pour la demande active. ASP.NET extrait HttpContext.User lorsque des décisions en matière d'autorisation sont prises.

Si vous utilisez l'authentification Windows, le module d'authentification Windows construit automatiquement un objet WindowsPrincipal et le stocke dans HttpContext.User. Si vous utilisez d'autres mécanismes d'authentification, tels que l'authentification par formulaires ou Passport, vous devez construire un objet GenericPrincipal et le stocker dans HttpContext.User.

Identités ASP.NET

À tout moment lors de l'exécution d'une application Web ASP.NET, plusieurs identités peuvent être présentes au cours d'une même demande. Ces identités sont les suivantes :

• HttpContext.User renvoie un objet IPrincipal qui contient les informations de sécurité de la demande Web active. Il s'agit du client Web authentifié.

• WindowsIdentity.GetCurrent() renvoie l'identité du contexte de sécurité du thread Win32 en cours d'exécution. Par défaut, l'identité est ASPNET, c'est-à-dire le compte par défaut utilisé pour exécuter les applications Web ASP.NET. Cependant, si l'application Web a été configurée pour l'emprunt d'identité, l'identité représente l'utilisateur authentifié (qui est IUSR_MACHINE si l'authentification anonyme IIS est appliquée).

• Thread.CurrentPrincipal renvoie l'objet Principal du thread .NET en cours qui s'exécute sur le thread Win32.

Informations supplémentaires

• Pour obtenir une analyse détaillée de l'identité ASP.NET dans le cadre d'une combinaison de configurations d'applications Web (sans et avec emprunt d'identité), consultez la section « Matrice d'identification ASP.NET » de la partie « Référence » dans ce guide.

• Pour plus d'informations sur la création de votre propre implémentation IPrincipal, consultez le Module 8, « Sécurité ASP.NET » et « Implémenter IPrincipal » dans la partie « Référence » de ce guide.

Applications Web et .NET Remoting

Dans la version actuelle de .NET Framework, les applications Web et .NET Remoting ne disposent pas de leur propre modèle de sécurité. Ils héritent tous deux de la fonctionnalité de sécurité de IIS et ASP.NET.

Bien qu'il n'existe pas de sécurité intégrée dans l'architecture .NET Remoting, celle-ci a été conçue en tenant compte de la sécurité. Il incombe ensuite au développeur et/ou à l'administrateur d'incorporer certains niveaux de sécurité dans les applications .NET Remoting. La transmission ou non des objets Principal entre différents processus .NET Remoting dépend de l'emplacement du client et de l'objet distant, par exemple :

• .NET Remoting dans le même processus. Lorsque .NET Remoting est utilisé entre des objets dans le ou les mêmes domaines d'application ou dans des domaines différents, l'infrastructure .NET Remoting copie une référence de l'objet IPrincipal associé au contexte de l'appelant dans le contexte du destinataire.

• .NET Remoting sur différents processus. Dans ce cas, les objets IPrincipal ne sont pas transmis entre les processus. Les informations d'identification utilisées pour construire l'objet IPrincipal initial doivent être transmises au processus distant, qui peut être situé sur un ordinateur distinct. Cette opération permet à l'ordinateur distant de construire un objet IPrincipal approprié en fonction des informations d'identification fournies.

Haut de page

Résumé

Ce module vous a présenté l'ensemble des options d'authentification et d'autorisation fournies par les diverses technologies .NET. Il vous a également proposé une introduction à la sécurité .NET Framework et aux objets Principal et Identity qui sont au cœur du mécanisme d'autorisation ASP.NET.

Grâce à l'utilisation de plusieurs opérateurs de contrôle d'appels dans votre application Web .NET, vous serez en mesure d'implémenter une stratégie de sécurité offrant une protection renforcée. En résumé, les points que vous devez retenir sont les suivants :

• Les applications ASP.NET peuvent utiliser les fonctionnalités de sécurité existantes proposées par Windows et IIS.

• Vous pouvez utiliser les protocoles SSL et IPSec pour assurer des communications sécurisées au niveau des différentes couches d'une application Web .NET, du navigateur à la base de données, par exemple.

• Utilisez SSL pour protéger les informations d'identification en texte brut transmises sur le réseau lorsque vous utilisez l'authentification de base ou l'authentification par formulaires.

• Les applications Web ASP.NET créées à l'aide la version 1 de .NET Framework doivent être exécutées en tant qu'applications associées à un niveau de confiance suffisant. Pour les développeurs d'applications Web côté serveur, le mécanisme de sécurité d'accès au code CAS présente de ce fait des limitations. .NET Framework version 1.1 prendra en charge les applications Web associées à un niveau de confiance partiel. Le mécanisme CAS prendra alors plus d'importance.

• .NET représente les utilisateurs qui ont été identifiés avec l'authentification Windows à l'aide d'une combinaison de classes WindowsPrincipal et WindowsIdentity.

• Les classes GenericPrincipal et GenericIdentity ou FormsIdentity permettent de représenter les utilisateurs qui ont été identifiés à l'aide de modèles d'authentification autres que Windows, tels que l'authentification par formulaires.

• Vous pouvez générer vos propres implémentations Principal et Identity en créant des classes qui implémentent IPrincipal et IIdentity.

• Dans les applications Web ASP.NET, l'objet IPrincipal qui représente l'utilisateur authentifié est associé à la demande Web HTTP active à l'aide de la propriété HttpContext.User.

• Les passerelles sont des points de contrôle d'accès dans votre application. Elles permettent aux utilisateurs autorisés d'accéder aux ressources ou aux services. Les opérateurs de contrôle d'appels sont chargés de contrôler l'accès aux passerelles.

• Utilisez plusieurs opérateurs de contrôle d'appels pour offrir une stratégie de défense renforcée.

• Les services Web et .NET Remoting s'appuient sur les services de sécurité sous-jacents fournis par ASP.NET et IIS.

Le Module 3, « Authentification et autorisation », fournit des informations complémentaires qui vous aideront à choisir la stratégie d'authentification et d'autorisation la plus appropriée au scénario de votre application.

Haut de page