Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
MSDN Library

Module 3 : Authentification et autorisation

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Avant de commencer Avant de commencer
Élaboration d'une stratégie d'authentification et d'autorisation Élaboration d'une stratégie d'authentification et d'autorisation
Méthodes d'autorisation Méthodes d'autorisation
Transmission de l'identité Transmission de l'identité
Autorisation par rôle Autorisation par rôle
Choix d'un mécanisme d'authentification Choix d'un mécanisme d'authentification
Résumé Résumé

Dans ce module

La conception de mécanismes d'authentification et d'autorisation pour une application Web distribuée est une tâche complexe : vous devez prendre un grand nombre de décisions qui auront une incidence sur presque tous les composants de l'application que vous développez. L'adoption d'un mécanisme d'authentification et d'autorisation adapté permet de limiter de nombreux risques en matière de sécurité. L'implémentation d'un mécanisme de ce type au cours des toutes premières phases du développement de l'application s'avère bien plus facile que l'ajout a posteriori d'une solution dans une application existante ou en cours de développement.

Ce module décrit les mécanismes d'authentification et d'autorisation à votre disposition lors du développement d'applications Web ASP.NET distribuées. Il présente également un processus auquel vous pouvez faire appel pour choisir les mécanismes d'authentification et d'autorisation appropriés à votre application.

Objectifs

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

  • découvrir les diverses options de transmission d'identité dans plusieurs couches d'application ;

  • déterminer les mécanismes d'authentification et d'autorisation adaptés à votre application Web distribuée ;

  • comparer le modèle « d'emprunt d'identité ou de délégation » (également connu sous le nom d'« appelant initial ») et le modèle de « sous-système approuvé » pour l'implémentation de mécanismes d'authentification et d'autorisation dans vos applications Web .NET distribuées ;

  • comparer l'autorisation par rôle et l'autorisation par ressource.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Windows XP ou Windows 2000 Server (avec le service pack 3) et systèmes d'exploitation ultérieurs

  • Microsoft Internet Information Services (IIS) version 5.0 et ultérieure

  • Microsoft Active Directory

  • .NET Framework version 1.0 (avec le service pack 2) et versions ultérieures

  • SQL Server 2000 (avec le service pack 2) et versions ultérieures

Avant de commencer

L'élaboration d'une stratégie d'authentification et d'autorisation pour les applications Web distribuées est une tâche complexe. L'aspect positif est que l'élaboration de l'authentification et de l'autorisation durant les phases initiales du développement de votre application permet de limiter de nombreux risques en matière de sécurité.

Ce module vous permettra de concevoir une stratégie d'autorisation adaptée à votre application et apportera également des réponses aux questions clés suivantes :

  • Où dois-je effectuer l'autorisation et quels mécanismes dois-je adopter ?

  • Quel mécanisme d'authentification dois-je utiliser ?

  • Dois-je utiliser le service d'annuaire Active Directory® pour l'authentification ou dois-je valider les informations d'identification auprès d'un magasin de données personnalisé ?

  • Quelles sont les implications et les considérations en matière de conception pour les plates-formes hétérogènes et homogènes ?

  • Comment dois-je représenter les utilisateurs qui n'utilisent pas le système d'exploitation Microsoft® Windows® dans mon application ?

  • Comment dois-je transmettre l'identité de l'utilisateur dans les différents niveaux de mon application ? Quand dois-je utiliser l'emprunt d'identité ou la délégation au niveau du système d'exploitation ?

Lorsque vous pensez à l'autorisation, vous devez également penser à l'authentification. Les deux processus vont de pair pour deux raisons :

  • Tout d'abord, une véritable stratégie d'autorisation nécessite des utilisateurs authentifiés.

  • Ensuite, la manière dont vous authentifiez les utilisateurs (et particulièrement la manière dont l'identité de l'utilisateur authentifié est représentée dans votre application) détermine les opérateurs de contrôle d'appels à votre disposition.
    Certains opérateurs de contrôle d'appels tels que l'autorisation de fichiers ASP.NET, les rôles Microsoft Enterprise Services (COM+) et les listes de contrôle d'accès Windows nécessitent une identité Windows authentifiée (sous la forme d'un objet WindowsIdentity qui encapsule un jeton d'accès Windows, lequel définit le contexte de sécurité de l'appelant). D'autres opérateurs de contrôle d'appels, tels que l'autorisation des URL ASP.NET et les rôles .NET ne requièrent pas d'identité Windows authentifiée. Ils exigent simplement une identité authentifiée, qui n'est pas nécessairement représentée par un jeton d'accès Windows.

Élaboration d'une stratégie d'authentification et d'autorisation

Les étapes suivantes identifient un processus qui vous permettra d'élaborer une stratégie d'authentification et d'autorisation pour votre application :

  1. Identification des ressources

  2. Choix d'une stratégie d'autorisation

  3. Choix des identités utilisées pour l'accès aux ressources

  4. Transmission de l'identité

  5. Choix d'une méthode d'authentification

  6. Choix de la méthode de transmission de l'identité

Identification des ressources

Cette procédure consiste à identifier les ressources que votre application doit mettre à la disposition des clients. Les ressources classiques sont les suivantes :

  • Ressources de serveur Web telles que des pages Web, des applications Web, des ressources statiques (pages et images HTML).

  • Ressources de base de données telles que des données associées aux différents utilisateurs ou des données au niveau de l'application.

  • Ressources réseau telles que des ressources de systèmes de fichiers distants et des données issues de magasins d'annuaire tels que Active Directory.

Vous devez également identifier les ressources système auxquelles votre application doit accéder. Elles s'opposent aux ressources qui sont mises à la disposition des clients. Le Registre, les journaux d'événements et les fichiers de configuration sont des exemples de ressources système.

Choix d'une stratégie d'autorisation

Les deux principales stratégies d'autorisation sont les suivantes :

  • Autorisation par rôle. L'accès aux opérations (en principe des méthodes) est sécurisé en fonction du rôle auquel l'appelant appartient. Les rôles sont utilisés pour diviser la base d'utilisateurs de votre application en plusieurs ensembles d'utilisateurs dotés des mêmes privilèges en matière de sécurité au sein de l'application (Direction générale, Responsables et Employés, par exemple). Les utilisateurs sont ainsi mappés à des rôles. Si un utilisateur est autorisé à effectuer l'opération demandée, l'application utilise des identités fixes pour l'accès aux ressources. Ces identités sont approuvées par les gestionnaires de ressources correspondants (bases de données, système de fichiers, etc.).

  • Autorisation par ressource. Les différentes ressources sont sécurisées au moyen de listes de contrôle d'accès Windows. L'application emprunte l'identité de l'appelant avant d'accéder aux ressources, ce qui permet au système d'exploitation d'effectuer des vérifications d'accès standard. L'accès aux ressources est effectué à l'aide du contexte de sécurité de l'appelant initial. Cette méthode d'emprunt d'identité limite grandement l'évolutivité de l'application, car le regroupement de connexions ne peut pas être utilisé efficacement dans le niveau intermédiaire (« middle-tier ») de l'application.

