Autorisation des utilisateurs et des rôles
L' ASP.NET permet de contrôler l'accès des clients aux ressources d'URL. Elle peut être configurée pour la méthode HTTP utilisée pour lancer la demande (GET ou POST), ainsi que pour autoriser ou refuser l'accès à des groupes d'utilisateurs ou de rôles. Les exemples suivants représentent l'accès accordé à un utilisateur appelé John et à un rôle appelé Admins. L'accès est refusé à tous les autres utilisateurs.
<![CDATA[
<authorization>
<allow users="jdoe@contoso.com" />
<allow roles="Admins" />
<deny users="*" />
</authorization>
]]>
Les éléments admis pour les directives d'autorisation sont soit allow, soit deny. Chaque élément allow ou deny doit contenir un attribut users ou roles. Plusieurs utilisateurs ou rôles peuvent être spécifiés dans un élément unique si vous fournissez une liste en employant les virgules comme séparateurs.
<![CDATA[
<allow users="John,Mary" />
]]>
La méthode HTTP peut être indiquée à l'aide de l'attribut Verb :
<![CDATA[
<allow VERB="POST" users="John,Mary" />
<deny VERB="POST" users="*" />
<allow VERB="GET" users="*" />
]]>
Cet exemple permet à Mary et John d'effectuer une demande POST sur les ressources protégées et n'autorise les autres utilisateurs qu'à employer la méthode GET.
Il existe deux noms d'utilisateur spéciaux :
- * : Tous les utilisateurs
- ? : Utilisateurs anonymes (non authentifiés)
Ces noms d'utilisateur spéciaux sont couramment utilisés par les applications employant une authentification basée sur des formulaires pour refuser l'accès aux utilisateurs non authentifiés, comme le montre l'exemple suivant :
<![CDATA[
<authorization>
<deny users="?" />
</authorization>
]]>
L'autorisation d'URL est calculée de manière hiérarchique et les règles utilisées pour déterminer l'accès sont les suivantes :
- Les règles relatives à l'URL sont recueillies à partir de la hiérarchie et une liste de règles fusionnée est établie.
- Les règles les plus récentes sont placées au début de la liste. Autrement dit, la configuration du répertoire actif se trouve au début de la liste, suivie de la configuration du parent immédiat, etc. jusqu'au fichier de niveau supérieur de l'ordinateur.
- Les règles sont vérifiées jusqu'à ce qu'une correspondance soit trouvée. Si la correspondance est autorisée, l'accès est octroyé. Sinon, l'accès est interdit.
Cela signifie que les applications qui ne sont pas intéressées par l'héritage de leur configuration doivent configurer explicitement toutes les possibilités relatives à leurs applications.
Le fichier Web.config de niveau supérieur par défaut d'un ordinateur donné permet d'accéder à tous les utilisateurs. Si aucune application ne possède une configuration contraire (et en supposant qu'un utilisateur est authentifié et réussit la vérification ACL d'autorisation de fichier), l'accès est octroyé.
Lors de la vérification des rôles, l'autorisation d'URL parcourt de haut en bas la liste des rôles configurés et crée un pseudocode semblable au suivant :
if(User.IsInRole("ConfiguredRole")) {
ApplyRule();
}
If User.IsInRole("ConfiguredRole") Then
ApplyRule()
End If
if(User.IsInRole("ConfiguredRole")) {
ApplyRule();
}
|
|
C#
|
VB
|
JScript
|
|
Pour votre application, cela signifie que vous utilisez votre propre classe qui implémente System.Security.Principal.IPrincipal afin de fournir votre propre sémantique de mappage des rôles, de la manière décrite à la section Authentification Windows.
L'exemple suivant utilise les services d'authentification basés sur des formulaires. L'accès est explicitement refusé à jdoe@contoso.com et aux utilisateurs anonymes. Tentez d'ouvrir une session dans l'exemple en utilisant Username="jdoe@contoso.com" et Password="password". L'accès vous est refusé et vous êtes redirigé vers la page de connexion. À présent, ouvrez une session en tant que Username="mary@contoso.com" et Password="password". Vous pouvez constater que l'accès vous est octroyé.
| |
| VB Authentification basée sur des formulaires/par cookie avec autorisation d'URL |
|
|
Vérifiez
