Jeff Kercher, auteur
Edward Jezierski, responsable programmes
Microsoft Corporation
Résumé : cet article traite de
l'importance des aspects relatifs à la sécurité
lors de la conception d'une application serveur. Les services
IIS (Internet Information Services) et ASP.NET offrent
des modèles de sécurité qui permettent
d'authentifier vos utilisateurs comme il convient et d'obtenir
le contexte de sécurité adéquat au sein de votre
application.
Sommaire
Introduction
Remarques relatives
à la sécurité
Relations
entre IIS et ASP.NET
Méthodes
d'authentification
Sécurité des
services Web
Système CAS
(Code Access Security)
Sécurité
des canaux
Informations
complémentaires
Annexe A
Introduction
La sécurité est un des principaux soucis pour les
architectes et les développeurs de programmes. Les
applications qui contiennent des informations stratégiques
doivent être protégées contre les attaques
malveillantes et contre toute tentative éventuelle de la
part de la concurrence de dérober des informations ou des
éléments relevant de la propriété
intellectuelle. Lors de la conception d'un modèle de
sécurité pour votre application, vous devez
connaître parfaitement les exigences de sécurité
d'un point de vue commercial, ainsi que les conséquences
que le choix d'un modèle de sécurité
spécifique peut avoir sur les performances,
l'évolutivité et le déploiement.
Remarques relatives à la
sécurité
Lorsque vous créez une application serveur, le document
de spécification correspondant doit contenir une section
relatives aux questions liées à la
sécurité. Dans la spécification fonctionnelle de
votre application, vous devez examiner les éléments
suivants et, dans la mesure du possible, apporter une
réponse concrète :
- Objectifs de sécurité. Mettre en
évidence les objectifs à atteindre et vous assurer
que vous pouvez les décrire.
- Risques relatifs à la sécurité.
Connaître les points vulnérables de votre
application. Vous devez également avoir une idée
précise des menaces éventuelles qui guettent votre
activité.
- Authentification. Il s'agit d'accepter les
informations d'identification fournies par un utilisateur et
de les valider auprès d'une autorité
désignée. L'identité de l'utilisateur (ou
éventuellement celle d'une application ou d'un
ordinateur) constitue ce que l'on appelle l'entité de
sécurité. Le client doit fournir des informations
d'identification pour permettre aux serveur de vérifier
cette entité. Une fois que l'identité est connue,
l'application peut autoriser l'entité à
accéder aux ressources du système. La section
suivante de ce document présente divers critères
qui vous aideront à choisir la méthode
d'authentification appropriée.
- Autorisation. Il s'agit de déterminer si
l'identité déclinée a le droit d'accéder
à une ressource spécifique.
- Sécurisation de la transmission des
données. En cryptant les données envoyées
sur le réseau, vous vous assurez qu'elles ne seront pas
consultées sans permission ou falsifiées pendant
leur transfert. Vous devez tenir compte du degré de
sécurisation qu'exigent les données circulant sur
le réseau.
- Emprunt d'identité. Ce dispositif permet
à un processus serveur de s'exécuter en utilisant
les informations d'identification du client. Lorsque le
serveur emprunte l'identité du client, toutes les
opérations qu'il exécute sont réalisées
avec les informations d'identification de ce client.
Toutefois, l'emprunt d'identité ne permet pas au serveur
d'accéder à des ressources distantes au nom du
client. Pour ce type d'opération, une
délégation s'avère nécessaire.
- Délégation. Comme l'emprunt
d'identité, ce dispositif permet à un processus
serveur de s'exécuter en utilisant les informations
d'identification du client. Cependant, la
délégation va plus loin en autorisant le processus
serveur à appeler d'autres ordinateurs au nom du
client.
- Sécurité du système d'exploitation.
Ce dispositif fait référence à la mise en
place de liste de contrôle d'accès (ACL) et à
la sécurité du réseau pour interdire les
personnes non habilitées d'accéder aux ressources
sécurisées. Vous devez définir les listes ACL
adéquates sur les ressources à protéger afin
d'en permettre l'accès aux seules entités
autorisées.
- Sécurisation des accès physiques. Il
s'agit tout simplement d'installer votre machine serveur dans
une salle sécurisée. Ne négligez pas cet
aspect.
- Système CAS. Ce système permet
d'approuver un code à des degrés différents,
en fonction de sa provenance et de certains autres aspects
concernant son identité. Vous devez déterminer
comment créer vos propres droits d'accès.
Relations entre IIS et
ASP.NET
Pour concevoir votre application, vous devez clairement
comprendre les relations entre l'authentification des services
IIS et l'architecture de sécurité de Microsoft®
ASP.NET. Ceci vous permettra d'authentifier correctement vos
utilisateurs et de mettre en place le contexte de
sécurité adapté à votre application. Notez
que la configuration de la sécurité des applications
ASP.NET et la configuration de sécurité IIS sont
totalement indépendantes, de sorte que vous pouvez les
utiliser indépendamment ou conjointement.
Pour IIS, les paramètres de configuration relatifs
à la sécurité sont stockés dans la
métabase de données IIS. Ceux concernant la
sécurité ASP .NET (mais pas uniquement ceux-là)
sont regroupés dans des fichiers de configuration XML.
Cette distinction simplifie en général le
déploiement de votre application du point de vue
sécuritaire, mais le modèle de sécurité
adopté par l'application va également exiger la
configuration adéquate aussi bien de la métabase IIS
que de l'application ASP.NET via son fichier de configuration
(Web.config).
La figure 1 illustre les relations entre IIS et
ASP.NET.
.gif)
figure 1. Relations entre IIS et ASP.NET sur le plan de
la sécurité
Fournisseurs d'authentification ASP.NET et
sécurité IIS
ASP.NET met en œuvre l'authentification en utilisant
des fournisseurs d'authentification, à savoir des modules
de code qui vérifient les informations d'identification et
implémentent d'autres fonctionnalités de
sécurité, comme la génération de cookies.
ASP.NET prend en charge les trois fournisseurs
suivants :
- Authentification par formulaire. Avec ce
fournisseur, les requêtes non authentifiées sont
redirigées vers un formulaire HTML spécifié
par le biais d'un processus de redirection côté
client. L'utilisateur peut ensuite fournir les informations
d'identification nécessaires à l'ouverture de la
session et renvoyer le formulaire au serveur. Si
l'application authentifie la requête (à l'aide
d'une logique qui lui est propre), ASP.NET émet un
cookie contenant les informations d'identification ou une
clé en vue d'acquérir à nouveau
l'identité du client. Les requêtes suivantes
contiennent le cookie dans leur en-tête, de sorte qu'il
n'est pas nécessaire de procéder à de
nouvelles authentifications.
- Authentification par passport. Ce service
d'authentification centralisé, fourni par Microsoft,
offre un système de connexion unique et des services
d'abonnement (membership) pour les sites participants.
ASP.NET, en association avec le kit de développement
(SDK) Microsoft® Passport, offre une fonctionnalité
similaire à l'authentification par formulaire aux
utilisateurs de Passport.
- Authentification Windows. Ce module utilise les
fonctions d'authentification d'IIS. Une fois qu'IIS a
procédé à l'authentification, ASP.NET utilise
le jeton (token) de l'identité authentifiée pour
autoriser l'accès.
Pour appliquer un fournisseur d'authentification particulier
à une application ASP.NET, vous devez créer une
entrée dans le fichier de configuration de celle-ci, comme
indiqué ci-après :
// fichier web.config
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>
Outre l'authentification, ASP.NET propose un mécanisme
d'emprunt d'identité visant à déterminer le
jeton de sécurité du thread de l'application. Pour
obtenir le jeton adéquat, il vous appartient de configurer
de manière appropriée l'authentification IIS, les
fournisseurs d'authentification ASP.NET et les paramètres
d'emprunt d'identité ASP .NET. La figure 2 montre les
combinaisons les plus probables entre l'authentification IIS et
les fournisseurs ASP.NET.
.gif)
figure 2. Schéma des paramètres de
sécurité ASP.NET et IIS
Authentification utilisant des comptes Windows
Si vous envisagez d'authentifier des utilisateurs en vous
servant des comptes gérés par un contrôleur de
domaine Microsoft Windows NT® ou au sein de Microsoft
Windows® 2000 Active Directory™, vous devez utiliser
l'authentification IIS couplée au Fournisseur Windows pour
ASP.NET, comme le montre la figure 2. Ce faisant, vous
n'avez pas besoin d'écrire un code d'authentification
spécifique. Lorsque l'authentification se déroule
selon cette méthode, ASP.NET crée un objet Windows
Principal (entité) et l'associe au contexte de
l'application, en fonction de l'utilisateur authentifié.
Ainsi, le thread ASP.NET peut s'exécuter en tant
qu'utilisateur authentifié et obtenir l'adhésion au
groupe de l'utilisateur.
Dans certains cas, vous pouvez contourner l'authentification
IIS et mettre en place une solution personnalisée. Cela
est également possible avec ASP.NET. Vous écrivez par
exemple un filtre ISAPI personnalisé qui vérifie les
informations d'identification de l'utilisateur par rapport
à Active Directory et la création de l'objet Windows
Principal se fera manuellement. D'autres méthodes sont
également possibles mais vous devrez écrire davantage
de code qu'en utilisant directement le fournisseur .NET.
Authentification utilisant des comptes non-Windows
Si vous prévoyez d'authentifier des utilisateurs au
niveau de l'application et si ces utilisateurs n'ont pas de
comptes Windows, vous allez configurer IIS pour une
authentification anonyme. Dans cette configuration, vous
disposez des modules d'authentification .NET
suivants :
- None : si vous n'authentifiez pas les
utilisateurs ou si vous développez un code
d'authentification personnalisé.
- Forms : si vous souhaitez qu'une page de
connexion soit présentée aux utilisateurs.
- Passport : si vous utilisez les services
Passport.
Emprunt d'identité et délégation
Avec l'emprunt d'identité, les applications ASP.NET
peuvent éventuellement s'exécuter avec
l'identité du client au nom duquel elles fonctionnent.
L'emprunt d'identité est généralement
employé pour contrôler l'accès aux ressources.
Examinez avec soin si ce dispositif est vraiment
nécessaire ou non, car il consomme davantage de ressources
serveur. La délégation est une forme plus puissante
de l'emprunt d'identité car le processus serveur a alors
l'accès à des ressources distantes tout en agissant
en tant que client.
Si l'emprunt d'identité est activé, ASP.NET
reçoit le jeton qui lui permet de réaliser cet
emprunt à partir d'IIS. Dans une application Web, vous
contrôlez mieux l'emprunt d'identité avec ASP.NET
qu'avec les pages ASP classiques. Il suffit en effet de
spécifier une valeur dans le fichier Web.config de
l'application.
Lorsque vous spécifiez le paramètre d'emprunt
d'identité, trois options sont possibles :
- Emprunt d'identité activé. Dans ce cas,
ASP.NET emprunte le jeton qui lui est transmis par IIS, qui
correspond soit à un utilisateur authentifié,
soit à un compte d'utilisateur Internet anonyme.
<identity impersonate="true"/>
- Emprunt d'identité activé, avec mention d'une
identité d'emprunt spécifique. Dans ce cas,
ASP.NET emprunte le jeton généré en
utilisant l'identité configurée. Le jeton du
client, s'il existe, n'est pas utilisé.
<identity impersonate="true" name="domain\user" password="pwd"/>
- Emprunt d'identité désactivé. Il
s'agit de l'option par défaut qui assure la
compatibilité avec ASP. Dans ce cas, le thread ASP
.NET s'exécute en utilisant le jeton du processus de
travail de l'application, qui par défaut est le compte
système IIS, quelle que soit la combinaison
d'authentification (IIS ou ASP.NET) utilisée.
<identity impersonate="false"/>
Si l'application réside sur un partage UNC, ASP.NET va
toujours emprunter le jeton UNC IIS pour accéder à ce
partage, à moins qu'un compte configuré soit
employé. Si le compte explicitement configuré est
spécifié, ASP.NET l'utilise de préférence
au jeton UNC IIS.
Le tableau 1 montre le jeton du thread utilisé par
ASP.NET pour exécuter la requête, en fonction de
trois paramètres de configuration différents dans
Web.config. Remarquez bien que le compte IUSR_SERVER
désigne le compte configuré en vue d'un accès
anonyme pour l'URL en cours (il ne s'agit donc pas
nécessairement d'un compte IUSR_). Le compte processus est
celui qu'utilise le processus de travail de l'application pour
s'exécuter : par défaut, il s'agit du compte
système (System Account), sauf s'il en existe un autre,
configuré.
Tableau 1. Jeton de thread ASP pour configurations ASP
et IIS | Emprunt d'identité
ASP.NET | IIS utilise le compte
anonyme | IIS n'utilise pas le compte
anonyme | L'application réside
sur un partage UNC |
| Désactivé | Compte processus | Compte processus | Jeton UNC IIS |
| Activé | IUSR_SERVER | Utilisateur authentifié | Jeton UNC IIS |
| Activé avec l'utilisateur
spécifié "Jeff" | "Jeff" | "Jeff" | "Jeff" |
Identités d'application
Il est conseillé d'exécuter le processus de
travail d'application ASP .NET (aspnet_wp.exe) en utilisant un
compte spécialement configuré, avec des
privilèges moindres que le compte System par défaut.
Il y a à cela deux raisons. Premièrement, même
si le dispositif de sécurité est violé, l'intrus
ne possède pas d'accès en tant qu'administrateur.
Deuxièmement, cela permet aux fournisseurs d'applications
hébergées (FAH) d'exécuter des applications en
utilisant des comptes "moins puissants", afin que les
applications hébergées ne puissent pas compromettre
l'intégrité du serveur ou réaliser des
opérations exigeant des droits d'administration.
Pour exécuter le processus de travail ASP en utilisant
un compte spécifié, ajoutez un élément
<processModel> dans le fichier de configuration
racine (machine.config), qui se trouve dans le dossier
\WINNT\Microsoft.NET\Framework\Version\Config, comme
indiqué ci-dessous :
<system.web>
<processModel enable="true" username="domain\user" password="pwd"/>
</system.web>
Outre la spécification d'un compte utilisateur
particulier, vous pouvez donner à l'attribut
username une des deux valeurs spécialement
reconnues, à savoir "SYSTEM" ou "MACHINE". Dans les deux
cas, l'attribut password doit être défini à
"AutoGenerate", puisqu'aucune information d'identification
n'est requise. Le paramètre "SYSTEM" (par défaut)
exécute le processus de travail en utilisant le compte
System, alors qu'avec le paramètre "MACHINE", le processus
s'exécute avec un compte spécial nommé à
l'aide d'un préfixe ASPNET. Ce compte est semblable au
compte IWAM_MACHINENAME utilisé par IIS pour exécuter
des instances de dllhost.exe en cas d'hébergement
d'applications ASP standard. Le compte ASPNET est
créé durant l'installation .NET.
Si vous utilisez un compte personnalisé, celui-ci doit
posséder les droits d'accès nécessaires sur les
répertoires suivants.
- Un accès Lecture/Écriture est requis sur le
répertoire %installroot%\ASP.NET Temporary Files. Les
sous-répertoires qui en dépendent servent à
stocker une sortie compilée de manière
dynamique.
- Un accès Lecture/Écriture est requis sur le
répertoire %temp%. Celui-ci est utilisé par les
compilateurs lors de la compilation dynamique.
- Un accès Lecture est requis sur le répertoire
de l'application.
- Un accès Lecture est requis sur l'arborescence
%installroot% pour permettre l'accès aux assembly
système.
Notez que les rubriques de contrôle d'accès (ACE)
appropriées sont définies durant le processus
d'installation pour le compte ASPNET.
Si vous utilisez un compte processus spécialement
configuré, vous devez savoir qu'il limite de façon
non négligeable l'emprunt d'identité. Bien qu'il vous
soit possible d'emprunter l'identité du client, vous ne
pouvez pas utiliser la forme étendue d'emprunt
d'identité lorsqu'un compte d'emprunt spécifique est
défini dans le fichier Web.config de l'application. Cette
option requiert en effet que le processus de travail ait le
privilège SE_TCB_NAME ("Agir en tant que partie du
système d'exploitation"), ce qui n'est
généralement pas le cas d'un processus à
l'identité plus faible. L'emprunt d'identité par
requête continue toutefois de fonctionner car IIS
crée la session de connexion et transmet le jeton
d'emprunt d'identité directement au processus de travail.
Cette restriction s'applique uniquement à Windows 2000 et
Windows NT 4. Microsoft Windows XP apporte des
améliorations qui permettent la création de sessions
de connexion spécifiques sans que ce privilège soit
nécessaire.
Pour plus d'informations, consultez les chapitres suivants
du Guide .NET Framework Developers Guide :
- "How ASP.NET Security Works"
- "ASP.NET Authentication"
- "ASP.NET Configuration Concepts"
- "Using IIS Authentication With ASP.NET
Impersonation"
Pour plus d'informations sur l'authentification dans IIS
5.0, reportez-vous à l'article "
Internet Information Services 5.0 Authentication Methods .gif)
.gif)
".
Méthodes
d'authentification
Dans vos applications Web .NET, vous disposez de nombreuses
options d'authentification. Par exemple, vous pouvez choisir un
des mécanismes IIS pris en charge ou procéder à
une authentification au sein même du code de votre
application. Au moment de faire votre choix, vous devez tenir
compte de certains des facteurs suivants :
- Systèmes d'exploitation serveur et client
- Type de navigateur client
- Nombre d'utilisateurs, emplacement et type de la base de
données des noms d'utilisateurs et des mots de
passe
- Aspects liés au déploiement : votre
application est-elle de type Internet ou intranet,
réside-t-elle derrière un pare-feu, etc.
- Type de l'application, par exemple : s'agit-il d'un
site Web interactif ou d'un service Web non
interactif ?
- Degré de confidentialité des données que
vous protégez
- Performances et facteurs d'évolutivité
- Autorisations à accorder, par exemple :
voulez-vous mettre votre application à la disposition de
tous les utilisateurs, ou souhaitez-vous limiter certains
domaines à des utilisateurs reconnus et d'autres
domaines aux administrateurs uniquement ?
Choix d'une méthode d'authentification
Vous pouvez utiliser le diagramme proposé en Annexe A pour vous
aider à déterminer la méthode d'authentification
la plus adaptée, en fonction des besoins de votre
application. Pour utiliser ce diagramme, répondez aux
questions concernant la nature de la base utilisateurs et le
modèle de déploiement. Les cases
d'extrémité du diagramme désignent les
méthodes d'authentification appropriées qu'il est
possible d'adopter.
Après examen du diagramme, reportez-vous aux
sous-sections suivantes qui contiennent des informations plus
détaillées sur les différentes méthodes et
apportent des éléments qui vous aideront dans votre
choix. À la fin de cette section, vous devez être en
mesure de choisir une méthode.
Explication des points de décision du diagramme
- Les utilisateurs doivent-ils se connecter avec un
login ? Est-ce qu'un nom d'utilisateur et un mot de
passe sont nécessaires pour accéder au site ou au
service ?
- La personnalisation est-elle
nécessaire ? Le site va-t-il proposer un
contenu personnalisé, sans exiger des utilisateurs
qu'ils ouvrent une session ?
- Comptes utilisateurs ? Les comptes
utilisateurs sont-ils des comptes Windows NT Domain, Active
Directory, ou sont-ils stockés dans d'autres bases de
données, par exemple une base relationnelle, un autre
service de répertoire LDAP (Lightweight Directory
Access Protocol) ou un fichier XML ?
- Une connexion unique ou une connexion transparente
est-elle nécessaire ? Voulez-vous que les
utilisateurs se connectent via une page de connexion ou
souhaitez-vous que l'authentification se déroule
automatiquement ? Par exemple, vous pouvez demander une
authentification automatique pour une transaction
automatisée BtoB (Business-to-Business).
- Avez-vous besoin d'une connexion
sécurisée ? Voulez-vous que votre
système soit quasiment inviolable pour empêcher les
pirates de dérober des noms d'utilisateur et des mots de
passe sur le réseau ? Cette décision
dépend en général du degré de
confidentialité des données placées sur le
site.
- L'application s'exécutera-t-elle sur
Internet ? L'application se trouvera-t-elle
derrière un pare-feu, où les utilisateurs ne sont
pas authentifié par rapport à un domaine, ou bien
s'agira-t-il d'une application intranet où les
utilisateurs sont peut-être déjà
authentifiés sur un domaine ?
- Avez-vous besoin de déléguer le contexte de
sécurité ? Avez-vous besoin que des
composants métier s'exécutent avec l'identité
de l'appelant ? Dans la négative, l'emprunt
d'identité est nécessaire. En outre, si vous devez
accéder à des ressources système, par exemple
des files d'attente de messages, des bases de données ou
des fichiers système sur des ordinateurs distants, un
emprunt d'identité avec délégation est
nécessaire.
- Les serveurs et les clients s'exécutent-ils
uniquement sur Windows 2000 ? Utilisez-vous un
environnement homogène d'ordinateurs avec Windows 2000,
ou existe-t-il des clients qui fonctionnent avec d'autres
systèmes d'exploitation tels que Windows 9x et Windows
NT 4.0 ?
Authentification anonyme
Avec l'authentification anonyme, le serveur ne demande pas
au client d'envoyer les informations d'identification de
l'utilisateur. Cette méthode est idéale si votre site
ou votre service est accessible à tous et si vous n'avez
pas besoin de connaître l'identité de l'appelant. De
plus, il n'existe pas de restrictions liées au navigateur
et qui seraient dues à des incompatibilités avec les
mécanismes d'authentification pris en charge. Lorsqu'un
site est configuré pour une authentification anonyme, tous
les utilisateurs peuvent y accéder. Il convient de noter
que, même si vous avez configuré IIS pour une
authentification anonyme, l'authentification peut se
dérouler au niveau de la couche ASP.NET, ce qui n'est pas
une véritable authentification anonyme. Dans cette
section, nous partons du principe que IIS et l'application
n'ont pas besoin de login.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification anonyme dans les cas
suivants :
- Vous n'avez pas besoin de connaître le nom et/ou le
mot de passe de l'appelant, que ce soit pour la connexion ou
pour les composants de la logique métier.
- Les informations que vous protégez sont
considérées comme étant "publiques".
Vous ne devez pas envisager l'authentification anonyme dans
les cas suivants :
- Vous limitez votre base utilisateurs en exigeant un nom
de login et un mot de passe.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification anonyme.
Sites avec un contenu
personnalisé seulement
Si vous créez un site offrant exclusivement un contenu
personnalisé, l'authentification anonyme peut vous
convenir. C'est le cas par exemple d'un site qui diffuse les
nouvelles locales en fonction du code postal de l'utilisateur,
sans que celui-ci ait besoin d'ouvrir explicitement une
session. La fonction de personnalisation peut être mise en
œuvre à l'aide de cookies, séparément de
l'authentification. Pour plus d'informations sur les cookies,
reportez-vous à la section sur les Cookies plus loin dans ce
document.
Emprunt d'identité
Dans le cas d'une authentification anonyme, le thread de
l'application s'exécute :
- soit comme compte Internet intégré anonyme,
IUSR_MACHINENAME,
- soit comme compte configuré dans IIS pour
l'utilisateur anonyme,
- soit comme compte système IIS.
Si votre application utilise d'autres ressources, par
exemple des composants COM+, des bases de données, des
files d'attente de messages ou des partages de fichiers UNC,
vous devez définir les autorisations appropriées pour
l'utilisateur anonyme. Si c'est le cas, tenez compte des
observations suivantes :
- Configurez un contrôleur de domaines comprenant tous
vos serveurs Web et d'applications. Configurez l'utilisateur
anonyme afin qu'il s'exécute comme utilisateur de
domaine avec les autorisations adéquates pour
accéder aux ressources. Cette méthode offre une
plus grande souplesse car la gestion des comptes est
centralisée.
- Si vous n'appartenez pas à un domaine, vous pouvez
créer un utilisateur ayant les mêmes nom et mot de
passe sur chacun des serveurs Web ou d'applications.
Toutefois, cette solution est déconseillée en
raison des difficultés liées à la gestion de
comptes dupliqués.
Performances
Le fait d'avoir un site Web anonyme et de ne pas utiliser
l'emprunt d'identité ASP.NET améliore les
performances, mais il s'agit là de la configuration
d'applications la moins sécurisée.
Mise en œuvre
Pour mettre en œuvre l'authentification anonyme,
configurez IIS pour ce type d'authentification et
définissez le compte d'utilisateur anonyme approprié.
Par ailleurs, configurez ASP.NET à l'aide du fichier
Web.config de façon à désactiver
l'authentification.
// fichier web.config
<system.web>
<authentication mode="None" />
</system.web>
Authentification de base
Lorsque IIS est configuré pour l'authentification de
base, le navigateur reçoit l'instruction d'envoyer les
informations d'identification de l'utilisateur via HTTP. Les
mots de passe et noms d'utilisateur sont codés à
l'aide du codage Base64. Bien que le mot de passe soit
codé, il est jugé peu sûr en raison de la
relative facilité avec laquelle il peut être
décrypté. Le navigateur présente une boîte
de dialogue à l'utilisateur puis il émet de nouveau
la requête anonyme d'origine avec les informations
d'identification fournies, y compris le nom d'utilisateur et le
mot de passe. L'affichage contextuel d'une boîte de
connexion peut s'avérer utile ou non, selon les besoins
propres à la conception de votre interface utilisateur. La
plupart des navigateurs Internet prennent en charge
l'authentification.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification de base dans les cas
suivants :
- Vos utilisateurs ont des comptes Windows NT Domain ou
Active Directory.
- Vous devez prendre en charge plusieurs types de
navigateurs, y compris Netscape Navigator et toutes les
versions d'Internet Explorer (y compris les plates-formes
Pocket PC et Windows CE).
- Vous devez gérer l'authentification sur
Internet.
- Vous devez accéder au mot de passe en clair dans
votre code d'application.
- Vous devez gérer la délégation.
Vous ne devez pas envisager l'authentification de base dans
les cas suivants :
- Vous avez besoin d'une connexion sécurisée et
vous n'utilisez pas de canal sécurisé tel qu'en
propose SSL (Secure Sockets Layer).
- Vos utilisateurs sont enregistrés dans une base de
données personnalisées et n'ont pas de compte
Windows.
- Vous tenez à ce qu'un formulaire personnalisé
soit présenté à l'utilisateur comme page de
connexion.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification de base.
Délégation utilisant
l'authentification de base
Il est possible d'associer l'authentification de base à
un processus de délégation d'un ordinateur à un
autre (mais pas au-delà). Dans le cadre de la
délégation, le serveur IIS connecte l'utilisateur
localement via un appel à l'API Win32 LogonUser.
IIS disposant du mot de passe de l'utilisateur en clair, il
peut répondre aux sollicitations d'ordinateurs distants,
ce qui permet au serveur Web d'agir au nom du client. Si vous
avez besoin de déléguer le contexte de
sécurité à d'autres ordinateurs (au-delà du
premier qui a bénéficié de la
délégation), vous devez localement établir des
connexions avec les autres ordinateurs de la chaîne
d'appel. L'authentification de base autorise cette
démarche car vous avez accès au nom d'utilisateur et
au mot de passe en clair, et vous pouvez les transmettre à
d'autres applications telles que celles basées sur ISAPI
ou CGI.
Sécurisation de
l'authentification de base
N'oubliez pas que le mot de passe peut facilement être
décrypté ; vous devez donc limiter
l'authentification de base à des applications non
sécurisées ou, tout au plus, à des applications
à demi sécurisées.
Vous pouvez sécuriser l'authentification de base en
l'associant à SSL. Vous empêchez ainsi le
décryptage des mots de passe. Bon nombre d'applications
Internet actuelles ont recours à cette association.
Mise en œuvre
Pour mettre en œuvre l'authentification de base,
configurez-la dans IIS et vérifiez que vos utilisateurs
possèdent l'autorisation "connexion locale" sur le serveur
Web. Si votre application ASP.NET doit s'exécuter en tant
qu'utilisateur identifié par l'authentification de base,
configurez le fichier Web.config comme suit :
// fichier web.config
<system.web>
<authentication mode="Windows" />
</system.web>
Authentification Digest
Il s'agit d'un nouveau mode d'authentification proposé
avec Windows 2000 et IIS 5.0. Il repose sur le cryptage du mot
de passe de l'utilisateur et fournit un mécanisme qui
empêche certaines attaques de serveur courantes (attaque
replay par exemple). Dans l'authentification Digest, les
informations d'identification ne sont pas envoyées en
clair sur le réseau, comme le fait l'authentification de
base. En fait, un système de hachage appelé MD5 et
développé par RSA est mis en œuvre. (Pour plus
d'informations, reportez-vous à l'article "The MD5
Message-Digest Algorithm" à l'adresse
http://www.ietf.org/rfc/rfc1321.txt.) Bien que ce mode
d'authentification soit exploitable en environnement Internet,
les conditions requises au niveau du serveur et du client
limitent sa généralisation. Contrairement à
l'authentification de base et à l'instar de NTLM et
Kerberos, IIS ne connecte pas l'utilisateur localement au
serveur Web, interdisant toute délégation.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification Digest dans les cas
suivants :
- Votre serveur Web exécute Windows 2000 et vos
utilisateurs ont des comptes Windows stockés dans Active
Directory.
- Tous vos clients utilisent la plate-forme .NET ou
Internet Explorer 5.x.
- Vous avez besoin de coder les mots de passe de façon
plus complexe que dans l'authentification de base.
- Vous devez gérer l'authentification sur
Internet.
Vous ne devez pas envisager l'authentification Digest dans
les cas suivants :
- Certains de vos clients utilisent des plates-formes
autres que .NET ou Internet Explorer 5.0 (ou version
supérieure).
- Vos utilisateurs n'ont pas de comptes Windows dans Active
Directory.
- Vous avez besoin de recourir à la
délégation.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification Digest.
Sécurisation de
l'authentification Digest
L'objectif de l'authentification Digest est d'offrir un mode
de connexion plus sûr que l'authentification de base.
Cependant, elle n'est pas aussi sûre que
l'authentification de base couplée avec SSL, NTLM,
Kerberos, ou une authentification par certificat.
L'authentification Digest avec SSL est une solution
fiable : toutefois les contraintes liées à son
déploiement limitent sa généralisation.
Configuration spécifique de
la plate-forme pour l'authentification Digest
L'authentification Digest nécessite que les clients
utilisent .NET ou Internet Explorer 5.x. Les comptes
d'utilisateur doivent être enregistrés dans Active
Directory, configuré pour l'authentification Digest.
Mise en œuvre
Vous devez configurer IIS pour l'authentification Digest.
Pour plus d'informations, reportez-vous vous à l'article
Q222028 de la Base de connaissances Microsoft, "Setting Up Digest
Authentication for Use with Internet Information Services
5.0"
.
Si votre application ASP.NET doit s'exécuter en tant
qu'utilisateur authentifié par l'authentification Digest
IIS, configurez le fichier Web.config comme suit :
// fichier web.config
<system.web>
<authentication mode="Windows" />
</system.web>
Pour utiliser l'authentification Digest dans Windows 2000,
le serveur doit avoir accès à un serveur Active
Directory configuré pour ce type d'authentification.
Pour plus d'informations sur l'authentification Digest,
consultez la spécification RFC 2069 à l'adresse
http://www.ietf.org/rfc/rfc2069.txt.
Authentification intégrée à Windows
L'authentification intégrée à Windows
(Stimulation/Réponse NTLM ou Kerberos) suppose
l'authentification d'un utilisateur ayant un compte Windows NT
Domain ou Active Directory. Contrairement aux authentifications
de base et Digest, le mot de passe crypté n'est pas
envoyé sur le réseau, ce qui rend cette méthode
très sûre. Si les services Active Directory sont
installés sur le serveur et si le navigateur est
compatible avec le protocole d'authentification Kerberos V5, ce
dernier ainsi que le protocole Stimulation/Réponse sont
utilisés ; sinon, seul le protocole
Stimulation/Réponse est employé. Cette solution
convient parfaitement à un environnement intranet, où
les ordinateurs serveurs Web et les utilisateurs sont dans le
même domaine, avec des administrateurs garantissant que
chaque machine exécute Microsoft Internet Explorer version
3.01 ou ultérieure.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification intégrée
à Windows dans les cas suivants :
- Vos utilisateurs ont des comptes Windows NT Domain ou
Active Directory.
- Votre application fonctionne sur un intranet
(derrière un pare-feu).
- Tous vos clients utilisent Internet Explorer version 3.01
ou ultérieure.
- Vous devez recourir à la délégation (dans
ce cas, Kerberos est obligatoire).
- Vous avez besoin d'une procédure de connexion
transparente pour les utilisateurs du domaine (par exemple
sans affichage de boîte de dialogue pour la
connexion).
Vous ne devez pas envisager l'authentification
intégrée à Windows dans les cas
suivants :
- Vos comptes utilisateur sont stockés dans une base
de données externe et non dans une base Windows NT
Domain ou Active Directory.
- Vous devez gérer l'authentification sur
Internet.
- Vos clients utilisent Netscape Navigator ou d'autres
navigateurs non-Microsoft.
- Vous devez obtenir le mot de passe en clair du
client.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification intégrée à Windows.
Niveau de sécurité de
NTLM et Kerberos
Ces deux protocoles sont jugés extrêmement
sûrs. Avec NTLM et Kerberos, le mot de passe n'est pas
envoyé sur le réseau. NTLM utilise un système de
type Stimulation/Réponse. Kerberos est jugé plus
sûr encore car il gère l'authentification mutuelle
(c'est-à-dire que les clients peuvent vérifier le
serveur avec lequel ils communiquent).
Problèmes de
délégation
Le protocole NTLM ne gère pas la délégation.
Une fois que les informations d'identification ont
été transmises au serveur IIS, elles ne peuvent pas
être transférées à un serveur dorsal pour
authentification. Cependant, Kerberos accepte la
délégation, ce qui permet de déléguer les
informations d'identification du client à d'autres
processus sur plusieurs ordinateurs situés en aval. Par
exemple, vous pouvez utiliser Kerberos pour présenter les
informations d'identification d'un utilisateur Web à un
composant COM+ de niveau intermédiaire, jusqu'à une
base de données Microsoft SQL Server™,
configurée avec la sécurité intégrée
Windows. L'authentification Kerberos n'est pas activée
dans une configuration Active Directory par défaut.
Assurez-vous que votre environnement prend en charge Kerberos
si vous voulez choisir ce protocole avec l'intention d'utiliser
la délégation.
Utilisation sur Internet
Ni NTLM ni Kerberos ne sont couramment utilisés sur
Internet. Le principal problème en cas d'utilisation de
Kerberos sur Internet vient de ce que l'autorité de
sécurisation doit être centralisée et accessible
à tous les utilisateurs. Pour ce faire, il faut que
l'infrastructure nécessaire existe. En outre, ces
protocoles ne sont pas pris en charge pas des navigateurs
non-Microsoft, ce qui peut être un facteur restrictif,
selon votre base de clients.
Performances et
évolutivité
Kerberos est plus rapide que NTLM. Cependant, ni l'un ni
l'autre n'est aussi rapide que l'authentification de base ou
que certaines méthodes d'authentification
personnalisées. Si vous prévoyez la connexion de
nombreux utilisateurs simultanément, vous devez concevoir
avec soin votre configuration Active Directory. Lorsque le
nombre d'utilisateurs potentiel se compte par millions,
envisagez de stocker leurs noms et mots de passe dans une base
de données hautement performante, telle que SQL Server. Si
vous déléguez le contexte de sécurité dans
une application à plusieurs niveaux, vous risquez de
rencontrer des problèmes d'évolutivité. En
particulier, les solutions de niveau intermédiaire, comme
les regroupements de connexion aux bases de données, ne
sont pas utilisables.
Mise en œuvre
Pour mettre en œuvre une solution Kerberos ou NTLM,
vous devez configurer IIS pour l'authentification
intégrée à Windows. Si vous devez gérer des
clients qui n'utilisent pas Internet Explorer, vous avez la
possibilité de choisir l'authentification de base
couplée avec NTLM ou Kerberos.
Lors de la configuration Kerberos, vous devez prendre en
compte les éléments spécifiques
ci-après :
- Les ordinateurs clients et serveur doivent tous
fonctionner avec Windows 2000 dans un domaine Windows
2000.
- Le compte utilisateur du client doit être
activé pour la délégation.
- Le compte du service doit être activé pour la
délégation.
Si votre application ASP.NET soit s'exécuter comme
utilisateur authentifié par IIS avec l'authentification
intégrée à Windows, configurez le fichier
Web.config comme suit :
// fichier web.config
<system.web>
<authentication mode="Windows" />
</system.web>
Pour plus d'informations sur l'utilisation de Kerberos,
reportez-vous aux articles suivants :
Authentification par certificat
Un certificat est une "clé" numérique
installée sur un ordinateur. Lorsque l'ordinateur tente
d'accéder à un serveur, la clé est
automatiquement présentée pour authentifier
l'utilisateur. Il est possible de mapper des certificats
clients sur des comptes Windows enregistrés dans un
domaine ou dans Active Directory. Si vous utilisez le
fournisseur d'authentification Windows dans ASP.NET, le thread
d'application va s'exécuter en tant qu'utilisateur sur
lequel le certificat est mappé. Vous pouvez aussi mettre
en place une authentification personnalisée dans ASP .NET
et, par exemple, utiliser l'adresse de messagerie (ou un champ
unique) contenue dans le certificat. Du point du vue du client,
la sécurité est transparente puisque le client n'a
pas à se connecter via une page de connexion. Pour cette
raison, l'emploi de certificats constitue une option
intéressante pour les processus métier
automatisés.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification par certificat dans
les cas suivants :
- Les données que vous protégez sont
stratégiques et une solution extrêmement sûre
s'impose.
- Vous avez besoin de recourir à l'authentification
mutuelle.
- Vous souhaitez confier à un tiers la gestion des
relations entre le serveur et le détenteur du
certificat.
- Vous recherchez la transparence au niveau de
l'interaction avec le client, par exemple dans le cas
d'échanges BtoB automatisés.
Vous ne devez pas envisager l'authentification par
certificat dans les cas suivants :
- Le coût d'émission et de gestion des
certificats clients est trop élevé par rapport
à l'avantage obtenu.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification par certificat.
Déploiement
Vous devez physiquement déployer le certificat client
sur le poste de travail client. Pour ce faire, il existe
plusieurs méthodes, qui vont du déploiement Web
à l'installation du certificat à partir d'un CD-ROM.
Les problèmes liés au déploiement expliquent en
général que le recours aux certificats ne soit pas
aussi courant que les autres modes d'authentification
utilisés conjointement avec SSL.
Mappage des certificats sur des
comptes Windows
Il est possible de mapper des certificats sur des comptes
Domain ou Active Directory. Pour authentifier des utilisateurs
individuels, utilisez le mappage un-à-un, qui consiste
à mapper un certificat sur un compte individuel. Avec le
mappage Active Directory, il n'existe pas de limite à ce
type de mappage.
Si vous devez authentifier tous les utilisateurs d'un groupe
ou d'une organisation spécifique, vous pouvez utiliser le
mappage plusieurs-à-un, dans lequel, par exemple, un
certificat contenant le nom d'une entreprise commune est
mappé sur un compte unique.
Ainsi, imaginez le scénario BtoB suivant :
- L'entreprise A autorise son partenaire, l'entreprise B,
à consulter une partie de son site Web interne.
- Un certificat est installé sur les ordinateurs de
l'entreprise B.
- Le mappage plusieurs-à-un permet que l'application
ASP.NET s'exécute comme compte Windows
générique "CompanyB".
Pour obtenir plus d'informations sur les certificats,
consultez l'ouvrage "Designing Secure Web-Based Applications
for Microsoft Windows 2000" par Michael Howard.
Mise en œuvre
Vous devez configurer IIS pour l'authentification par
certificat. Pour plus d'informations sur le mappage de
certificats à clé publique sur des comptes
utilisateur Windows 2000, reportez-vous à l'article "
Step-by-Step Guide to Mapping Certificates to User
Accounts"
.
Authentification avec Passport
L'authentification avec Passport est un service
centralisé proposé par Microsoft. Lorsque vous
utilisez Passport, vous n'avez pas besoin de mettre en
œuvre votre propre code d'authentification, la page de
connexion, ou, dans certains cas, la table des utilisateurs.
Passport utilise les cookies. Si des clients ont déjà
été authentifiés par Passport, ils ont
accès à votre site. Dans le cas contraire, ils sont
automatiquement redirigés vers le site Passport pour
authentification.
Passport constitue une bonne solution si vous souhaitez
mettre en place un processus de connexion unique sur plusieurs
domaines qui prennent en charge aussi Passport. Passport offre
des services complémentaires en plus de
l'authentification, notamment la gestion de profils et des
services d'achat.
Sur la plate-forme Windows 2000, il n'y a pas
d'intégration directe de Passport avec les éventuels
mécanismes d'authentification et d'autorisation relevant
du système d'exploitation. Alors que .NET Framework
vérifie s'il existe des cookies Passport, si vous
gérez votre propre base utilisateurs, vous devez mettre en
œuvre un code spécifique pour mapper l'utilisateur
Passport sur votre utilisateur, ainsi qu'un dispositif
d'autorisation propre.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification avec Passport dans
les cas suivants :
- Votre site va être utilisé conjointement avec
d'autres sites exploitant Passport et vous souhaitez offrir
une connexion unique aux utilisateurs qui doivent y
accéder.
- Vous ne voulez pas gérer de base de données des
noms et mots de passe utilisateur.
Vous ne devez pas envisager l'authentification avec Passport
dans les cas suivants :
- Vous voulez utiliser les noms d'utilisateur et les mots
de passe déjà stockés dans votre base de
données ou dans Active Directory. (Bien que, en
écrivant un code supplémentaire, vous puissiez
mapper un ID Passport sur un compte utilisateur.)
- Vos clients sont d'autres ordinateurs qui accèdent
au site par programmation.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification avec Passport.
Activation de Passport
Pour utiliser l'authentification par Passport, il convient
d'inscrire le site avec le service Passport et d'installer le
SDK Passport sur le serveur.
Délégation
Sur Windows 2000, il est impossible de déléguer
les informations d'identification sécurisées par
Passport d'un utilisateur d'un serveur à un autre.
Mappage sur des comptes
utilisateur
L'ID utilisateur Passport (PUID) est uniquement une
identité. Si vos comptes utilisateur sont définis
dans Active Directory ou dans une base personnalisée et si
vous devez mapper le PUID sur un utilisateur, implémentez
votre propre code personnalisé. Les futures versions de
Windows devraient offrir une prise en charge native du mappage
des PUID sur des comptes Windows.
Sécurisation du
mécanisme Passport
Le cryptage des cookies fait de Passport un moyen sûr
lorsqu'il est utilisé comme méthode
d'authentification indépendante. Cependant, pour
éviter les attaques replay et assurer la meilleure
sécurité possible, utilisez Passport en association
avec SSL.
Mise en œuvre
Pour mettre en œuvre Passport, vous devez installer le
SDK Passport sur le serveur. Vous devez également vous
enregistrer auprès de Passport afin d'utiliser le service.
Configurez le fichier web.config comme suit :
// fichier web.config
<system.web>
<authentication mode="Passport" />
</system.web>
Pour plus d'informations sur le service Passport,
reportez-vous aux documents anglais suivants :
Authentification par formulaire
L'authentification par formulaire fait référence
à un composant personnalisé d'interface utilisateur,
qui accepte les informations d'identification de l'utilisateur,
par exemple un nom et un mot de passe. Bon nombre
d'applications Internet actuelles proposent ce genre de
formulaires pour établir une connexion. Le formulaire en
lui-même n'effectue pas l'authentification, il sert
uniquement à obtenir les informations d'identification de
l'utilisateur. Pour permettre l'authentification, l'accès
à la base de données des noms et mots de passe
d'utilisateur via un code personnalisé est
nécessaire.
Lorsque l'utilisateur est authentifié, le serveur
fournit au client un moyen d'indiquer, lors des requêtes
suivantes, qu'il a déjà été
authentifié. Si nécessaire, vous pouvez obliger le
client à procéder à une authentification à
chaque requête, bien que cette solution affecte les
performances et l'évolutivité. Il existe deux
approches possibles pour identifier un client qui s'est
connecté :
- Les cookies. Un cookie est un élément
d'information initialement présenté par le serveur
au client. Ensuite, le client le représente au serveur
dans chaque requête HTTP. Ceci permet de savoir si le
client a déjà été authentifié.
ASP.NET permet l'utilisation des cookies en vue d'une
authentification par formulaire dans le module
CookieAuthenticationProvider. Les cookies sont reconnus par
la plupart des navigateurs Web, y compris Internet Explorer
et Netscape Navigator.
- Solution personnalisée. Vous pouvez aussi
développer un mécanisme personnalisé pour
identifier le client auprès du serveur. Si vos clients
ont désactivé les cookies, stockez un
identificateur unique dans chaque chaîne de requête
URL. Vous pouvez aussi utiliser des champs de formulaire
cachés qui sont enregistrés dans un cadre permanent
invisible ou de premier niveau. Dans les deux cas, vous devez
vous assurer qu'aucun pirate ne pourra, par programmation,
faire croire à votre application qu'il est
authentifié.
Les cookies sont largement utilisés par les sites Web
qui appliquent l'authentification par formulaire. La version
initiale de .NET ne prendra en charge que l'authentification
par formulaire utilisant des cookies.
Scénarios d'utilisation classiques
Vous devez envisager l'authentification par formulaire dans
les cas suivants :
- Les noms d'utilisateur et les mots de passe sont
stockés ailleurs que dans des comptes Windows. Remarquez
qu'il est possible d'utiliser l'authentification par
formulaire avec des comptes Windows.
- Vous déployez votre application sur Internet.
- Vous devez prendre en charge tous les navigateurs et
systèmes d'exploitation des clients.
- Vous voulez proposer votre propre formulaire d'interface
comme page de connexion.
Vous ne devez pas envisager l'authentification par
formulaire dans les cas suivants :
- Vous déployez une application sur un intranet
d'entreprise et vous pouvez tirer parti de l'authentification
intégrée à Windows.
- Il vous est impossible de prévoir un accès par
programmation pour vérifier le nom et le mot de passe
des utilisateurs.
Autres considérations
Vous devez également tenir compte des
éléments suivants si vous choisissez
l'authentification par formulaire.
Sécurisation de
l'authentification par formulaire
Si les utilisateurs entrent des mots de passe via la page de
connexion, sécurisez le canal à l'aide de SSL pour
éviter qu'ils ne soient détournés. Si vous
utilisez des cookies pour gérer l'identité de
l'utilisateur entre les requêtes, n'oubliez pas qu'il
existe un risque qu'un pirate "détourne" le cookie de
l'utilisateur en utilisant un programme de surveillance de
réseau. La seule manière de rendre le site
entièrement sécurisé en cas d'utilisation de
cookies est d'utiliser SSL pour toutes les communications avec
le site. Pour la plupart des sites de commerce, cette option
est irréalisable en raison de l'impact important sur les
performances. Avec ASP.NET, vous pouvez faire en sorte que le
serveur régénère les cookies à intervalles
réguliers. Cette stratégie, qui introduit la notion
de durée de validité des cookies, a pour but
d'éviter qu'un autre utilisateur n'accède au site
avec un cookie volé.
Performances et
évolutivité
Lorsque vous concevez un site Web volumineux, vous devez
tenir compte de l'impact que l'authentification des
utilisateurs exerce sur les performances. Si vous prévoyez
la connexion de très nombreux utilisateurs à la fois,
la vérification des informations d'identification doit
être aussi rapide que possible.
L'utilisation de SSL affecte de façon notable les
performances en raison des étapes supplémentaires de
cryptage qui sont requises. Il peut s'avérer
nécessaire de séparer les serveurs qui assurent la
connexion sécurisée des serveurs de contenus
regroupés dans une ferme Web afin de maintenir le niveau
de performances requis.
Vérification de l'existence
de cookies
Si vous utilisez .NET, la vérification de l'existence
d'un cookie se déroule automatiquement. Cependant, en
dehors de .NET, deux approches sont possibles :
- Vous pouvez mettre en œuvre un filtre ISAPI
confirmant la présence d'un cookie dans la requête
d'un client, ce qui prouve que le client a été
authentifié. Si le cookie existe, vous autorisez le
traitement de la requête. Si le cookie n'existe pas,
vous redirigez le client vers la page de connexion. Un filtre
ISAPI conforme à cette description est
implémenté par Microsoft® Commerce Server
2000.
- Vous pouvez écrire un code au début de chaque
page Web qui contrôle l'existence du cookie ou de toute
autre valeur personnalisée transmise par la page Web. Si
le jeton est absent, le code peut rediriger l'utilisateur
vers la page de connexion. Il s'agit d'une
implémentation simple ; toutefois, vous risquez de
ne pas pouvoir protéger d'autres ressources que les
pages ASP. Par exemple, les fichiers image restent toujours
accessibles.
Si vous utilisez ASP.NET, exploitez éventuellement la
fonction intégrée fournie par l'authentification par
formulaire.
Utilisation de l'authentification
par formulaire avec des comptes Windows
Si vous déployez une application Internet et si vos
utilisateurs possèdent des comptes Windows sur le serveur,
il est possible d'adopter l'authentification par formulaire,
simple ou avec SSL, à la place de l'authentification de
base ou Digest.
Mais cette solution n'est peut-être pas idéale si
votre application fonctionne sur un intranet et utilise
déjà l'authentification intégrée à
Windows. Par ailleurs, la politique de sécurité de
votre entreprise risque de désapprouver le fait que des
utilisateurs entrent leur mot de passe dans un formulaire
HTML.
Mise en œuvre
Pour mettre en œuvre l'authentification par formulaire,
vous devez créer votre propre page de connexion et
rediriger l'URL pour les clients non authentifiés. Vous
devez aussi créer votre propre schéma de recherche
des comptes. Avec ASP.NET, vous pouvez configurer le fichier
Web.config comme suit :
// fichier web.config
<system.web>
<authentication mode="Forms" />
</system.web>
Puisque vous implémentez votre propre authentification,
vous configurez généralement IIS pour une
authentification anonyme.
Pour plus d'informations sur la mise en œuvre de SSL,
reportez-vous aux articles suivants :
Cookies
Un cookie est une petit fichier texte placé sur votre
disque dur par un serveur Web. Son but principal est de
permettre au serveur d'identifier un client qui s'est
déjà connecté. Vous pouvez utiliser les cookies
avec ou sans système d'authentification. Considérez
les scénarios d'utilisation suivants :
- Utilisation en association avec l'authentification par
formulaire. Le serveur associe au client un cookie au moment
de l'authentification, puis les requêtes suivantes font
l'objet d'une vérification sur la base du cookie
présenté au serveur.
- Utilisation en vue d'une personnalisation ; dans ce
cas, un contenu personnalisé est fourni à
l'utilisateur.
ASP.NET propose un mécanisme pour créer des
cookies et vérifie automatiquement s'ils existent dans les
requêtes des clients. Il est éventuellement possible
de crypter les cookies créés par ASP.NET en utilisant
un schéma de codage DES triple, pris en charge par .NET
Framework. Vous pouvez aussi implémenter vous-même un
fournisseur de cookies et l'utiliser avec l'authentification
par formulaire.
Pour plus d'informations sur les cookies, reportez-vous
à "Information About Cookies"
.
Autres considérations
Selon le type de navigateur, il se peut que des limites de
taille soient applicables. La spécification RFC 2019 fait
état d'une limite de 4 Ko. Internet Explorer 5
n'impose pas de limite de taille. Pour que les cookies
fonctionnent correctement avec les navigateurs, les
paramètres de sécurité de ces derniers doivent
avoir été configurés.
Sécurité des
services Web
Un service Web est une application basée sur
l'infrastructure ASP.NET, qu'il est possible d'appeler sur
Internet par programmation. Du point de vue de la
sécurité, les mêmes problèmes se posent que
pour le développement d'un site Web interactif. De plus,
pour sécuriser un site Web, vous utilisez les mêmes
mécanismes que pour n'importe quelle autre ressource
ASP.NET (comme les fournisseurs d'authentification IIS et ASP
.NET). Cependant, les facteurs supplémentaires suivants
sont à prendre en compte :
- Interaction des clients. Il se peut que votre
service Web n'ait pas à faire à des utilisateurs
interactifs qui se connectent et entrent leurs informations
d'identification, vos "utilisateurs" étant en fait des
applications.
- Sécurité au niveau méthode. Vous
devrez peut-être accorder aux utilisateurs des
autorisations qui restreignent l'utilisation de certaines
méthodes. Vous procéderez alors comme pour les
composants COM+.
- Délégation. Votre service Web devra
parfois appeler d'autres services et gérer le contexte
de sécurité de l'appelant d'origine.
Authentification pour un service Web
Les services Web ont à valider, d'une manière ou
d'une autre, les informations d'identification des
utilisateurs. Si le service n'est pas interactif, il doit
obtenir le jeton de sécurité de l'appelant, ou
exposer les méthodes appropriées pour permettre la
présentation des informations d'identification. Les
méthodes d'authentification suivantes, facilement
utilisables, n'exigent pas l'identification des utilisateurs,
ce qui les rend particulièrement adaptées à des
services Web programmables :
- Authentification de base, Digest, et intégrée
à Windows
- Authentification par mappage de certificats
- Authentification personnalisée ou spécifique de
l'application
Éventuellement, vous pouvez aussi utiliser :
- La sécurité IPSec (Internet Protocol
Security)
- Passport
Utilisation des comptes Windows et de l'authentification
IIS
Les mêmes aspects que ceux évoqués dans la
section Méthodes
d'authentification de cet article sont à prendre en
considération. Cette solution n'exige qu'un minimum de
code personnalisé et vous pouvez autoriser l'accès
à d'autres ressources à l'aide des listes ACL
Windows.
Utilisation de certificats et mappage de certificats
En cas d'authentification par certificat, l'interaction
entre le client et le serveur peut être transparente, ce
qui signifie que le client n'a pas à fournir, par voie de
programme, le nom d'utilisateur et le mot de passe. En outre,
il s'agit d'un mécanisme parfaitement sécurisé.
Les transactions BtoB, telles que le passage de commandes,
offrent un contexte idéal pour l'utilisation des
certificats. Si vous utilisez le mappage des certificats pour
obtenir des comptes utilisateur Windows, vous pouvez aussi
définir des listes de contrôle d'accès (ACL)
pour autoriser l'accès aux ressources.
Authentification personnalisée
Vous avez toujours la possibilité de mettre en place
des solutions d'authentification personnalisées. Dans ce
cas, il n'est plus nécessaire de recourir à des
applications pour gérer des comptes utilisateur Windows
séparés, ce qui est un avantage par rapport à
l'authentification intégrée à Windows. Vous
pouvez aussi incorporer votre propre méthode dans le code
du service Web et l'optimiser en fonction des besoins
spécifiques de l'application.
Les solutions d'authentification personnalisée
possibles pour des services Web incluent :
- Accepter un nom d'utilisateur et un mot de passe comme
paramètre dans vos appels de méthodes.
- Fournir une méthode de connexion qu'il faut appeler
avant tout autre méthode. Vous pouvez utiliser la
fonctionnalité des cookies de Microsoft .NET Framework
pour vérifier que des appels à la méthode de
connexion ont eu lieu.
- Utiliser les éléments SOAP Header
(en-tête) ou Body (corps) pour stocker les informations
d'identification.
- Créer un en-tête ou un corps HTTP
personnalisé pour y stocker les informations
d'identification.
La sécurité IPSec (Internet Protocol
Security)
Si vous connaissez l'adresse IP de l'ordinateur client, par
exemple si le client est un serveur Web qui appelle une logique
métier encapsulée dans des services Web de niveau
intermédiaire, la sécurité IPSec (Internet
Protocol Security) peut s'avérer intéressante.
Cette méthode vous permet de limiter le nombre
d'ordinateurs qui se connectent à votre service Web en
fonction de leur adresse IP.
Toutefois, cette approche n'est pas viable dans un
environnement Internet, lorsque vous ne connaissez pas à
l'avance les adresses IP de votre client.
Pour plus d'informations sur IPSec, reportez-vous à
l'article MSDN intitulé "
IP sécurisé pour Microsoft Windows 2000 Server"
.
Utilisation de Passport avec des services Web
Dans certains cas, l'authentification par Passport est
applicable à un service Web. Cependant, son utilisation
peut être limitée en raison de la nécessité
de rediriger des clients non authentifiés vers le site
Passport. La redirection peut provoquer des problèmes pour
les clients non-interactifs, à moins qu'ils ne soient
spécialement programmés pour gérer le processus
de redirection sur le serveur Passport.
Autorisation
Après avoir authentifié l'utilisateur, vous pouvez
au besoin l'autoriser à accéder au service Web. Il
existe plusieurs options d'autorisation :
- Utilisation des listes ACL de Windows
- Utilisation de l'autorisation URL
- Utilisation des objets Principal (entité) .NET
Utilisation des listes ACL de Windows
Avec les listes ACL de Windows, vous pouvez créer des
autorisations système sur des fichiers d'application
spécifiques. Cette solution fonctionne si votre service
Web authentifie des utilisateurs par rapport à des comptes
Windows et utilise l'emprunt d'identité.
Utilisation de l'autorisation URL
Le module URLAuthorizationModule mappe des utilisateurs et
des rôles sur des éléments dans l'espace de noms
URI.Ce module met en œuvre des formulations d'autorisation
aussi bien positives que négatives. En pratique, il est
utilisable pour autoriser ou empêcher, de façon
sélective et pour certains utilisateurs, l'accès
à des éléments arbitraires de l'espace de noms
(namespace) URI en se basant par exemple sur leur appartenance
à un rôle. L'exemple suivant accorde un accès
à plusieurs utilisateurs de domaine et le refuse à
toute autre personne.
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="domain1\user, domain2\user2, domain1\user3 />
<deny users="*" />
</authorization>
</system.web>
</configuration>
Objet Principal de Windows
L'espace de noms System.Security.Principal de la
bibliothèque de classe .NET Framework (BCL) propose un
objet WindowsPrincipal pour représenter le contexte
de sécurité sous lequel le code s'exécute. Cet
objet est créé automatiquement lorsque vous utilisez
l'authentification Windows dans IIS. Il permet de vérifier
l'appartenance à un groupe Windows d'un utilisateur
Windows et limite les accès en conséquence.
Objet Principal
générique
Il est possible de créer un objet Principal
générique sur la base de vos rôles
personnalisés. Vous pouvez l'utiliser lorsque vous
disposez de votre propre base de données
utilisateur/rôle. L'objet Principal reçoit son
contenu dans l'événement OnAuthenticate. Vous
pouvez avoir une table personnalisée mappée sur des
comptes Windows que vous mettez en correspondance dans cet
événement. Dans tous les cas, vous pouvez créer
un objet Principal personnalisé pour cet
utilisateur particulier.
Pour les utilisateurs récurrents qui ont déjà
été authentifiés, recréez l'objet
Principal à l'aide d'un cookie.
Rôles et sécurité au niveau
méthode
Il est parfois nécessaire d'instaurer la
sécurité au niveau méthode afin de limiter, pour
des objets Principal clients, les appels à certaines
méthodes. Il y a plusieurs façons de
procéder.
Si vous utilisez des comptes Windows, créez des
rôles pour vos utilisateurs sous la forme de groupes
Windows. Étant donné que le thread ASP emprunte
l'identité du client et que vous disposez d'un objet
Windows Principal, utilisez les solutions
suivantes :
- Créez des listes ACL sur des ressources
protégées auxquelles accède le thread
ASP.NET.
- Appelez la méthode IsInRole sur l'objet
WindowsPrincipal à partir de chaque méthode
afin de vérifier que l'appelant possède les
autorisations adéquates. Vous pouvez aussi insérer
dans le code une instruction logique qui appelle une
sous-routine particulière selon que le client appartient
à tel ou tel groupe.
Si vous utilisez un objet Generic Principal
créé à partir d'utilisateurs et de rôles
figurant dans une base de données
personnalisée :
- Vous pouvez contrôler l'appartenance à un
rôle par le biais de la programmation, en appelant la
méthode IsInRole sur l'objet Principal de
la même façon qu'avec l'objet Windows
Principal décrit plus haut.
Si vous n'utilisez pas d'objet Principal, vous
disposez d'autres options, notamment :
- Accepter les informations d'identification de
l'utilisateur comme paramètres dans l'appel de
méthode et effectuer une recherche.
- Vérifier l'existence d'un cookie au tout début
de l'appel de méthode.
- Créer une méthode de connexion qui renvoie une
valeur clé personnalisée, les méthodes
suivantes acceptant cette valeur comme paramètre. Ce
processus est similaire à l'utilisation des cookies
gérés par les navigateurs ; néanmoins, il
peut aussi être utilisé lorsque les cookies ne sont
pas pris en charge par le client.
Délégation
Concernant la délégation, les questions qui se
posent pour les services Web sont les mêmes que pour les
sites Web ASP.NET. Pour déléguer le contexte de
sécurité à un service Web, vous devez utiliser
l'authentification Kerberos, ou transmettre les informations
d'identification afin que les services Web s'exécutant sur
d'autres ordinateurs puissent appeler la méthode
LogonUser s'il s'agit de serveurs Windows, ou l'API
d'authentification équivalente s'ils ne sont pas des
serveurs Windows.
Accès du client
En cas de connexion à un service Web par programmation,
vous pouvez tirer parti des classes .NET pour assurer la
connectivité au niveau du client. Les protocoles
d'authentification pris en charge par les clients .NET clients
sont :
- Authentification de base
- Authentification Digest
- Authentification intégrée à Windows (NTLM
et Kerberos)
- Authentification par certificats
- Authentification personnalisée
Système CAS (Code Access
Security)
Pour protéger les systèmes informatiques contre
l'intrusion nuisible de programmes et permettre à un code
"portable" de s'exécuter en toute sécurité, .NET
Framework propose un mécanisme appelé Code Access
Security (CAS). Bien qu'il s'agisse d'une fonction de
sécurité .NET, elle s'applique à tous les codes
gérés .NET, tels que des applications Web ASP .NET.
Malgré cela, vous pouvez toujours écrire un code
spécifique lorsque :
- Vous concevez des contrôles hébergés par
des navigateurs.
- Vous hébergez des applications tierces.
- Vous hébergez des assembly de différents
fournisseurs sur un serveur partagé.
- Vous souhaitez interdire à certains assembly des
fonctions natives, comme les API d'écriture de
fichier.
La sécurité CAS permet de sécuriser le code
à des degrés divers, en fonction de la politique
sécuritaire de l'entreprise, de la provenance du code et
d'autres aspects liés à son identité, tel que
son nom d'assembly "robuste". Ce système de
sécurité minimise le risque d'utilisation abusive de
votre code par un autre. Il vous permet de définir
spécifiquement les opérations que votre code a le
droit d'exécuter ainsi que celles qui lui sont totalement
interdites. Notamment, la sécurité CAS offre un
système de gestion d'autorisation selon lequel le code
peut explicitement demander des autorisations
particulières et explicitement en refuser d'autres dont il
sait qu'il n'en a pas besoin.
Autorisations d'accès pour le code
La sécurité CAS s'appuie sur la notion
d'autorisations d'accès accordées au code. Chaque
autorisation correspond au droit pour le code d'accéder
à une ressource protégée, par exemple un
fichier, un répertoire ou une entrée de registre, ou
le droit qu'il a d'exécuter une opération
protégée telle que l'appel à un code non
géré. Le code peut réclamer des autorisations et
la politique de sécurité du runtime détermine
les autorisations à accorder. Pour obtenir la liste
complète des autorisations, reportez-vous à la
section
Code Access Permissions .
.NET permet aux administrateurs d'assigner à une
application un ensemble prédéfini d'autorisations.
Ces ensembles varient en fonction du niveau de confiance
accordée à l'application. Par défaut, les
applications reçoivent un niveau de confiance qui
dépend des "preuves" présentées au niveau de la
signature numérique du code, de son origine et de
l'emplacement de l'application.
Par exemple, des applications s'exécutant sur un
partage UNC (dans la zone de sécurité
Intranet) reçoivent le jeu d'autorisations
LocalIntranet. Les applications s'exécutant sur la
machine locale (dans la zone de sécurité
MyComputer) reçoivent l'ensemble
FullTrust.
Pour une configuration plus sophistiquée, il est
possible d'attribuer aux applications Web ASP.NET des niveaux
de confiance. Les niveaux sont définis dans le fichier de
configuration, à l'aide de l'élément
<trust>.
<trust level="Full | High | Low | None" originUrl="url" />
Chaque niveau détermine les autorisations de
l'application, lesquelles sont détaillées dans un
fichier XML décrivant la politique de sécurité
applicable. Chaque niveau peut être mappé sur un
fichier spécifique. Les mappages par défaut pour
ASP.NET sont :
- High : mappage sur web_hightrust.config
Ce niveau correspond à des autorisations qui accordent
aux applications un accès en lecture/écriture au
répertoire de l'application (soumis aux autorisations du
système d'exploitation) et qui leur permet de remplacer
l'objet Principal (entité) de l'authentification. Il
restreint par ailleurs le droit des applications à
appeler du code non géré. - Low : mappage sur web_lowtrust.config
Ce niveau permet aux applications de lire les données du
répertoire d'application et offre une connectivité
réseau limitée. Les applications peuvent se
reconnecter à leur site hôte, en supposant que
l'attribut originUrl de l'élément
<trust> soit correctement configuré. - None : mappage sur web_notrust.config
Ce niveau fournit l'autorisation d'exécution de base et
permet à l'application d'utiliser le stockage
protégé (mécanisme qui permet d'associer le
code aux données sauvegardées en toute
sécurité).
Notez que le niveau de confiance Full n'est associé
à aucun fichier de configuration, puisqu'il autorise les
applications à utiliser toutes les ressources (en fonction
des autorisations du système d'exploitation), ce qui
revient à une exécution sans sécurité CAS
(bien que le système CAS ne puisse pas être
désactivé pour le code géré). Vous pouvez
modifier ces mappages dans l'élément
<securityPolicy> du fichier de configuration et
personnaliser ou enrichir chaque niveau. Vous pouvez aussi
créer vos propres niveaux pour définir des groupes
d'autorisation arbitraires. Le mappage par défaut
<securityPolicy> est indiqué
ci-après.
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>
Verrouillage des paramètres de configuration
La configuration ASP.NET est hiérarchique par nature
avec, éventuellement, des fichiers de configuration aux
niveaux machine, application et sous-application. Les fichiers
de configuration de second niveau sont utilisables pour
modifier les paramètres définis à un niveau
supérieur, ou pour ajouter des informations de
configuration. Bien que cette possibilité autorise un
grand degré de flexibilité, les administrateurs
préfèrent parfois imposer les paramètres de
configuration et refusent qu'ils soient modifiés par des
applications spécifiques. Ainsi, l'administrateur d'un
site Web hébergé peut spécifier le niveau de
sécurité d'accès du code et interdire aux
applications de le modifier. Pour ce faire, il utilisera
l'élément <location> associé à
l'attribut allowOverride.
Supposons par exemple qu'un administrateur de site Web
hébergé souhaite interdire à toutes les
applications l'appel à un code non géré.
L'extrait suivant d'un fichier de configuration montre comment
l'administrateur peut verrouiller les paramètres de
configuration d'accès du code pour tout un site et limiter
les applications avec le niveau de confiance High (lequel
interdit tout appel à un code non
géré) :
<location path="somesitepath" allowOverride="false">
<trust level="high" originUrl="http://somesite.com" />
</location>
L'attribut path peut faire référence à
un site ou à un répertoire virtuel et il s'applique
au répertoire nommé et à tous les
sous-répertoires. Dans l'exemple précédent, si
vous définissez allowOverride à "false", vous
empêcher les applications du site de modifier les
paramètres de configuration spécifiés dans
l'élément <location>. La
possibilité de verrouiller les paramètres de
configuration s'applique à tous les paramètres, et
pas seulement aux paramètres de sécurité tels
que les niveaux de confiance.
Pour plus d'informations, reportez-vous aux documents
suivants :
Sécurité des
canaux
Les canaux transportent des messages au-delà des
limites d'une machine, par exemple vers d'autres domaines
d'applications, processus ou ordinateurs. .NET Framework
fournit deux canaux pour le transport à distance, HTTP et
TCP.
Vous devez envisager la sécurisation d'un canal
Remoting lorsque vous voulez protéger des données
confidentielles ou stratégiques qui sont transmises via
ces protocoles. En effet, à l'aide d'un logiciel de
surveillance du réseau, ces informations peuvent
facilement être interceptées et lues, à moins
qu'elles ne soient cryptées.
Voici quelques éléments importants concernant la
sécurité des canaux :
- Le canal HTTP utilisé dans IIS avec ASP.NET
gère la transmission et la réception de
données sécurisées avec SSL. SSL est le
système le plus courant pour configurer un canal
d'échanges sécurisé et il peut être
configuré dans IIS.
- Si vous voulez utiliser un canal non sécurisé
tel que HTTP/Port 80 ou TCP, vous pouvez toujours crypter les
données manuellement à l'aide de l'API de
cryptographie.
- Il est possible de mettre en œuvre un dispositif de
sécurité des canaux sous la couche transport. Dans
Windows 2000, vous pouvez adopter la sécurité IPSec
(Internet Protocol Security) pour sécuriser la
transmission des données tout en étant transparent
par rapport à l'application.
- Si vous utilisez ASP.NET avec des composants COM ou DCOM
et si vous utilisez DCOM comme protocole Remoting, pensez au
niveau d'authentification DCOM Packet Privacy pour crypter
vos transmissions DCOM.
Pour plus d'informations, reportez-vous aux documents
suivants :
Informations
complémentaires
Pour de plus amples informations sur les questions de
sécurité abordées dans cet article, consultez
les documents suivants :
Pour plus d'informations sur la sécurisation des
services Web, consultez les références
suivantes :
Pour des informations générales sur la
sécurité, reportez-vous à :
ANNEXE A
.gif)
figure 3. Diagramme permettant de déterminer la
méthode d'authentification la plus appropriée
(cliquez sur l'image pour l'agrandir) Collaborateurs
Merci aux réviseurs et à tous ceux qui ont permis
la rédaction de cet article, notamment :
Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro
(Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward
Jezierski, Alex Mackman, Mike Jenne, David Mowers, Amitabh
Srivastava, Steve Busby, Kenny Jones.
Dernière
mise à jour le lundi 12 novembre 2001