Dans la plupart des applications Web .NET où l'évolutivité est essentielle, une méthode d'autorisation reposant sur les rôles représente la meilleure solution. Pour certaines applications intranet de plus petite taille qui gèrent le contenu par utilisateur à partir des ressources (telles que des fichiers) et qui peuvent être sécurisées à l'aide de listes de contrôle d'accès Windows appliquées aux utilisateurs individuels, une méthode reposant sur les ressources peut être appropriée.

Le modèle courant et recommandé pour l'autorisation par rôle est le suivant :

  • Authentifiez les utilisateurs dans votre application Web frontale.

  • Mappez les utilisateurs à des rôles.

  • Autorisez l'accès aux opérations (et pas directement aux ressources) en fonction des rôles auxquels les utilisateurs appartiennent.

  • Accédez aux ressources principales nécessaires (requises pour gérer les opérations demandées et autorisées) à l'aide d'identités de service fixes. Les gestionnaires de ressources principales (bases de données, par exemple) approuvent l'application afin qu'elle autorise les appelants et accordent des autorisations à l'identité de service approuvée (ou aux identités de service approuvées).

    Par exemple, un administrateur de base de données peut accorder des autorisations exclusivement à une application de ressources humaines (mais pas à des utilisateurs individuellement).

Remarque : une méthode d'autorisation par rôle au niveau de l'application nécessite également l'utilisation d'une autorisation par ressource pour sécuriser les ressources au niveau du système (les fichiers de configuration, les clés du Registre, etc.).

Informations supplémentaires

  • Pour plus d'informations sur ces deux méthodes d'autorisation, consultez la section « Méthodes d'autorisation » plus loin dans ce module.

  • Pour plus d'informations sur l'autorisation par rôle et les différents types de rôles susceptibles d'être utilisés, consultez la section « Autorisation par rôle » plus loin dans ce module.

Choix des identités utilisées pour l'accès aux ressources

Répondez à la question : « qui accèdera aux ressources ? »

