Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
par Saad Ladki
Introduction
L’autorisation était difficile dans les versions précédentes d’IIS. Étant donné que IIS fonctionnait uniquement avec les identités Windows, vous deviez accéder au système de fichiers et définir les listes de contrôle d’accès sur les fichiers et les répertoires. Cette opération était fastidieuse, car l’interface utilisateur de la liste de contrôle d’accès est complexe et les règles d’autorisation ne se copient pas très bien d’un ordinateur à l’autre.
IIS 7.0 et les versions ultérieures utilisent l’autorisation d’URL. Elle vous permet d’appliquer des règles d’autorisation à l’URL proprement dite plutôt qu’à la ressource du système de fichiers sous-jacente. En outre, la configuration d’autorisation d’URL IIS est stockée dans les fichiers web.config. Vous pouvez distribuer des règles d’autorisation avec le contenu de l’application. La procédure pas à pas suivante vous présente la fonctionnalité d’autorisation d’URL IIS dans Windows Server® 2008 Beta 3 et Windows Vista Service Pack 1.
Prérequis
Cette procédure pas à pas nécessite l’installation des fonctionnalités IIS ci-dessus suivantes en plus de l’installation par défaut :
- « ASP.NET » sous « Internet Information Services » – « World Wide Web Services » – « Fonctionnalités de développement d’applications »
- « Autorisation d’URL » sous « Internet Information Services » – « World Wide Web Services » – « Sécurité »
Scénario
Nous allons simuler un scénario dans lequel vous disposez d’un répertoire sécurisé auquel seuls Alice, Bob et le groupe Administrateurs peuvent accéder. Dans ce répertoire, nous avons un fichier appelé bobsSecret.aspx auquel seul Bob est censé pouvoir accéder.
Configuration du scénario
Pour ce scénario, nous avons besoin de trois utilisateurs : Alice, Bob et Fred. Nous avons également besoin d’un nouveau groupe appelé BobAndFriends dont Alice et Bob sont membres. Créez les trois comptes et le groupe via le gestionnaire d’utilisateurs Windows ou en démarrant une invite de commandes avec élévation de privilèges et entrez les commandes suivantes.
net user Alice <password_of_your_choice> /add
net user Bob <password_of_your_choice> /add
net user Fred <password_of_your_choice> /add
net localgroup BobAndFriends /add
net localgroup BobAndFriends Alice /add
net localgroup BobAndFriends Bob /add
Ouvrez l’Explorateur et accédez au répertoire
%systemdrive%\inetpub\wwwroot
.Créez un répertoire appelé « sécurisé ».
Accédez au répertoire « sécurisé » et créez un fichier appelé « default.aspx ». Vous pouvez le faire avec le bloc-notes ou tout autre éditeur de texte.
Collez le code suivant dans la page default.aspx :
<%@Language="C#"%> <% string currentUser = Request.ServerVariables["LOGON_USER"]; if (currentUser == "") currentUser = "anonymous"; Response.Write("<b>Current User:</b> " + currentUser); %>
Créez un autre fichier appelé bobsSecret.aspx et collez-y le code suivant :
<%@Language="C#"%> <% string currentUser = Request.ServerVariables["LOGON_USER"]; if (currentUser == "") currentUser = "anonymous"; Response.Write("<b>Current User:</b> " + currentUser); Response.Write(" <b>My secret:</b> I used Apache before I discovered IIS7.</b> "); %>
Voyez maintenant si les deux pages web fonctionnent en demandant
http://localhost/secure/
ethttp://localhost/secure/bobsSecret.aspx
.
Configuration de l’authentification
L’authentification répond à la question « qui » souhaite avoir accès. L’autorisation répond à la question « si » le « qui » authentifié obtient effectivement l’accès. Par conséquent, avant d’expérimenter avec l’autorisation d’URL, nous devons activer l’authentification, car sans savoir « qui » veut avoir accès, nous ne pouvons pas répondre à la question « if ».
Démarrez INETMGR en tapant INETMGR dans le menu « Démarrer la recherche ».
Ouvrez le nœud de l’ordinateur dans l’arborescence de gauche, puis ouvrez le nœud « Site web par défaut », puis sélectionnez le répertoire « sécurisé ».
Double-cliquez sur « Authentication ».
Désactivez « Authentification anonyme » et activez « Authentification de base ».
À présent, demandez
http://localhost/secure
ethttp://localhost/secure/bobsSecret.aspx
à nouveau. Vous serez invité à entrer les informations d’identification. Entrez « Alice » comme nom d’utilisateur et son mot de passe. Vous serez authentifié en tant que « Alice ».Remarque
Si vous utilisez Internet Explorer, vous pouvez appuyer sur Ctrl+F5 afin qu’Internet Explorer actualise la version mise en cache de la page ASP.NET.
Configuration de l’autorisation d’URL
Maintenant, sécurisez les deux pages afin que seuls Alice et Bob y aient accès :
Double-cliquez sur le répertoire web « sécurisé » et sélectionnez « Règles d’autorisation ».
Supprimez la règle « Autoriser tous les utilisateurs ».
Cliquez sur « Ajouter une règle d’autorisation », puis sélectionnez la case d’option « Rôles ou groupes d’utilisateurs spécifiés : » et ajoutez « BobAndFriends », puis cliquez sur le bouton « OK ».
Fermez toutes les fenêtres Internet Explorer, car Internet Explorer met en cache les informations d’identification que vous avez entrées à l’étape précédente.
Ouvrez Internet Explorer et essayez d’accéder à la page à l’aide des informations d’identification de Fred. Vous n’avez pas accès.
Essayez maintenant les informations d’identification de Bob ou les informations d’identification d’Alice. Vous avez accès.
Configuration de l’autorisation d’URL pour une seule page web
Il reste le problème suivant : Alice peut toujours accéder à BobsSecret.aspx. Voici comment le corriger :
Double-cliquez sur le répertoire web « sécurisé » et sélectionnez « Affichage de contenu » en bas de la page.
Vous verrez une liste de fichiers dans le dossier sécurisé, à savoir « default.aspx » et « bobsSecret.aspx ».
Cliquez avec le bouton droit sur bobsSecret.aspx, puis sélectionnez « Affichage des fonctionnalités »
Vous n’effectuez maintenant que des modifications pour la page bobsSecret.aspx, comme indiqué dans la barre d’état.
Sélectionnez à nouveau « Règles d’autorisation ». Vous voyez les paramètres hérités, c’est-à-dire que le groupe BobsAndFriends est autorisé à accéder à bobsSecret.aspx.
Supprimez la règle « BobsAndFriends ».
Cliquez maintenant sur « Ajouter une règle d’autorisation... »
Cliquez sur la case d’option « Utilisateurs spécifiés : », entrez « Bob », puis cliquez sur « OK ».
Fermez toutes les fenêtres d’Internet Explorer et demandez
http://localhost/secure/bobsSecret.aspx
.Vous ne pourrez y accéder qu’en entrant les données d’identification de Bob.
Rubriques avancées sur l’autorisation d’URL
Les paragraphes suivants affichent certaines rubriques avancées sur l’autorisation d’URL.
Configuration
Vous n’avez pas besoin d’utiliser l’interface utilisateur pour spécifier les paramètres d’autorisation d’URL. Vous pouvez spécifier des règles d’autorisation d’URL directement dans votre fichier web.config. La section de configuration <d’autorisation> IIS est déléguée par défaut : vous pouvez distribuer des règles d’autorisation avec du contenu web. Ci-dessous, découvrez comment le fichier %systemdrive%\inetpub\wwwroot\secure\web.config
se présente après cette procédure pas à pas :
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="BobAndFriends" />
</authorization>
</security>
</system.webServer>
<location path="bobsSecret.aspx">
<system.webServer>
<security>
<authorization>
<remove users="" roles="BobAndFriends" verbs="" />
<add accessType="Allow" users="Bob" />
</authorization>
</security>
</system.webServer>
</location>
</configuration>
Différences entre l’autorisation d’URL ASP.NET et l’autorisation d’URL IIS
Il existe des différences minimes mais importantes entre l’autorisation d’URL ASP.NET et l’autorisation d’URL IIS. Les deux modules peuvent être installés via le programme d’installation IIS. L’autorisation d’URL IIS s’installe lorsque vous installez la fonctionnalité « Autorisation d’URL » dans l’interface utilisateur du programme d’installation IIS :
L’autorisation d’URL ASP.NET est installée lorsque vous installez ASP.NET sur IIS. Si vous êtes un expert ASP.NET, rappelez-vous que l’autorisation d’URL ASP.NET est implémentée dans le module System.Web.Security.UrlAuthorizationModule. La section de configuration correspondante est system.web/authorization. Voici l’entrée de configuration.
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />
Le module d’autorisation d’URL IIS est implémenté dans le module global urlauthz.dll.
<add name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" />
Il est important de garder à l’esprit que la condition préalable managedHandler se trouve sur le module d’autorisation d’URL ASP.NET. La condition préalable vous indique que le module d’autorisation d’URL est appelé uniquement lorsque le code qui gère la requête est mappé au code managé, généralement une page .aspx ou .asmx. En revanche, l’autorisation d’URL IIS s’applique à tout le contenu. Vous pouvez supprimer la condition préalable managedHandler du module d’autorisation d’URL ASP.NET. Elle est là pour éviter une pénalité de performances que vous devez payer lorsque chaque requête (par exemple, une requête vers de pages .html ou .jpg) doit passer par le code managé.
Évaluation des règles
Il existe également des différences dans l’ordre dans lequel IIS et les deux modules d’autorisation d’URL évaluent les règles d’autorisation. L’autorisation d’URL ASP.NET est axée sur les développeurs et les développeurs ont un contrôle total sur les règles qu’ils définissent. L’autorisation d’URL IIS garde l’administrateur à l’esprit et tente de s’assurer que les développeurs ne peuvent pas remplacer les règles définies par un administrateur.
exemple
Supposons que l’administrateur souhaite s’assurer que tous les utilisateurs d’un site particulier doivent être authentifiés. Pour ce faire, définissez la configuration suivante sur la racine du site :
<authorization lockElements="clear">
<add accessType="Deny" users="?" />
</authorization>
Cette configuration refuse l’accès aux utilisateurs anonymes (? = utilisateurs anonymes, * = tous les utilisateurs). Avec lockElements="clear", vous vous assurez que personne d’un niveau inférieur ne peut effacer l’héritage de ce paramètre. Votre paramètre est hérité de toutes les applications et répertoires virtuels de ce site. Il y a une violation de verrou lorsque vous essayez d’utiliser l’instruction <clear/> à un niveau inférieur.
Pour plus d’informations sur le verrouillage de la configuration, consultez Guide pratique pour verrouiller les paramètres de configuration ASP.NET.
Vous pouvez également verrouiller l’élément clear dans l’autorisation d’URL ASP.NET. Le problème est que l’autorisation d’URL ASP.NET évalue les règles d’autorisation du bas vers le haut, c’est-à-dire qu’elle évalue d’abord les règles dans le fichier web.config actuel avant d’évaluer les règles parentes. Dès qu’une correspondance est trouvée, l’accès est accordé ou refusé. Dans l’exemple ci-dessus, vous pouvez toujours accorder l’accès aux utilisateurs anonymes en spécifiant <add users="?"/> comme règle d’autorisation dans le fichier web.config sécurisé. Étant donné qu’il est évalué en premier, les utilisateurs anonymes se verraient accorder l’accès.
Le module d’autorisation d’URL IIS évalue d’abord les règles de refus. Étant donné que vous refusez l’accès aux utilisateurs anonymes, vous ne pouvez pas simplement remplacer cette règle. L’autre grande différence est que les règles parentes sont évaluées en premier. Cela signifie que si vous refusez l’accès à Fred à un niveau supérieur, vous ne pouvez pas autoriser l’accès à Fred à un niveau inférieur.
Tableau des différences
Différence | Comportement d’autorisation d’URL ASP.NET | Comportement d’autorisation d’URL IIS |
---|---|---|
Évaluation des règles | Ordre : a) Du niveau inférieur jusqu’au parent b) Dans l’ordre d’apparition dans la collection de règles | Ordre : a) Les règles de refus sont évaluées en premier en commençant par les parentes b) Autoriser les règles à partir du parent. c) Ordre d’apparition dans la collection de règles |
Interface utilisateur IIS | Aucune interface utilisateur IIS | Interface utilisateur « Règles d’autorisation » |
Section de configuration | system.web/authorization | system.webServer/security/authorization |
Module | System.Web.Security.UrlAuthorization | %windir%\system32\inetsrv\urlauthz.dll |
Contenu | S’applique uniquement au contenu mappé à un gestionnaire managé (peut être désactivé via la condition préalable managedHandler) | S’applique à tout le contenu |
Utilisation de comptes et de groupes de domaine
Vous devez spécifier des comptes et des groupes de domaine à l’aide des éléments suivants :
<domainname or username>\<user>
Cet exemple utilise le machinename, en supposant que nos comptes ont été créés sur l’ordinateur iis7test :
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="iis7test\BobAndFriends" />
</authorization>
</security>
</system.webServer>
<location path="bobsSecret.aspx">
<system.webServer>
<security>
<authorization>
<remove users="" roles="iis7test\BobAndFriends" verbs="" />
<add accessType="Allow" users="iis7test\Bob" />
</authorization>
</security>
</system.webServer>
</location>
</configuration>
Utilisation d’identités non-Windows
L’autorisation d’URL n’est pas uniquement destinée aux identités Windows. Elle fonctionne bien pour les identités non-Windows également. Utilisez-la avec l’appartenance et les rôles ASP.NET et pour les identités personnalisées, au cas où vous écrivez votre propre module d’authentification.
Résumé
L’autorisation d’URL est un nouveau moyen puissant de spécifier des règles d’autorisation pour les applications web. Vous pouvez maintenant spécifier des règles en XML sans utiliser de listes de contrôle d’accès Windows.