Demandes de sécurité
Pour s'assurer que seuls les appelants ayant reçu une autorisation spécifiée peuvent appeler votre code, vous pouvez demander de manière déclarative ou impérative que les appelants de votre code aient une autorisation ou un jeu d'autorisations spécifique. Une demande conduit le runtime à effectuer une vérification de sécurité afin d'appliquer les restrictions sur le code appelant. Pendant une vérification de sécurité, le runtime parcourt la pile des appels, en examinant les autorisations de chaque appelant dans la pile et en déterminant si l'autorisation demandée a été octroyée à chaque appelant. Si un appelant n'ayant pas l'autorisation demandée est trouvé, la vérification de sécurité échoue et SecurityException est levée. Les seules demandes qui n'entraînent pas de parcours de pile sont les demandes de liaison, qui ne vérifient que l'appelant immédiat.
Vous pouvez provoquer une vérification de sécurité chaque fois qu'une méthode particulière est appelée ou avant qu'un bloc particulier de code soit exécuté. Si vous souhaitez que la vérification de sécurité ait lieu lorsqu'un membre d'une classe particulière est appelé, vous pouvez placer une demande avant la classe de sorte qu'elle s'applique à chaque membre de la classe. La suite de cette rubrique explique comment effectuer des demandes de sécurité, quand le moment est opportun et quel type de demande de sécurité privilégier.
Si vous écrivez une bibliothèque qui accède directement à une ressource protégée et si cet accès est exposé à l'appelant, vous devez faire une demande de sécurité dans la bibliothèque pour vous assurer que tous les appelants dans la pile des appels ont l'autorisation d'accéder à cette ressource. Vos demandes peuvent être déclaratives ou impératives. Notez que les demandes ne doivent jamais être faites dans un constructeur de classe car il n'est pas garanti que le code du constructeur de classe s'exécute à un point particulier ou dans un contexte particulier. Étant donné que l'état de la pile des appels dans un constructeur de classe n'est pas bien défini, les demandes appliquées à des constructeurs de classe peuvent produire des résultats imprévus et indésirables.
Nous vous conseillons de suivre les indications suivantes, indépendamment du type de demande effectué :
Vérifiez que l'appelant provient d'une zone ou d'un site particulier ou a été signé par un éditeur particulier en exigeant que les appelants aient une autorisation d'identité particulière. Vous ne devez toutefois faire cela que lorsque vous octroyez un accès supplémentaire fondé sur la concordance avec une identité et non lorsque vous refusez l'accès sur la base de la concordance avec une identité. Étant donné qu'il est relativement simple de modifier ou de masquer l'identité du code, le refus d'accès fondé sur l'identité seule n'est pas une manière fiable de protéger votre code et les ressources auxquelles il accède à partir d'un accès non autorisé.
Vérifiez qu'un objet peut être créé uniquement par les appelants qui ont une autorisation spécifique en émettant la demande au niveau de la classe de cet objet. Supposez par exemple que vous ayez une classe appelée
myFileStream, qui dérive de la classe FileStream et que vous souhaitiez vous assurer que seuls les appelants autorisés peuvent créer des instances demyFileStream. Vous placerez une demande déclarative pour un objet FileIOPermission qui représente le droit d'accéder au flux créé parmyFileStreamau niveau classe de la classemyFileStream.Vous pouvez aussi mettre des demandes qui définissent ou obtiennent une propriété dans du code. Vous mettez généralement des demandes pour les autorisations moins restrictives sur l'accesseur get plutôt que sur l'accesseur set, à moins que la propriété ne contienne des informations sensibles telles qu'un mot de passe.
Notes
Les vérifications de sécurité basées sur les rôles ont une sémantique légèrement différente des vérifications de sécurité d'accès du code. Pour plus d'informations, consultez Sécurité basée sur les rôles.
Notes
Les demandes peuvent s'appliquer uniquement aux niveaux classe, méthode, événement et propriété ; les assemblys et les membres de variables individuelles non privées ne sont pas protégés par les demandes. Les demandes placées au niveau de l'assembly ou de la variable non privée n'entraîneront pas d'erreur de compilation. Par conséquent, il est important d'utiliser des propriétés au lieu des membres publics afin de garantir la protection que fournissent les demandes.
Voir aussi
Référence
Concepts
Écriture des bibliothèques de classes sécurisées