Choisissez l'identité ou les identités qui doivent être utilisées pour accéder aux ressources dans les différentes couches de votre application. Il s'agit des ressources accessibles à partir des applications Web, et éventuellement des services Web, des services Microsoft Enterprise Services et des composants .NET Remoting. Dans tous les cas, l'identité utilisée pour l'accès aux ressources peut être l'une des suivantes :

  • Identité de l'appelant initial. Cette méthode suppose un modèle de délégation ou d'emprunt d'identité dans lequel l'identité de l'appelant initial peut être obtenue puis transmise dans chaque couche de votre système. Le facteur de délégation est un critère clé permettant de déterminer votre mécanisme d'authentification.

  • Identité du processus. Il s'agit du cas par défaut (sans emprunt d'identité spécifique). L'accès aux ressources locales et les appels en aval sont effectués à l'aide de l'identité du processus en cours. La faisabilité de cette méthode dépend des limites qui sont franchies, car l'identité du processus doit être reconnue par le système cible.

    Dans ce cadre, les appels doivent être effectués de l'une des manières suivantes :

    • Dans le même domaine de sécurité Windows

    • Sur différents domaines de sécurité Windows (à l'aide de comptes de domaine et d'approbation, ou de mots de passe et de noms d'utilisateurs en double en l'absence de relation d'approbation)

  • Compte de service. Cette méthode utilise un compte de service (fixe). Par exemple :

    • Pour l'accès à une base de données, il peut s'agir d'un mot de passe et d'un nom d'utilisateur SQL fixes présentés par le composant qui établit une connexion à la base de données.

    • Lorsqu'une identité Windows fixe est requise, utilisez une application serveur Microsoft Enterprise Services.

  • Identité personnalisée. Lorsque vous ne travaillez pas avec des comptes Windows, vous pouvez construire vos propres identités (à l'aide des implémentations de IPrincipal et de IIdentity) qui peuvent contenir des informations associées à votre propre contexte de sécurité. Il peut s'agir, par exemple, de listes de rôles, d'identificateurs uniques ou de tout autre type d'informations personnalisées.
    Si vous utilisez les types IPrincipal et IIdentity pour implémenter votre identité personnalisée et si vous les placez dans le contexte Web actuel (en utilisant HttpContext.User), vous profitez immédiatement des opérateurs de contrôle d'appels intégrés, tels que les rôles .NET et les demandes PrincipalPermission.

Transmission de l'identité

Pour prendre en charge l'autorisation, l'audit et l'extraction des données au niveau de chaque utilisateur, il peut être nécessaire de transmettre l'identité de l'appelant initial dans différents niveaux de l'application et sur plusieurs ordinateurs. Par exemple, si un gestionnaire de ressources principales doit effectuer une autorisation individualisée des appelants, l'identité de l'appelant doit être transmise à ce gestionnaire de ressources.

En fonction des besoins des gestionnaires de ressources en termes d'autorisation et des besoins de votre système en termes d'audit, identifiez les identités qui doivent être transmises dans votre application.

Choix d'une méthode d'authentification

Les facteurs clés qui ont une incidence sur le choix d'une méthode d'authentification sont en tout premier lieu la nature de la base d'utilisateurs de votre application (types de navigateurs qu'ils utilisent et s'ils disposent de comptes Windows), et deuxièmement les besoins en termes d'audit et d'emprunt d'identité ou de délégation de votre application.

Informations supplémentaires

Pour obtenir des informations détaillées qui vous permettront de choisir un mécanisme d'authentification pour votre application, consultez la section « Choix d'un mécanisme d'authentification » plus loin dans ce module.

Choix de la méthode de transmission de l'identité

Vous pouvez transmettre l'identité (pour fournir le contexte de sécurité) au niveau de l'application ou transmettre l'identité et le contexte de sécurité au niveau du système d'exploitation.

Pour transmettre l'identité au niveau de l'application, utilisez des paramètres de procédures stockées et de méthodes. La transmission de l'identité au niveau de l'application gère les opérations suivantes :

  • Extraction des données en fonction de chaque utilisateur à l'aide des paramètres de demandes approuvés

    SELECT x,y FROM SomeTable WHERE username="bernard"
  • Audit personnalisé dans n'importe quel niveau de l'application

La transmission de l'identité au niveau du système d'exploitation gère les opérations suivantes :

  • Audit au niveau de la plate-forme (audit Windows et audit SQL Server, par exemple)

  • Autorisation de chaque utilisateur en fonction des identités Windows

Pour transmettre l'identité au niveau du système d'exploitation, vous pouvez utiliser le modèle d'emprunt d'identité ou de délégation. Dans certaines circonstances, vous pouvez utiliser la délégation Kerberos, tandis que dans d'autres cas (lorsque l'environnement ne prend pas en charge Kerberos), vous devrez peut-être opter pour d'autres méthodes, telles que l'authentification de base. Dans le cadre de l'authentification de base, les informations d'identification de l'utilisateur sont à la disposition de l'application serveur et peuvent être utilisées pour accéder aux ressources réseau en aval.

Informations supplémentaires

Pour plus d'informations sur la transmission de l'identité et la méthode permettant d'obtenir un jeton d'emprunt d'identité à l'aide des informations d'identification réseau (prise en charge de la délégation), consultez la section « Transmission de l'identité » plus loin dans ce module.

Méthodes d'autorisation

Les deux principales méthodes d'autorisation sont les suivantes :

  • Autorisation par rôle. Les utilisateurs sont répartis au sein de rôles logiques, définis par l'application. Les membres d'un rôle particulier ont les mêmes privilèges au sein de l'application. L'accès aux opérations (en principe exprimé par des appels de méthodes) est autorisé en fonction du rôle auquel l'appelant appartient.
    Les ressources sont accessibles à l'aide d'identités fixes (telles que l'identité d'un processus de service Web ou d'une application Web). Les gestionnaires de ressources approuvent l'application afin qu'elle autorise les utilisateurs, puis ils autorisent l'identité approuvée.

  • Autorisation par ressource. Les différentes ressources sont sécurisées au moyen de listes de contrôle d'accès Windows. La liste de contrôle d'accès détermine les utilisateurs qui sont autorisés à accéder à la ressource, ainsi que les types d'opérations que chaque utilisateur est autorisé à effectuer (lecture, écriture, suppression, etc.).
    Les ressources sont accessibles à l'aide de l'identité de l'appelant initial (au moyen de l'emprunt d'identité).

Autorisation par rôle

Dans le cadre d'une sécurité s'appuyant sur les rôles (ou opérations), l'accès aux opérations (pas aux ressources principales) est autorisé en fonction des rôles auxquels l'appelant appartient. Les rôles (analysés et définis lors de la conception de l'application) sont utilisés comme conteneurs logiques qui regroupent les utilisateurs partageant les mêmes privilèges (ou fonctionnalités) de sécurité au sein de l'application. Les utilisateurs sont mappés à des rôles dans l'application et ces associations permettent de gérer l'accès à des opérations spécifiques (méthodes) mises à disposition par l'application.

L'emplacement auquel ce mappage des rôles a lieu dans votre application est un critère de conception essentiel. Par exemple :

  • D'un côté, le mappage des rôles peut être effectué dans un gestionnaire de ressources principales tel qu'une base de données. Cette opération nécessite la transmission du contexte de sécurité de l'appelant initial dans les niveaux de votre application vers la base de données principale.

  • D'un autre côté, le mappage des rôles peut être effectué dans votre application Web frontale. Avec cette méthode, l'accès aux gestionnaires de ressources en aval est effectué à l'aide d'identités fixes que chaque gestionnaire de ressources autorise et est prêt à approuver.

  • La troisième option consiste à effectuer le mappage des rôles quelque part entre les niveaux principal et frontal, dans une application Microsoft Enterprise Services de niveau intermédiaire, par exemple.

Dans les applications Web constituées de plusieurs niveaux, l'utilisation des identités approuvées pour accéder aux gestionnaires de ressources principales offrent de plus grandes possibilités d'évolutivité de l'application (grâce au regroupement des connexions). Qui plus est, grâce à l'utilisation des identités approuvées, la transmission du contexte de sécurité de l'appelant initial au niveau du système d'exploitation n'est plus aussi importante (cette opération peut être difficile, voire impossible à réaliser dans certains scénarios).

Autorisation par ressource

La méthode d'autorisation par ressource repose sur les listes de contrôle d'accès Windows et les mécanismes de contrôle d'accès sous-jacents du système d'exploitation. L'application emprunte l'identité de l'appelant et la confie au système d'exploitation avec des gestionnaires de ressources spécifiques (le système de fichiers, des bases de données, etc.) pour effectuer les vérifications d'accès.

Cette méthode est généralement la plus adaptée pour les applications qui offrent un accès à des ressources susceptibles d'être sécurisées individuellement à l'aide de listes de contrôle d'accès Windows, comme des fichiers. Il peut s'agir, par exemple, d'une application FTP ou d'une application Web simple pilotée par les données. Cette méthode n'est plus aussi efficace lorsque la ressource demandée est constituée de données qui doivent être obtenues et regroupées à partir de différentes sources (plusieurs bases de données, tables de base de données, applications externes ou applications Web, par exemple).

La méthode par ressource repose également sur la transmission du contexte de sécurité de l'appelant initial dans l'application jusqu'aux gestionnaires de ressources principales. Elle peut nécessiter une configuration complexe et diminuer considérablement la capacité d'une application à plusieurs niveaux à s'adapter à un grand nombre d'utilisateurs, car elle empêche l'utilisation efficace du regroupement (le regroupement de connexions à une base de données, par exemple) dans le niveau intermédiaire (« middle-tier ») de l'application.

Modèles d'accès aux ressources

Les deux méthodes d'autorisation peuvent être observées dans les deux modèles d'accès aux ressources les plus utilisés par les applications Web .NET (et les applications distribuées à plusieurs niveaux en général). Ces modèles sont les suivants :

  • Modèle de sous-système approuvé

  • Modèle d'emprunt d'identité ou de délégation

Chaque modèle offre des avantages et des inconvénients du point de vue de la sécurité et de l'évolutivité. Ces modèles sont décrits dans les sections suivantes.

Modèle de sous-système approuvé

Dans le cadre de ce modèle, le service de niveau intermédiaire (« middle-tier ») utilise une identité fixe pour accéder aux services et aux ressources en aval. Le contexte de sécurité de l'appelant initial n'est pas transmis dans le service au niveau du système d'exploitation, bien que l'application puisse choisir de transmettre l'identité de l'appelant initial au niveau de l'application. Cette procédure peut être nécessaire pour la prise en charge des besoins en termes d'audit principal ou de l'autorisation et de l'accès aux données pour chaque utilisateur.

Le nom du modèle provient du fait que le service en aval (peut-être une base de données) approuve le service en amont afin qu'il autorise les appelants. Ce modèle est présenté dans la figure 3.1. Faites tout particulièrement attention à la limite de confiance. Dans cet exemple, la base de données approuve le niveau intermédiaire (« middle-tier ») pour autoriser les appelants et permettre uniquement aux appelants habilités d'accéder à la base de données à l'aide de l'identité approuvée.

 Modèle de sous-système approuvé

Figure 3.1
Modèle de sous-système approuvé

Le mode d'accès aux ressources dans le modèle de sous-système approuvé est le suivant :

  • Authentification des utilisateurs

  • Mappage des utilisateurs à des rôles

  • Autorisation accordée en fonction de l'appartenance à des rôles

  • Accès au gestionnaire de ressources en aval à l'aide d'une identité approuvée fixe

Identités fixes

L'identité fixe utilisée pour accéder aux gestionnaires de ressources et aux systèmes en aval est souvent fournie par un compte Windows préconfiguré, appelé compte de service. Avec un gestionnaire de ressources Microsoft SQL Server?, cela implique l'authentification Windows auprès de SQL Server.

Certaines applications utilisent également un compte SQL nommé (spécifié par un nom d'utilisateur et un mot de passe dans une chaîne de connexion) pour accéder à SQL Server. Dans ce scénario, la base de données doit être configurée pour l'authentification SQL.

Pour plus d'informations sur les avantages respectifs de l'authentification Windows et de l'authentification SQL lors de la communication avec SQL Server, consultez le Module 12, « Sécurité de l'accès aux données ».

Utilisation de plusieurs identités approuvées

Il est possible que certains gestionnaires de ressources aient besoin d'effectuer une autorisation légèrement plus précise, en fonction du rôle auquel appartient l'appelant. Par exemple, vous pouvez avoir deux groupes d'utilisateurs, l'un devant être autorisé à effectuer des opérations de lecture/écriture et l'autre devant être habilité à effectuer uniquement des opérations de lecture.

Envisageons la méthode suivante avec SQL Server :

  • Créez deux comptes Windows, l'un pour des opérations de lecture et l'autre pour des opérations de lecture/écriture.
    Généralement, vous disposez de comptes séparés pour refléter les rôles spécifiques aux applications. Vous pouvez par exemple utiliser un compte pour les utilisateurs Internet et un autre compte pour les opérateurs et/ou les administrateurs internes.

  • Mappez chaque compte à un rôle de base de données SQL Server défini par l'utilisateur et définissez les autorisations de base de données nécessaires pour chaque rôle.

  • Mappez les utilisateurs aux rôles dans votre application et utilisez l'appartenance aux rôles pour déterminer le compte dont l'identité doit être empruntée avant la connexion à la base de données.

La figure 3.2 ci-dessous illustre cette méthode.

 Utilisation de plusieurs identités pour accéder à une base de données afin de permettre une autorisation plus précise

Figure 3.2
Utilisation de plusieurs identités pour accéder à une base de données afin de permettre une autorisation plus précise

Modèle d'emprunt d'identité ou de délégation

Dans le cadre de ce modèle, un service ou un composant (généralement au sein de la couche logique des services métier) emprunte l'identité du client (à l'aide de l'emprunt d'identité au niveau du système d'exploitation) avant d'accéder au service en aval suivant. Si le service suivant figure sur le même ordinateur, l'emprunt d'identité est suffisant. La délégation est nécessaire si le service en aval est situé sur un ordinateur distant.

En réponse à la délégation, le contexte de sécurité utilisé pour l'accès aux ressources en aval est celui du client. Ce modèle est généralement utilisé pour plusieurs raisons :

  • Il permet au service en aval d'effectuer une autorisation individuelle pour les appelants à l'aide de l'identité de l'appelant initial.

  • Il permet au service en aval d'utiliser les fonctionnalités d'audit au niveau du système d'exploitation.

Comme exemple concret de cette technique, un composant Microsoft Enterprise Services du niveau intermédiaire peut emprunter l'identité de l'appelant avant d'accéder à une base de données. La base de données est accessible à l'aide d'une connexion de base de données liée au contexte de sécurité de l'appelant initial. Dans le cadre de ce modèle, la base de données authentifie chaque appelant et prend des décisions d'autorisation en fonction des autorisations affectées à l'identité de l'appelant (ou de l'appartenance aux groupes Windows de l'appelant). Le modèle d'emprunt d'identité ou de délégation est présenté dans la figure 3.3.

Modèle d'emprunt d'identité ou de délégation

Figure 3.3
Modèle d'emprunt d'identité ou de délégation

Choix d'un modèle d'accès aux ressources

Le modèle de sous-système approuvé est utilisé dans la grande majorité des applications Internet et des applications intranet importantes, principalement pour des raisons d'évolutivité. Le modèle d'emprunt d'identité a tendance à être utilisé pour des applications de plus petite taille, pour lesquelles l'évolutivité n'est pas un facteur important, et pour des applications pour lesquelles l'audit est un facteur essentiel (pour des raisons de non-répudiation).

Avantage du modèle d'emprunt d'identité ou de délégation

Le principal avantage du modèle d'emprunt d'identité ou de délégation réside dans la capacité d'audit (proche des données). L'audit permet aux administrateurs de savoir quels utilisateurs ont tenté d'accéder à des ressources spécifiques. En général, on considère que la procédure d'audit fait vraiment autorité si les audits sont générés au moment précis de l'accès à la ressource et par les même routines que celles qui accèdent à la ressource.

Le modèle d'emprunt d'identité ou de délégation gère cet aspect en conservant le contexte de sécurité de l'utilisateur pour l'accès aux ressources en aval. Le système principal peut ainsi connecter d'autorité l'utilisateur et l'accès demandé.

Inconvénients du modèle d'emprunt d'identité ou de délégation

Les inconvénients que présente le modèle d'emprunt d'identité ou de délégation sont les suivants :

  • Enjeux technologiques. La plupart des fournisseurs de service de sécurité ne prennent pas en charge la délégation, Kerberos étant l'exception notoire.
    Les processus qui font appel à l'emprunt d'identité nécessitent des privilèges élevés (plus particulièrement le privilège Fonctionner en tant que partie intégrante du système d'exploitation). Cette restriction s'applique à Windows 2000 et ne s'appliquera pas à Windows .NET Server.

  • Évolutivité. Avec le modèle d'emprunt d'identité ou de délégation, vous ne pouvez pas utiliser efficacement le regroupement de connexions à une base de données, car l'accès à la base de données s'effectue à l'aide de connexions qui sont liées aux contextes de sécurité des différents appelants initiaux. Cela limite de manière significative la capacité de l'application à s'adapter à un grand nombre d'utilisateurs.

  • Administration plus lourde. Les listes de contrôle d'accès sur les ressources principales doivent être gérées de telle sorte qu'un niveau d'accès approprié soit accordé à chaque utilisateur. Lorsque le nombre de ressources principales augmente (ainsi que le nombre d'utilisateurs), un effort d'administration important est nécessaire pour gérer les listes de contrôle d'accès.

Avantages du modèle de sous-système approuvé

Le modèle de sous-système approuvé offre les avantages suivants :

  • Évolutivité. Le modèle de sous-système approuvé gère le regroupement de connexions, critère essentiel de l'évolutivité des applications. Le regroupement de connexions permet à plusieurs clients de réutiliser les connexions regroupées disponibles. Il fonctionne avec ce modèle car l'accès à toutes les ressources principales utilise le contexte de sécurité du compte de service, indépendamment de l'identité de l'appelant.

  • Gestion plus simple des listes de contrôle d'accès principales. Seul le compte de service accède aux ressources principales (des bases de données, par exemple). Les listes de contrôle d'accès sont configurées par rapport à cette identité unique.

  • Pas d'accès direct des utilisateurs aux données. Dans le modèle de sous-système approuvé, seul le compte de service du niveau intermédiaire est autorisé à accéder aux ressources principales. Par conséquent, les utilisateurs ne peuvent pas accéder aux données principales sans passer par l'application (et être soumis à l'autorisation de celle-ci).

Inconvénients du modèle de sous-système approuvé

Les deux inconvénients du modèle de sous-système approuvé sont les suivants :

  • Audit. Pour procéder à l'audit au niveau principal, vous pouvez transmettre explicitement (au niveau de l'application) l'identité de l'appelant initial au niveau principal, et l'audit peut être effectué à ce stade. Vous devez approuver le niveau intermédiaire (« middle-tier ») et vous êtes confronté à un risque potentiel de répudiation. Vous pouvez également générer un journal d'audit dans le niveau intermédiaire puis l'associer aux journaux d'audit principaux (pour ce faire, vous devez vous assurer que les horloges des serveurs sont synchronisées).

  • Risque accru en cas d'atteinte à l'intégrité d'un serveur. Dans le modèle de sous-système approuvé, le service de niveau intermédiaire bénéficie d'un accès étendu aux ressources principales. Par conséquent, si un service de niveau intermédiaire n'est plus sûr, il peut être potentiellement plus facile pour un utilisateur malveillant d'obtenir un accès étendu aux ressources principales.

Transmission de l'identité

Les applications distribuées peuvent être subdivisées en de nombreux sous-systèmes sécurisés. Par exemple, une application Web frontale, un service Web de niveau intermédiaire, un composant distant et une base de données constituent quatre sous-systèmes de sécurité différents. Chacun effectue des opérations d'authentification et d'autorisation.

Vous devez identifier les sous-systèmes qui doivent transmettre l'identité de l'appelant (et le contexte de sécurité associé) au sous-système en aval suivant afin de prendre en charge l'autorisation de l'appelant initial.

Transmission de l'identité au niveau de l'application ou au niveau du système d'exploitation

Les stratégies de transmission des identités comprennent l'utilisation des fonctions de délégation du système d'exploitation ou la transmission de tickets et/ou d'informations d'identification au niveau de l'application. Par exemple :

  • Pour transmettre l'identité au niveau de l'application, vous transmettez en principe des informations d'identification (ou tickets) à l'aide d'arguments de méthodes ou de paramètres de procédures stockées.

    Remarque : les objets GenericPrincipal qui contiennent l'identité de l'appelant authentifié ne sont pas transmis automatiquement au sein des processus. Un code personnalisé est nécessaire.

    Vous pouvez transmettre des paramètres aux procédures stockées, qui permettent d'extraire et de traiter les données spécifiques aux utilisateurs. Par exemple :

    SELECT CreditLimit From Table Where UserName="Bernard"
    

    Cette méthode est parfois appelée méthode de paramètre de demande approuvé.

  • La transmission de l'identité au niveau du système d'exploitation nécessite une forme étendue de l'emprunt d'identité, appelée délégation.

Emprunt d'identité et délégation

Dans des circonstances normales, les threads au sein d'une application serveur sont exécutés à l'aide du contexte de sécurité du processus serveur. Les attributs qui comprennent le contexte de sécurité du processus sont gérés par la session de connexion du processus et sont mis à disposition par le jeton d'accès Windows au niveau du processus. L'accès à toutes les ressources locales et distantes s'effectue à l'aide du contexte de sécurité au niveau du processus, qui est déterminé par le compte Windows utilisé pour exécuter le processus serveur.

Emprunt d'identité

Lorsqu'une application serveur est configurée pour l'emprunt d'identité, un jeton d'emprunt d'identité est associé au thread utilisé pour traiter une demande. Le jeton d'emprunt d'identité représente le contexte de sécurité de l'appelant authentifié (ou utilisateur anonyme). L'accès aux ressources locales s'effectue à l'aide du jeton d'emprunt d'identité du thread, qui entraîne l'utilisation du contexte de sécurité de l'appelant.

Délégation

Si le thread de l'application serveur tente d'accéder à une ressource distante, la délégation est nécessaire. Plus précisément, le jeton de l'appelant dont l'identité a été empruntée doit être associé à des informations d'identification réseau. Dans le cas contraire, l'accès à toutes les ressources distantes est effectué en tant qu'utilisateur anonyme (AUTHORITY\ANONYMOUS LOGON).

Différents facteurs déterminent si un contexte de sécurité peut être délégué ou non. Le tableau 3.1 présente les différents types d'authentification IIS et indique, pour chaque type, si le contexte de sécurité de l'appelant authentifié peut être délégué ou non.

Tableau 3.1 : Types d'authentification IIS

Type d'authentification

Délégation possible

Remarques

Authentification anonyme

Variable

Si le compte anonyme (par défaut IUSR_MACHINE) est configuré dans IIS en tant que compte local, il ne peut pas être délégué sauf si l'ordinateur distant et l'ordinateur local (serveur Web) disposent de comptes locaux identiques (avec des noms d'utilisateurs et des mots de passe correspondants).
Si le compte anonyme est un compte de domaine, il peut être délégué.

Authentification de base

Oui

Si l'authentification de base est utilisée avec des comptes locaux, elle peut être déléguée si les comptes locaux sur l'ordinateur local et distant sont identiques. Les comptes de domaine peuvent également être délégués.

Authentification Digest

Non

 

Authentification intégrée de Windows

Variable

L'authentification intégrée de Windows implique l'authentification NTLM ou Kerberos (en fonction de la version du système d'exploitation sur l'ordinateur client et serveur).
NTLM ne gère pas la délégation.
Kerberos gère la délégation si l'environnement est correctement configuré.
Pour plus d'informations, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » dans ce guide.

Authentification par certificats clients

Variable

La délégation est possible si elle est utilisée avec le mappage de certificats IIS et que le certificat est mappé à un compte local dupliqué sur l'ordinateur distant ou à un compte de domaine.
Les informations d'identification du compte mappé sont ainsi stockées sur le serveur local et sont utilisées pour créer une connexion interactive (qui dispose d'informations d'identification réseau).
Le mappage de certificats Active Directory ne gère pas la délégation.

Important : la délégation Kerberos sur Windows 2000 n'est pas limitée. En d'autres termes, un utilisateur peut être en mesure de parcourir plusieurs tronçons réseau sur plusieurs ordinateurs distants. Pour éliminer ce risque de sécurité potentiel, vous devez limiter la portée du compte de domaine en supprimant le compte du groupe Utilisateurs du domaine et autoriser l'utilisation du compte uniquement pour la connexion à des ordinateurs spécifiques.

Autorisation par rôle

La plupart des applications Web .NET utilisent une méthode d'autorisation par rôle. Vous devez prendre en compte les différents types de rôles et choisir les plus appropriés au scénario de votre application. Les options disponibles sont les suivantes :

  • Rôles .NET

  • Rôles Microsoft Enterprise Services (COM+)

  • Rôles de base de données SQL Server définis par l'utilisateur

  • Rôles d'application SQL Server

Rôles .NET

Les rôles .NET sont extrêmement souples et s'articulent autour des objets IPrincipal qui contiennent la liste des rôles auxquels une identité authentifiée appartient. Les rôles .NET peuvent être utilisés dans des applications Web, des services Web ou des composants distants hébergés dans ASP.NET (et accessibles à l'aide de HttpChannel).

Vous pouvez procéder à l'autorisation à l'aide des rôles .NET, soit de manière déclarative à l'aide de demandes PrincipalPermission , soit par programmation dans le code à l'aide de demandes PrincipalPermission impératives ou de la méthode IPrincipal.IsInRole.

Rôles .NET avec l'authentification Windows

Si votre application utilise l'authentification Windows, ASP.NET construit automatiquement un objet WindowsPrincipal qui est associé au contexte de la demande Web active (à l'aide de HttpContext.User). Une fois que le processus d'authentification est terminé et que ASP.NET a associé l'objet à la demande active, ce dernier est utilisé pour toutes les autorisations par rôle .NET ultérieures.

L'appartenance aux groupes Windows de l'appelant authentifié permet de déterminer l'ensemble de rôles. Dans le cadre de l'authentification Windows, les rôles .NET sont identiques aux groupes Windows.

Rôles .NET avec une authentification autre que Windows

Si votre application utilise un mécanisme d'authentification autre que Windows, tel que l'authentification par formulaires ou l'authentification Passport, vous devez rédiger un code pour créer un objet GenericPrincipal (ou un objet IPrincipal personnalisé) et le peupler avec un ensemble de rôles obtenu à partir d'un magasin de données d'authentification personnalisé tel qu'une base de données SQL Server.

Objets IPrincipal personnalisés

Le mécanisme de sécurité qui s'appuie sur les rôles .NET est extensible. Vous pouvez développer des classes qui implémentent des objets IPrincipal et IIdentity et proposer vos propres fonctionnalités d'autorisation par rôle étendues.

Dans la mesure où l'objet IPrincipal personnalisé (contenant les rôles obtenus à partir d'un magasin de données personnalisé) est associé au contexte de la demande active (à l'aide de HttpContext.User), les fonctionnalités de base de vérification des rôles sont assurées.

Si vous implémentez l'interface IPrincipal, vous garantissez que les formes impératives et déclaratives des demandes PrincipalPermission fonctionnent avec votre identité personnalisée. De plus, vous pouvez implémenter des règles étendues de sémantique de rôles, par exemple en proposant une méthode supplémentaire telle que IsInMultipleRoles( string [] roles ) qui vous permet de tester et d'affirmer l'appartenance à plusieurs rôles.

Informations supplémentaires

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

  • Pour plus d'informations sur la création d'objets GenericPrincipal, consultez la section « Procédure : Créer des objets GenericPincipal avec l'authentification par formulaires » dans ce guide.

Rôles Microsoft Enterprise Services (COM+)

L'utilisation de rôles Microsoft Enterprise Services (COM+) étend les vérifications d'accès au niveau intermédiaire (« middle-tier ») et permet d'utiliser le regroupement de connexions à des bases de données lorsque vous établissez une connexion à des bases de données principales. Toutefois, pour une véritable autorisation par rôle Microsoft Enterprise Services (COM+), votre application Web frontale doit emprunter l'identité de l'appelant initial et la transmettre (à l'aide d'un jeton d'accès Windows) à l'application Microsoft Enterprise Services. Pour ce faire, les entrées suivantes doivent être insérées dans le fichier Web.config de l'application Web.

<authentication mode="Windows" />
<identity impersonate="true" />

Si les vérifications déclaratives au niveau de la méthode sont suffisantes (pour déterminer les utilisateurs qui peuvent appeler certaines méthodes), vous devez déployer votre application et mettre à jour l'appartenance aux rôles à l'aide de l'outil d'administration Services de composants.

Si des vérifications par programmation sont requises dans le code de la méthode, vous perdez certains avantages en termes d'administration et de déploiement des rôles Microsoft Enterprise Services (COM+), car la logique des rôles est codée de manière irréversible.

Rôles de base de données SQL Server définis par l'utilisateur

Dans le cadre de cette méthode, vous devez créer des rôles dans la base de données, affecter des autorisations en fonction des rôles et mapper les comptes d'utilisateurs et de groupes Windows aux rôles. Vous devez transmettre l'identité de l'appelant à la base de données principale (si vous utilisez l'authentification Windows recommandée pour SQL Server).

Rôles d'applications SQL Server

Dans le cadre de cette méthode, les autorisations sont accordées aux rôles dans la base de données, mais les rôles d'applications SQL Server ne contiennent aucun compte d'utilisateur ou de groupe. Par conséquent, vous perdez les détails relatifs à l'appelant initial.

Les rôles d'applications vous permettent d'autoriser l'accès à une application spécifique (contrairement à un ensemble d'utilisateurs). L'application active le rôle à l'aide d'une procédure stockée intégrée qui accepte un mot de passe et un nom de rôle. L'un des principaux inconvénients de cette méthode réside dans le fait que l'application doit gérer de manière sécurisée les informations d'identification (le nom de rôle et le mot de passe associé).

