Conception d'une autorisation

Une autorisation représente la capacité à accéder à une ressource protégée ou à effectuer une opération protégée. Lorsque vous implémentez votre propre classe d'autorisations, vous devez prendre plusieurs décisions de design de haut niveau. L'une des premières étapes consiste à déterminer exactement la ressource que votre autorisation personnalisée est destinée à protéger.

Vous déciderez ensuite s'il n'y a pas de problèmes de chevauchement des autorisations. Bien que vous souhaitiez éviter que deux autorisations protègent la même ressource, dans certaines situations, vous ne pouvez pas raisonnablement l'éviter. Par exemple, l'autorisation d'accéder à du code non managé peut aussi englober d'autres autorisations, car du code ayant reçu l'autorisation d'accéder à du code non managé peut faire quasiment n'importe quoi par l'intermédiaire d'une interface API non managée. Cependant, lorsque l'autorisation d'accéder à du code non managé n'est pas octroyée, vous devez accorder les autorisations d'accéder à d'autres ressources spécifiques. Par conséquent, il est avisé de séparer l'autorisation d'accéder à du code non managé des autres autorisations.

Comment savez-vous si un chevauchement de la couverture des autorisations est gérable ? Il n'y a pas de réponse absolue, mais il faut savoir que si l'une des autorisations représente un accès plus fin que l'autre, elle sera généralement plus facilement octroyée. Lorsque c'est le cas, l'octroi de droits d'accès est aisé dans de nombreux cas, ce qui simplifie la tâche de l'administrateur.

Après avoir décidé de la ressource que votre autorisation protégera et résolu les problèmes de chevauchement des autorisations, vous devez décider de la finesse du contrôle d'accès. La réponse à cette question affecte la façon dont vous concevez les variables qui représentent l'état de l'autorisation et détermine si les administrateurs peuvent configurer l'accès à la ressource protégée. Cela peut aussi affecter la performance, la simplicité d'utilisation ainsi que d'autres facteurs.

Pour illustrer certains de ces problèmes de design, envisageons quelques designs qui auraient pu être choisis pour la classe FileIOPermission que le .NET Framework fournit. Chaque choix de design affecte les variables qui représentent l'état d'autorisation.

• Bit unique qui signifie « utiliser tous les fichiers » ou « n'utiliser aucun fichier », en fonction de sa valeur.

• Deux bits signifiant « lire tous les fichiers » et « écrire tous les fichiers » ou non, en fonction de leurs valeurs.

• 26 bits signifiant « utiliser tous les fichiers sur le lecteur spécifié ».

• Tableau de chaînes énumérant tous les fichiers auxquels l'accès est accordé.

Il y a clairement plusieurs compromis à prendre en compte. Par exemple, l'autorisation à bit unique est très simple, rapide et facile à comprendre, mais elle représente un choix tout ou rien pour les administrateurs, ce qui peut ne pas s'avérer souhaitable. D'autres choix spécifiant une représentation plus complexe de l'état d'autorisation pourraient ralentir la performance dans une certaine mesure. Vous devez peser ces compromis et ne pas oublier que vous ne devez pas créer plusieurs autorisations pour protéger la même ressource. Nous vous conseillons généralement de concevoir votre classe d'autorisations de sorte que l'état de l'autorisation ne soit pas plus complexe que nécessaire, sans avoir un impact considérable sur la performance.

Bien que d'autres designs soient possibles, la plupart des autorisations respectent l'un des modèles de design standard suivants ou une combinaison d'entre eux :

• Autorisations booléennes. Le type d'objet d'autorisation le plus simple contient un ou plusieurs bits, chacun correspondant à « l'autorisation de faire X ». Vous avez l'autorisation ou vous ne l'avez pas. Un exemple de ce type d'autorisation est la classe SecurityPermission, dont l'état contient les variables booléennes représentant le droit de faire différentes choses, telles que l'autorisation d'appeler dans du code non managé, chacune étant autorisée ou non.

• Niveaux d'autorisations. Cette forme d'autorisation plus granulaire a des variables représentant chaque type d'accès comme un chiffre, de zéro (correspondant à absolument aucun accès) jusqu'à un chiffre plus grand (correspondant à un accès totalement illimité), avec quelques niveaux entre les deux. Vous pouvez par exemple utiliser la classe UIPermission pour exprimer différents niveaux d'autorisation d'utiliser les fenêtres, d'aucune autorisation à une autorisation illimitée de l'interface utilisateur, avec quelques gradations entre les deux.

• Autorisations de liste d'objets. Ce type d'autorisation fournit une spécification très granulaire pour ce qui est autorisé ou non. La classe FileIOPermission est un bon exemple de ce type d'autorisation car son état est représenté par les listes de fichiers sur lesquels certains types d'accès sont autorisés. Les autorisations avec des listes sont plus pratiques pour protéger les ressources qui contiennent un grand nombre d'objets nommés.

Il est généralement souhaitable de minimiser les dépendances externes dans votre autorisation personnalisée car chaque assembly dont votre autorisation dépend devra être chargé lorsque le système de sécurité nécessite votre classe d'autorisations. De plus, chaque assembly utilisé par votre classe d'autorisations personnalisée (sauf Mscorlib) doit être ajouté à la liste ayant le niveau de confiance suffisant. (Pour plus d'informations, consultez Mise à jour de la stratégie de sécurité.) Si cela est possible, nous vous conseillons de placer votre autorisation personnalisée et les classes d'attributs qui y sont associées dans un assembly séparé, afin de réduire la probabilité que d'autres assemblys soient chargés inutilement.

Voir aussi

Concepts

Création de vos propres autorisations d'accès du code

Autres ressources

Sécurité d'accès du code