Informations supplémentaires

Pour plus d'informations sur les rôles d'application et les rôles de base de données SQL Server définis par l'utilisateur, consultez le Module 12, « Sécurité de l'accès aux données ».

Comparaison des rôles .NET et des rôles Microsoft Enterprise Services (COM+)

Le tableau suivant compare les fonctionnalités des rôles .NET et des rôles Microsoft Enterprise Services (COM+).

Tableau 3.2 : Comparaison des rôles Microsoft Enterprise Services et des rôles .NET

Fonctionnalité

Rôles Microsoft Enterprise Services

Rôles .NET

Administration

Outil d'administration Services de composants

Personnalisée

Magasin de données

Catalogue COM+

Magasin de données personnalisé (SQL Server ou Active Directory, par exemple)

Déclarative

Oui
[SecurityRole("Responsable")]

Oui
[PrincipalPermission( SecurityAction.Demand,Role="Responsable")]

Impérative

Oui
ContextUtil.IsCallerInRole()

Oui
IPrincipal.IsInRole

Granularité au niveau de la méthode, de la classe et de l'interface

Oui

Oui

Extensible

Non

Oui
(à l'aide de l'implémentation IPrincipal personnalisée)

Disponible pour tous les composants .NET

Uniquement pour les composants issus de la classe de base ServicedComponent

Oui

Appartenance à des rôles

Les rôles contiennent des comptes de groupes ou d'utilisateurs Windows.

Lors de l'utilisation de WindowsPrincipals, les rôles SONT des groupes Windows (aucun niveau supplémentaire d'abstraction).

Exige l'implémentation explicite d'une interface

Oui
Pour obtenir une autorisation au niveau de la méthode, vous devez définir et développer explicitement une interface.

Non

Utilisation des rôles .NET

Vous pouvez sécuriser les éléments suivants à l'aide des rôles .NET :

  • Fichiers

  • Dossiers

  • Pages Web (fichiers .aspx)

  • Services Web (fichiers .asmx)

  • Objets

  • Méthodes et propriétés

  • Blocs de code dans les méthodes

L'utilisation de rôles .NET pour protéger des opérations (effectuées par des méthodes et des propriétés) et des blocs de code spécifiques implique que vous pouvez protéger l'accès aux ressources locales et distantes auxquelles votre application accède.

Remarque : les quatre premiers éléments de la liste précédente (fichiers, dossiers, pages Web et services Web) sont protégés à l'aide de UrlAuthorizationModule, qui peut utiliser l'appartenance aux rôles de l'appelant (et l'identité de ce dernier) pour prendre des décisions en matière d'autorisation.

Si vous utilisez l'authentification Windows, la majeure partie du travail nécessaire pour utiliser les rôles .NET est effectuée automatiquement. ASP.NET construit un objet WindowsPrincipal et l'appartenance aux groupes Windows de l'utilisateur détermine les rôles associés.

Si vous utilisez des rôles .NET avec un mécanisme d'authentification autre que Windows, vous devez rédiger un code pour :

  • obtenir les informations d'identification de l'utilisateur ;

  • valider les informations d'identification de l'utilisateur auprès d'un magasin de données personnalisé tel qu'une base de données SQL Server ;

  • extraire une liste de rôles, construire un objet GenericPrincipal et l'associer à la demande Web active.
    L'objet GenericPrincipal représente l'utilisateur authentifié et est utilisé pour les vérifications ultérieures de rôles .NET, telles que les demandes déclaratives PrincipalPermission et les vérifications par programmation IPrincipal.IsInRole.

Informations supplémentaires

Pour plus d'informations sur le processus qu'implique la création d'un objet GenericPrincipal dans le cadre de l'authentification par formulaires, consultez le Module 8, « Sécurité ASP.NET ».

Vérification de l'appartenance aux rôles

Les types suivants de vérifications de rôles .NET sont disponibles :

Important : la vérification des rôles .NET repose sur l'association d'un objet IPrincipal (représentant l'utilisateur authentifié) avec la demande active. Dans les applications Web ASP.NET, l'objet IPrincipal doit être associé à HttpContext.User. Dans les applications Windows Forms, l'objet IPrincipal doit être associé à Thread.CurrentPrincipal.

  • Vérifications manuelles des rôles. Pour une autorisation plus précise, vous pouvez appeler la méthode IPrincipal.IsInRole afin d'autoriser l'accès à des blocs de code spécifiques en fonction des rôles auxquels l'appelant appartient. Vous pouvez utiliser les deux opérateurs logiques AND et OR lors de la vérification de l'appartenance aux rôles.

  • Vérifications déclaratives des rôles (passerelles vers vos méthodes). Vous pouvez annoter les méthodes avec la classe PrincipalPermissionAttribute (qui peut être abrégée en PrincipalPermission) pour demander de manière déclarative les rôles auxquels un appelant appartient. Seul l'opérateur logique OR est pris en charge. Par exemple, vous pouvez exiger qu'un appelant figure au moins dans un rôle spécifique (par exemple, l'appelant doit correspondre à un rôle Guichetier ou un rôle Responsable). En revanche, vous ne pouvez pas utiliser de vérifications déclaratives pour spécifier que l'appelant doit correspondre à la fois à un rôle Responsable et à un rôle Guichetier.

  • Vérifications impératives des rôles (vérifications dans vos méthodes). Vous pouvez appeler PrincipalPermission.Demand dans le code pour appliquer une logique d'autorisation précise. Les opérateurs logiques AND et OR sont pris en charge.

Exemples de vérification de rôles

Les fragments de code suivants présentent quelques exemples de vérification de rôles à l'aide des techniques impérative, déclarative et par programmation.

Autoriser Bernard à effectuer une opération :

Remarque : bien que vous puissiez autoriser les utilisateurs individuellement, il est généralement conseillé de procéder à l'autorisation en fonction de l'appartenance aux rôles, ce qui vous permet d'autoriser des groupes d'utilisateurs partageant les mêmes privilèges au sein de votre application.

  • Vérification directe du nom de l'utilisateur

        GenericIdentity userIdentity = new GenericIdentity("Bernard");
        if (userIdentity.Name=="Bernard")
        {
        }
    
  • Vérification déclarative

        [PrincipalPermissionAttribute(SecurityAction.Demand, User="Bernard")]
        public void DoPrivilegedMethod()
        {
        }
    
  • Vérification impérative

        PrincipalPermission permCheckUser = new PrincipalPermission(
                                                       "Bernard", null);
        permCheckUser.Demand();
    

Autoriser les personnes associées au rôle Guichetier à effectuer une opération :

  • Vérification directe du nom de rôle

        GenericIdentity userIdentity = new GenericIdentity("Bernard");
        // Les noms de rôles doivent être extraits à partir d'un magasin de données.
        string[] roles = new String[]{"Responsable", "Guichetier"};
        GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity, 
                                                              roles);
        if (userPrincipal.IsInRole("Guichetier"))
        {
        }
    
  • Vérification déclarative

        [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Guichetier")]
        void SomeTellerOnlyMethod()
        {
        }
    
  • Vérification impérative

        public SomeMethod()
        {
          PrincipalPermission permCheck = new PrincipalPermission(
                                                       null,"Guichetier");
          permCheck.Demand();
          // Seuls les guichetiers peuvent exécuter le code suivant.
          // Les utilisateurs qui ne sont pas associés au rôle Guichetier entraînent une exception de sécurité.
          . . .
        }
    

Autoriser les personnes associées au rôle Responsable OU les personnes associées au rôle Guichetier à effectuer une opération :

  • Vérification directe du nom de rôle

        if (Thread.CurrentPrincipal.IsInRole("Guichetier") ||
            Thread.CurrentPrincipal.IsInRole("Responsable"))
        {
          // Effectuer des opérations associées à des privilèges.
        }
    
  • Vérification déclarative

        [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Guichetier"),
         PrincipalPermissionAttribute(SecurityAction.Demand, Role="Responsable")]
        public void DoPrivilegedMethod()
        {
        ...
        }
    
  • Vérification impérative

        PrincipalPermission permCheckTellers = new PrincipalPermission( 
                                                           null,"Guichetier");
        PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                           null,"Responsable");
       (permCheckTellers.Union(permCheckManagers)).Demand();
    

Autoriser uniquement les personnes associées aux rôles Responsable ET Guichetier à effectuer une opération :

  • Vérification directe du nom de rôle

        if (Thread.CurrentPrincipal.IsInRole("Guichetier") &&
            Thread.CurrentPrincipal.IsInRole("Responsable"))
        {
          // Effectuer une opération associée à des privilèges
        }
    
  • Vérification déclarative

    Il n'est pas possible d'effectuer des vérifications AND déclaratives avec les rôles .NET. Le cumul de demandes PrincipalPermission implique l'utilisation de l'opérateur logique OR.

  • Vérification impérative

        PrincipalPermission permCheckTellers = new PrincipalPermission(
                                                         null,"Guichetier");
        permCheckTellers.Demand();  
        PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                         null, "Responsable");
        permCheckManagers.Demand();
    

Choix d'un mécanisme d'authentification

Cette section présente des conseils destinés à vous permettre de choisir un mécanisme d'authentification approprié aux scénarios d'applications courants. Pour commencer, vous devez prendre en compte les considérations suivantes :

  • Identités. Un mécanisme d'authentification Windows est approprié uniquement si les utilisateurs de votre application disposent de comptes Windows qui peuvent être authentifiés par une autorité approuvée à laquelle le serveur Web de votre application peut accéder.

  • Gestion des informations d'identification. L'un des principaux avantages de l'authentification Windows réside dans le fait que vous pouvez laisser au système d'exploitation le soin de prendre en charge la gestion des informations d'identification. Dans le cadre des méthodes d'authentification autres que Windows, telles que l'authentification par formulaires, vous devez planifier avec soin l'emplacement et le mode de stockage des informations d'identification des utilisateurs. Les deux méthodes les plus courantes consistent à utiliser :

    • des bases de données SQL Server ;

    • des objets utilisateur dans Active Directory.

    Pour plus d'informations sur les questions de sécurité concernant l'utilisation de SQL Server en tant que magasin d'informations d'identification, consultez le Module 12, « Sécurité de l'accès aux données ».

    Pour plus d'informations sur l'authentification par formulaires auprès de magasins de données personnalisés (notamment Active Directory), consultez le Module 8, « Sécurité ASP.NET ».

  • Transmission de l'identité. Devez-vous implémenter un modèle d'emprunt d'identité ou de délégation et transmettre au système d'exploitation le contexte de sécurité de l'appelant initial sur différents niveaux (ou couches) ? Par exemple, pour gérer l'audit ou l'autorisation par utilisateur (précise). Dans ce cas, vous devez être en mesure d'emprunter l'identité de l'appelant et de déléguer son contexte de sécurité au sous-système en aval suivant, comme le décrit le paragraphe « Délégation » de la section « Transmission de l'identité », plus haut dans ce module.

  • Type de navigateur. Vos utilisateurs disposent-ils tous de Microsoft Internet Explorer ou devez-vous prendre en charge une base d'utilisateurs utilisant différents types de navigateurs ? Le tableau 3.3 présente les mécanismes d'authentification qui nécessitent des navigateurs Internet Explorer et ceux qui gèrent divers types de navigateurs courants.

Tableau 3.3 : Configuration requise en termes de navigateur pour l'authentification

Type d'authentification

Internet Explorer nécessaire

Remarques

Par formulaires

Non

 

Passport

Non

 

Intégrée de Windows (Kerberos ou NTLM)

Oui

Kerberos nécessite Windows 2000 ou des systèmes d'exploitation ultérieurs sur les ordinateurs serveur et client ainsi que des comptes configurés pour la délégation. Pour plus d'informations, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » dans ce guide.

Authentification de base

Non

L'authentification de base fait partie du protocole HTTP 1.1 qui est géré par pratiquement tous les navigateurs.

Authentification Digest

Oui

 

Par certificats

Non

Les clients nécessitent des certificats X.509.

Scénarios Internet

Les principales hypothèses de départ dans le cadre des scénarios Internet sont les suivantes :

  • Les utilisateurs ne disposent pas de comptes Windows dans le domaine du serveur ou dans un domaine approuvé accessible au serveur.

  • Les utilisateurs ne disposent pas de certificats clients.

La figure 3.4 présente une arborescence de décision permettant de choisir un mécanisme d'authentification pour les scénarios Internet.

Choix d'un mécanisme d'authentification pour les applications Internet

Figure 3.4
Choix d'un mécanisme d'authentification pour les applications Internet

Pour plus d'informations sur la sécurité des services Web et la spécification WS-Security de l'initiative GXA (Global XML Architecture), consultez le Module 10, « Sécurité des services Web ».

Comparaison de l'authentification par formulaires et de l'authentification Passport

Cette section répertorie les avantages respectifs de l'authentification par formulaires et de l'authentification Passport.

Avantages de l'authentification par formulaires

  • Gère l'authentification auprès d'un magasin de données personnalisé, en principe une base de données SQL Server ou Active Directory.

  • Gère l'autorisation par rôle avec une recherche des rôles à partir d'un magasin de données.

  • Intégration simple dans l'interface utilisateur Web.

  • ASP.NET assure la plus grande partie de l'infrastructure. Une petite quantité de code est nécessaire par rapport à la méthode ASP classique.

Avantages de l'authentification Passport

  • L'authentification Passport est une solution centralisée.

  • Elle supprime les problèmes de gestion des informations d'identification à partir de l'application.

  • Elle peut être utilisée avec des stratégies d'autorisation par rôle.

  • Elle est très sécurisée dans la mesure où elle repose sur les technologies de cryptographie.

Informations supplémentaires

  • Pour plus d'informations sur les méthodes d'authentification des services Web, consultez le Module 10, « Sécurité des services Web ».

  • Pour plus d'informations sur l'utilisation de l'authentification par formulaires avec SQL Server, consultez la section « Procédure : Utiliser l'authentification par formulaires avec SQL Server 2000 » dans ce guide.

Scénarios d'applications intranet et extranet

La figure 3.5 présente une arborescence de décision permettant de choisir un mécanisme d'authentification pour les scénarios d'applications intranet et extranet.

Choix d'un mécanisme d'authentification pour les applications intranet et extranet

Figure 3.5
Choix d'un mécanisme d'authentification pour les applications intranet et extranet

Comparaison des mécanismes d'authentification

Le tableau suivant compare les mécanismes d'authentification disponibles.

Tableau 3.4 : Méthodes d'authentification disponibles

Authentification de base

Authentification Digest

NTLM

Kerberos

Par cert.

Par formulaires

Passport

Les utilisateurs doivent disposer de comptes Windows dans le domaine du serveur

Oui

Oui

Oui

Oui

Non

Non

Non

Gère la délégation*

Oui

Non

Non

Oui

Possible

Oui

Oui

Nécessite des clients et serveurs Windows 2000

Non

Oui

Non

Oui

Non

Non

Non

Les informations d'ident. sont transmises en texte brut (SSL requis)

Oui

Non

Non

Non

Non

Oui

Non

Gère les navigateurs autres que Internet Explorer

Oui

Non

Non

Non

Oui

Oui

Oui

* Pour plus d'informations, consultez la rubrique « Délégation » dans la section « Transmission de l'identité » plus haut dans ce module.

Résumé

L'élaboration des méthodes d'autorisation et d'authentification des applications distribuées est une tâche difficile. Réalisée pendant les phases initiales du développement de votre application, elle permet de limiter de nombreux risques en matière de sécurité. Les points traités dans ce module sont récapitulés ci-après :

  • Utilisez le modèle d'accès aux ressources de sous-système approuvé pour profiter des avantages du regroupement de connexions à une base de données.

  • Si votre application n'utilise pas l'authentification Windows, utilisez la vérification de rôles .NET pour assurer l'autorisation. Validez les informations d'identification auprès d'un magasin de données personnalisé, récupérez une liste des rôles et créez un objet GenericPrincipal. Associez-le à la demande Web active (HttpContext.User).

  • Si votre application utilise l'authentification Windows et n'utilise pas les services Microsoft Enterprise Services, utilisez des rôles .NET. Gardez à l'esprit que, dans le cadre de l'authentification Windows, les rôles .NET sont des groupes Windows.

  • Si votre application utilise l'authentification Windows et les services Microsoft Enterprise Services, envisagez de faire appel aux rôles Microsoft Enterprise Services (COM+).

  • Pour une véritable autorisation par rôle à l'aide de rôles Microsoft Enterprise Services (COM+), l'identité de l'appelant initial doit être transmise à l'application Microsoft Enterprise Services. Si l'application Microsoft Enterprise Services est appelée à partir d'une application Web ASP.NET, l'application Web doit utiliser l'authentification Windows et être configurée pour l'emprunt d'identité.

  • Annotez les méthodes avec l'attribut PrincipalPermission pour demander l'appartenance aux rôles de manière déclarative. La méthode n'est pas appelée si l'appelant n'est pas dans le rôle spécifié, et une exception de sécurité est générée.

  • Appelez PrincipalPermission.Demand dans le code de la méthode (ou utilisez IPrincipal.IsInRole) pour obtenir des décisions d'autorisation précises.

  • Envisagez d'implémenter un objet IPrincipal personnalisé pour obtenir des règles de sémantique de vérification des rôles supplémentaires.

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft