Sécurité d'accès du code dans les applications ASP.NET 4

La sécurité d'accès du code (CAS, Code Access Security) correspond au mécanisme de sécurité .NET Framework (« bac à sable (sandbox) ») utilisé par ASP.NET pour appliquer des contraintes quant à la possibilité d'exécuter du code. ASP.NET a implémenté la sécurité d'accès du code depuis ASP.NET 1.1, en utilisant le concept des niveaux de confiance.

Cette rubrique décrit le fonctionnement de la sécurité d'accès du code dans ASP.NET 4, en mettant l'accent sur les modifications dont elle a fait l'objet depuis les versions antérieures. Si vous faites partie des nouveaux utilisateurs d'ASP.NET, ces modifications ne vous intéressent probablement pas. Toutefois, cette rubrique contient des informations sur le fonctionnement de la sécurité d'accès du code dans la version actuelle d'ASP.NET, ce qui peut vous orienter en termes de conception de nouvelles applications.

Cette rubrique traite des sujets suivants :

• Pourquoi les niveaux de stratégie de sécurité d'accès du code ne sont plus utilisés, et comment cela affecte des scénarios standard tels que le fait de permettre aux applications ASP.NET de confiance partielle de s'exécuter à partir des partages UNC.

• Comment personnaliser le comportement de la sécurité d'accès du code dans ASP.NET 4.

• Problèmes de compatibilité lorsque vous permettez au code de confiance de fonctionner avec la sécurité d'accès du code dans ASP.NET 4.

Cette rubrique suppose que vous comprenez la sécurité d'accès du code .NET Framework et les niveaux de confiance ASP.NET. Pour plus d'informations sur ces rubriques, consultez les documents suivants :

• How to: Use Medium Trust in ASP.NET 2.0 (page éventuellement en anglais)

• Utilisation de la sécurité d'accès au code avec ASP.NET

• Modifications de sécurité dans le .NET Framework 4

• Blog series about CAS policy and the CLR, by Shawn Farkas (page éventuellement en anglais)

• Cette rubrique contient les informations suivantes :

• Vue d'ensemble du modèle ASP.NET 4 de sécurité d'accès du code

• Domaines d'application homogènes

• APTCA conditionnel

• Transparence de la sécurité et fonctionnement dans ASP.NET 4

Vue d'ensemble du modèle ASP.NET 4 de sécurité d'accès du code

Dans ASP.NET 4, plusieurs modifications fondamentales ont été apportées à la sécurité d'accès du code depuis ASP.NET 3.5 et versions antérieures, notamment celles qui suivent :

• Par défaut, les domaines d'application de confiance partielle d'ASP.NET 4 sont homogènes. Un jeu limité d'autorisations possibles est ainsi généré pour le code qui s'exécute dans un domaine d'application de confiance partielle. Cela signifie également que la limite de confiance du domaine d'application est elle-même associée à un jeu d'autorisations de confiance partielle. Dans les domaines d'application homogènes, la stratégie de sécurité ne recoupe pas les stratégies de sécurité d'accès du code au niveau de l'ordinateur, de l'utilisateur ou de l'entreprise.

  Notes

  Le nouveau modèle de domaine d'application homogène nécessite un ensemble de fichiers de stratégie d'approbation ASP.NET déclaratifs légèrement différent des fichiers de stratégie utilisés dans les versions antérieures d'ASP.NET.Par conséquent, une fois que vous avez installé ASP.NET 4, l'ordinateur contient deux ensembles de fichiers de stratégie de confiance partielle ASP.NET.Le nouveau modèle de sécurité d'accès du code utilise un ensemble, tandis que l'autre ensemble est utilisé lorsque les applications sont configurées pour utiliser le modèle de sécurité d'accès du code antérieur à ASP.NET 4.

• Dans les versions antérieures d'ASP.NET, l'attribut AspNetHostingPermission était utilisé sur presque toutes les classes ASP.NET publiques pour empêcher l'utilisation des types ASP.NET dans des environnements de confiance partielle non Web. Par exemple, la présence de l'attribut AspNetHostingPermission empêchait l'utilisation de la plupart des classes ASP.NET dans une application ClickOnce de confiance partielle. (Pour plus d'informations sur la sécurité d'accès du code dans les applications ClickOnce, consultez Sécurité d'accès du code pour les applications ClickOnce.) Au lieu d'utiliser l'attribut AspNetHostingPermission, ASP.NET 4 emploie une autre technologie de sécurité d'accès du code appelée APTCA conditionnel (basée sur le type AllowPartiallyTrustedCallersAttribute) pour obtenir le même résultat. Par conséquent, l'attribut AspNetHostingPermission a été supprimé de la plupart des membres et des types ASP.NET.

• Dans ASP.NET 4, un grand nombre d'assemblys système ont été mis à jour pour utiliser le modèle de transparence de sécurité CLR. Le modèle de transparence dans ASP.NET 4 est très similaire à celui utilisé dans Silverlight. Pour plus d'informations sur la transparence du code, consultez Code transparent de sécurité (security-transparent).

Vous voyez les effets de ces modifications si vous avez utilisé les stratégies de sécurité d'accès du code CLR personnalisées qui ont été créées à l'aide d'outils comme caspol.exe. Les modifications affecteront également les applications Web de confiance partielle qui dépendent des assemblys déployés dans le GAC pour effectuer des opérations nécessitant des privilèges, lorsque du code ASP.NET ou .NET Framework uniquement était actif sur une pile des appels. Les sections suivantes décrivent les modifications CAS.

Domaines d'application homogènes

Cette section décrit les domaines d'application homogènes. Elle explique les changements de comportement depuis ASP.NET 2.0 qui résultent des domaines d'application homogènes. Elle indique également les options de compatibilité pouvant être définies et les modifications de code que vous pouvez effectuer pour exécuter du code dans les domaines d'application homogènes.

Nombre limité de jeux d'autorisations possibles

Les domaines d'application homogènes sont des domaines d'application de confiance partielle qui définissent un jeu d'autorisations partagé pour exécuter le code. Dans un domaine d'application homogène qui est hébergé dans ASP.NET 4, le code pouvant être chargé est associé à l'un des deux jeux d'autorisations. Le code s'exécute avec un niveau de confiance totale (le code du GAC s'exécute toujours avec un niveau de confiance totale) ou avec le jeu d'autorisations de confiance partielle défini par le paramètre trustLevel actuel. (Pour plus d'informations, consultez trustLevel, élément de securityPolicy (Schéma des paramètres ASP.NET)).

Notes

Par défaut, les domaines d'application ASP.NET 4 ont un niveau de confiance totale.Le comportement homogène dans ASP.NET 4 entre uniquement en vigueur une fois que l'attribut name de l'élément trustLevel a une valeur autre que Full.

Ce comportement est différent des applications de confiance partielle dans les versions antérieures d'ASP.NET. Dans les versions antérieures, vous pouviez créer plusieurs jeux d'autorisations ayant chacun des conditions d'appartenance et des jeux accordés différents. Les domaines d'application homogènes ont été introduits dans .NET Framework 4 en raison de la difficulté à gérer les scénarios d'autorisations mixtes comme ceux-ci. Il était difficile de créer plusieurs jeux d'autorisations ayant chacun des niveaux d'autorisations différents, puis de vérifier que ces différents niveaux étaient réellement appliqués, après avoir pris en considération toutes les conditions selon lesquelles le code pouvait s'exécuter. Par exemple, le code pouvait s'exécuter via la réflexion, le code de confiance totale pouvait exécuter un autre code de confiance totale pour le compte d'un appelant de confiance partielle, et ainsi de suite. Le jeu d'autorisations devait prendre en compte toutes ces conditions. Les domaines d'application homogènes simplifient considérablement les décisions CAS en réduisant les résultats possibles. Le code a un niveau de confiance totale ou possède un jeu d'autorisations de confiance partielle unique et bien défini. Pour ASP.NET, le jeu d'autorisations de confiance partielle bien défini s'applique à un niveau de confiance ASP.NET spécifié.

Il existe un troisième état possible pour le code qui tente de se charger dans un domaine d'application homogène. (Cela n'est pas considéré par le CLR comme un jeu d'autorisations distinct.) Le troisième jeu d'autorisations est le jeu d'autorisations vide, défini comme le jeu d'autorisations Nothing dans tous les fichiers de configuration de confiance partielle d'ASP.NET. Tout code avec le jeu d'autorisations Nothing est considéré comme impossible à charger. Par conséquent, toute tentative de chargement, dans un domaine d'application homogène, d'assemblys ayant le jeu d'autorisations Nothing lève une exception SecurityException.

Seule la stratégie de confiance partielle ASP.NET s'applique

Le jeu d'autorisations de confiance partielle d'un domaine d'application homogène est établi uniquement par l'hôte chargé de la création du domaine d'application. Dans ASP.NET 4, cela signifie que le jeu d'autorisations de confiance partielle est défini uniquement par le contenu d'un fichier de configuration de confiance partielle situé dans le sous-répertoire CONFIG de l'installation .NET Framework. Par défaut, les informations de stratégie ASP.NET pour les domaines d'application de confiance partielle ASP.NET 4 ne chevauchent plus les paramètres de stratégie CAS au niveau de l'entreprise, de l'ordinateur ou de l'utilisateur.

Les informations de stratégie CAS globales (stratégie que les développeurs géraient avant à l'aide d'outils tels que caspol.exe ou l'outil de configuration MMC Mscorcfg.msc) n'ont plus d'influence sur les domaines d'application homogènes d'ASP.NET 4. (Vous pouvez configurer ASP.NET pour utiliser le modèle CAS antérieur, dans lequel les paramètres ASP.NET recoupent la stratégie au niveau de l'entreprise, de l'ordinateur et de l'utilisateur. Ce comportement hérité est expliqué dans une section ultérieure.)

La modification la plus évidente concerne les applications ASP.NET 4 de confiance partielle hébergées sur UNC. Dans les versions précédentes, vous deviez utiliser caspol.exe afin d'élever les partages UNC au niveau de confiance totale, pour que les stratégies de confiance partielle d'ASP.NET entrent en vigueur. En effet, dans les versions antérieures d'ASP.NET, la stratégie CAS par défaut du CLR au niveau de l'ordinateur était appliquée en premier. Par conséquent, les applications hébergées sur UNC avaient un jeu limité d'autorisations associé à la zone Intranet. Étant donné que les domaines d'application de confiance partielle d'ASP.NET 4 établissent la stratégie à partir de fichiers de stratégie ASP.NET uniquement, l'emplacement physique d'une application Web n'a plus d'impact sur le jeu d'autorisations associé à une application de confiance partielle.

Un effet secondaire de ce changement est illustré par le scénario dans lequel un administrateur veut verrouiller un serveur Web pour refuser par défaut les autorisations d'exécution à tout le code managé, puis accorder les droits d'exécution pour des applications ASP.NET sélectionnées. Dans les versions antérieures d'ASP.NET, cette situation impliquait une solution de contournement peu connue, comme documenté dans l'article de la Base de connaissances CORRECTIF : message d'erreur lorsque vous essayez d'exécuter une application Web ASP.NET 2.0 si vous n'associez pas le groupe de code My_Computer_Zone avec le jeu d'autorisations « confiance totale » : « Server applications n'est pas disponible ». Dans ASP.NET 4, un administrateur peut verrouiller un serveur Web pour refuser ou accorder des autorisations d'exécution en suivant ces étapes :

1. Créer un niveau de confiance ASP.NET personnalisé dont le fichier de stratégie mappe tout le code au jeu d'autorisations Nothing (jeu d'autorisations vide), puis configurer toutes les applications ASP.NET pour utiliser ce niveau de confiance par défaut. (Cette opération s'effectue dans le fichier Web.config racine.)

2. Associer sélectivement des applications ASP.NET individuelles à des niveaux de confiance intégrés ou personnalisés qui accordent des autorisations d'exécution (et toute autre autorisation requise) à du code managé. Pour la mise en application au niveau de l'ordinateur, vous pouvez assigner sélectivement des niveaux de confiance à l'aide d'éléments location dans le fichier Web.config racine.

Emplacement et conventions d'attribution des noms pour les fichiers de stratégie d'approbation

L'emplacement et la convention d'attribution des noms des fichiers de stratégie CAS sont les mêmes que dans les versions antérieures d'ASP.NET. Les niveaux de confiance par défaut sont Full, High, Medium, Low et Minimal. Les fichiers de stratégie qui définissent les jeux d'autorisations de confiance partielle de High à Minimal sont tous situés dans le sous-répertoire CONFIG du répertoire d'installation .NET Framework.

Les fichiers de stratégie sont nommés selon le modèle suivant :

web_[trustlevelname]trust.config

Par exemple, le jeu d'autorisations de confiance partielle pour la confiance Medium se trouve dans le fichier nommé web_mediumtrust.config.

Modifications dans les fichiers de stratégie d'approbation pour ASP.NET 4

La plupart des informations contenues dans les fichiers de stratégie CAS ASP.NET 4 sont les mêmes que celles situées dans les fichiers de stratégie des versions précédentes. Toutefois, des ajouts mineurs ont été effectués pour les fonctionnalités .NET Framework 3.5 et .NET Framework 4. Le nom du jeu d'autorisations de confiance partielle associé à un domaine d'application homogène est ASP.Net. De plus, par défaut, tout le code situé dans une structure de répertoires d'application Web ou la structure de répertoires de génération de code se voit accorder des autorisations du jeu d'autorisations ASP.Net nommé.

Deux modifications ont été apportées aux fichiers de stratégie de confiance partielle depuis les versions précédentes :

• À la fin de chaque fichier de stratégie CAS ASP.NET 4, un élément CodeGroup ne mappe plus la confiance totale à une clé de signature Microsoft et à la clé de signature ECMA. Ces entrées ont été supprimées dans ASP.NET 4 car il s'agissait d'un héritage de versions antérieures, lorsque le GAC n'était pas toujours implicitement supposé bénéficier de la confiance totale.

• La partie Assertion de l'attribut SecurityPermission a été supprimée dans tous les fichiers de stratégie CAS ASP.NET 4. Une modification fondamentale effectuée par le CLR dans .NET Framework 4 est l'impossibilité, pour le code de confiance partielle, de déclarer des autorisations. Cela signifie que le code de confiance partielle échouera même s'il tente de déclarer des autorisations qu'il possède déjà.

Portée de la confiance partielle

Les domaines d'application homogènes signifient que les limites de domaine d'application ASP.NET 4 sont dotées d'un niveau de confiance partielle. Lorsqu'une application s'exécute en confiance partielle, les demandes de sécurité entraînent un parcours de pile. Tout le code sur la pile est évalué par rapport aux autorisations demandées. Dans les domaines d'application pour ASP.NET 3.5 et versions précédentes, il était courant que les chemins de code entraînent un parcours de pile jusqu'à la limite de domaine d'application. Étant donné que les limites de domaine d'application dans les versions antérieures à ASP.NET 4 bénéficiaient implicitement de la confiance totale, les parcours de pile pour certains chemins de code réussissaient. Dans les domaines d'application homogènes d'ASP.NET 4, tout parcours de pile qui atteint la limite de domaine d'application est évalué par rapport au jeu d'autorisations de confiance partielle qui est actuellement appliqué pour le domaine d'application.

La limite de domaine d'application, maintenant de confiance partielle, explique le changement CAS le plus commun qui en général requiert la modification du code de confiance totale pour qu'il fonctionne dans ASP.NET 4. Par exemple, l'équipe de développement ASP.NET devait ajouter des assertions de sécurité ciblées sur de nombreux chemins de code internes afin de supprimer les demandes de sécurité et de les empêcher de se propager jusqu'à la limite de domaine d'application. Si l'équipe de développement n'avait pas effectué cette opération, les tâches de base comme la compilation de page échoueraient car les demandes de sécurité pour ce types d'opérations (par exemple, autorisations E/S de fichier pour la compilation) auraient échoué en cas de comparaison avec le jeu d'autorisations de confiance partielle pour les niveaux de confiance comme Medium.

Il existe des points d'extensibilité dans ASP.NET qui peuvent entraîner le chargement et l'exécution du code d'un niveau de confiance totale lorsque le code ASP.NET uniquement est sur la pile. Dans ces scénarios, seul le code ASP.NET se trouve initialement sur la pile lorsque ASP.NET effectue un appel dans un type personnalisé qui implémente un certain type de point d'extensibilité. Si le type personnalisé a un niveau de confiance totale (ce qui ne doit se produire que s'il est déployé dans le GAC), l'intégralité de la pile des appels se compose de code d'un niveau de confiance totale. Dans un domaine d'application homogène, si du code dans un type d'extensibilité d'un niveau de confiance totale déclenche une demande de sécurité, cette demande finira par atteindre la limite de domaine d'application. Elle échouera ensuite lors de la vérification de la sécurité selon le jeu d'autorisations de confiance partielle.

Voici une liste de certains points d'extensibilité ASP.NET pour lesquels cette situation est possible :

• Gestionnaire HTTP personnalisé. Un gestionnaire personnalisé est appelé pendant la phase d'exécution du pipeline par le gestionnaire.

• Module HTTP personnalisé. Un module HTTP personnalisé est appelé pendant tous les événements de pipeline pour lesquels le module a été enregistré.

• Générateurs d'expressions et fournisseurs de générations personnalisés. Ces types sont appelés par ASP.NET lorsqu'il analyse et compile du contenu exécutable tel que les fichiers .aspx.

• Fournisseur du gestionnaire de rôles. Un fournisseur personnalisé peut être appelé pendant l'événement AuthorizeRequest dans le pipeline.

• Fournisseur de profils. Un fournisseur personnalisé peut être appelé pour enregistrer automatiquement des données de profil pendant l'événement EndRequest.

• Fournisseur d'analyse de fonctionnement. Un fournisseur personnalisé peut être appelé à des moments arbitraires pour stocker des données d'analyse de fonctionnement supplémentaires.

Un exemple simple d'un gestionnaire HTTP personnalisé illustre le changement de comportement de sécurité d'accès du code. Dans l'exemple suivant, le code du gestionnaire essaie de lire un fichier texte situé à la racine du lecteur C:\.

Public Class CustomHandler 
    Implements IHttpHandler 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

public class CustomHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

Si le gestionnaire est signé, marqué avec l'attribut AllowPartiallyTrustedCallersAttribute et déployé dans le GAC, le code réussit lorsque le gestionnaire est utilisé dans une application disposant du niveau de confiance moyen dans ASP.NET 3.5 ou version antérieure. La confiance moyenne est choisie pour cet exemple car avec ce niveau de confiance, le jeu d'autorisations de confiance partielle autorise uniquement l'entrée/sortie (E/S) de fichier en lecture/écriture pour la structure de répertoires de l'application. Le code d'un niveau de confiance totale (exemple de gestionnaire) peut accéder à d'autres emplacements de fichiers dans ASP.NET 3.5 et versions antérieures. En effet, lorsque le gestionnaire s'exécute, seul le code d'un niveau de confiance totale se trouve sur la pile, et la limite de domaine d'application elle-même bénéficie d'un niveau de confiance totale. Par conséquent, la demande d'E/S de fichier de l'appel ReadAllText est satisfaite implicitement par la limite de domaine d'application qui bénéficie d'une confiance totale.

Toutefois, si le même code de gestionnaire est utilisé dans une application ASP.NET 4 de confiance moyenne, il échouera, car l'appel à ReadAllText provoque une demande d'E/S de fichier pour l'accès en lecture au fichier texte. La demande d'E/S de fichier entraîne un parcours de pile qui atteint finalement la limite de domaine d'application. Dans ASP.NET 4, la limite de domaine d'application est associée au jeu d'autorisations de confiance moyenne, et ce jeu d'autorisations n'accorde pas l'accès à la racine du lecteur C:\. Par conséquent, la demande d'E/S de fichier échoue.

Pour ASP.NET 4, vous devez supprimer le parcours de la pile. Pour ce faire, utilisez l'attribut SecurityAction.Assert de l'attribut FileIOPermission sur la méthode ProcessRequest. L'exemple suivant montre comment utiliser un attribut FileIOPermission à cet effet.

[Visual Basic]

Public Class CustomHandler 
    Implements IHttpHandler 

    <FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _ 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

[C#]

public class CustomHandler : IHttpHandler

{

[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

Vous pouvez utiliser des assertions déclaratives (comme indiqué dans l'exemple) ou des assertions de programmation. Il est conseillé de procéder à une assertion déclarative des autorisations les plus restreintes nécessaires pour obtenir un bloc de code correct. Bien qu'il puisse sembler facile d'ajouter des assertions de sécurité non restreinte partout, cette approche ne doit pas être utilisée. Les défaillances de sécurité provoquées par le nouveau comportement des domaines d'application homogènes ont pour but de vous faire analyser le code de confiance totale et comprendre quelles opérations nécessitant des privilèges sont requises par le code de confiance totale. Vous pouvez ensuite procéder à une assertion sélective du jeu d'autorisations le plus restreint qui est obligatoire pour réactiver le code de confiance totale.

Configuration d'applications ASP.NET 4 pour utiliser le modèle CAS ASP.NET 2.0

Il est possible de configurer des applications ASP.NET 4 pour utiliser les comportements CAS ASP.NET 1.0 et ASP.NET 2.0. Dans ASP.NET 4, l'élément trust fournit un nouvel attribut legacyCasModel qui a par défaut la valeur false. Si cet attribut a pour valeur true, une application ASP.NET 4 est configurée pour utiliser la majeure partie (mais pas la totalité) du comportement de sécurité d'accès du code ASP.NET des versions antérieures.

Lorsque l'attribut LegacyCasModel a la valeur true, les comportements suivants se produisent :

• Les limites de domaine d'application de confiance partielle utilisent la confiance totale. Cela signifie que pour les scénarios dans lesquels le code de confiance totale s'exécute avec uniquement du code de confiance totale sur la pile, vous n'avez pas à utiliser des assertions pour supprimer les demandes de sécurité.

• Les paramètres pour les stratégies CAS au niveau de l'entreprise, de l'ordinateur et de l'utilisateur qui sont définis pour .NET Framework 4 recoupent la stratégie CAS ASP.NET. Cela signifie que toutes les autorisations personnalisées qui sont créées à l'aide de l'outil .NET Framework 4 caspol.exe ou Mscorcfg.msc prennent effet.

  Notes

  Dans la mesure où les fichiers de stratégie de sécurité de base et l'outil caspol.exe pour .NET Framework 4 se trouvent dans un répertoire différent de celui de .NET Framework 2.0, toute stratégie de sécurité personnalisée créée pour .NET Framework 2.0 doit être recréée pour .NET Framework 4 à l'aide de la version .NET Framework 4 de caspol.exe.

• Vous pouvez spécifier plusieurs jeux d'autorisations personnalisés qui s'appliquent à différents assemblys.

Même en mode CAS hérité, les comportements CAS suivants ne changent pas :

• ASP. Les assemblys NET 4 sont encore marqués comme APTCA conditionnel. (L'attribut APTCA conditionnel est décrit ultérieurement dans cette rubrique.) Le mode hérité ne peut pas être rétabli pour l'APTCA conditionnel, car cela impliquerait la suppression de l'attribut AspNetHostingPermission de la plupart des API ASP.NET 4 publiques. Il n'existe aucune méthode efficace pour appliquer cette autorisation aux API publiques ASP.NET lorsqu'elles s'exécutent en mode CAS hérité, mais ne pas l'appliquer lorsque les assemblys s'exécutent dans le nouveau modèle CAS.

• Le code de confiance partielle n'est plus autorisé à déclarer des autorisations. Le code auquel était précédemment accordé la confiance partielle pouvait appeler la méthode Assert et déclarer correctement toute autorisation qui lui avait déjà été accordée. Dans .NET Framework 4, quel que soit le modèle CAS appliqué pour une application ASP.NET, le code de confiance partielle n'est plus autorisé à exécuter des assertions de sécurité.

Pour distinguer les jeux d'autorisations qui s'appliquent dans le modèle CAS hérité du jeu d'autorisations unique qui s'applique dans le nouveau modèle CAS, lorsque l'attribut LegacyCasModel de l'élément trust a la valeur true, ASP.NET 4 lit la stratégie CAS à partir d'un ensemble différent de fichiers de configuration de confiance partielle. Pour chaque fichier de stratégie d'approbation existant pour les niveaux de confiance intégrés d'ASP.NET, il existe deux versions du fichier. ASP.NET lit une version pour le nouveau modèle CAS et l'autre version pour le modèle CAS hérité. Par exemple, pour le niveau de confiance moyenne, lorsque ASP.NET 4 s'exécute en mode hérité, il lit le fichier de stratégie nommé legacy.web_mediumtrust.config. Remarquez que le début du nom de fichier est "legacy". ASP.NET 4 utilise la même convention d'affectation des noms pour tous les fichiers de stratégie CAS et les niveaux de confiance ASP.NET intégrés. La différence principale entre les fichiers de stratégie CAS hérités et ceux non hérités est que les fichiers hérités incluent la définition CodeGroup qui référence la clé de signature Microsoft et la clé de signature ECMA.

Dans la mesure où vous pouvez configurer une application pour qu'elle utilise l'ancien modèle CAS, vous voulez peut-être, pour les applications existantes, affecter à l'option LegacyCasModel la valeur true et ainsi éviter d'apporter des modifications. Toutefois, il est important de comprendre que l'option héritée existe principalement pour faciliter la transition des applications existantes vers le modèle CAS ASP.NET 4. Dans le futur, les équipes ASP.NET et CLR se concentreront sur la conception et le codage avec le nouveau modèle CAS.

Silverlight 2 fut la première zone de fonctionnalités du .NET Framework à migrer vers le nouveau modèle. L'objectif pour le .NET Framework est de migrer tous les scénarios de confiance partielle bureau et serveur pour qu'ils s'exécutent sur le nouveau modèle CAS. Par conséquent, nous vous recommandons de ne pas négliger l'importance de permettre à nouveau aux applications de fonctionner dans le modèle CAS. De la même façon, les administrateurs qui utilisaient avant caspol.exe et Mscorcfg.msc doivent maintenant personnaliser les fichiers de stratégie de confiance partielle ASP.NET et les assignations d'autorisation.

Personnalisation de l'assignation des jeux d'autorisations dans le modèle CAS ASP.NET 4

Même si les domaines d'application homogènes d'ASP.NET 4 imposent au code un niveau de confiance totale ou le jeu d'autorisations nommé de niveau de confiance partielle d'ASP.NET, les développeurs et les administrateurs peuvent influencer la façon dont un jeu d'autorisations est associé à un assembly. Les approches suivantes vous permettent de personnaliser le processus d'association d'un jeu d'autorisations à une partie du code d'exécution :

• Vous pouvez personnaliser le fichier de stratégie de confiance partielle pour un niveau de confiance individuel. (Il s'agissait d'une approche possible dans les versions antérieures d'ASP.NET.)

• Vous pouvez configurer statiquement des assemblys de confiance totale d'ASP.NET 4.

• Vous pouvez utiliser le type HostSecurityPolicyResolver d'ASP.NET 4 pour accéder aux fonctionnalités de la classe HostSecurityManager CLR avec des contraintes.

Les deux premières approches vous permettent d'effectuer des personnalisations de façon déclarative, alors que la troisième option vous permet de procéder à des personnalisations dans le code.

Personnalisation de fichiers de stratégie pour un niveau de confiance

La première approche pour modifier les fichiers de stratégie de confiance partielle d'ASP.NET est la même que dans les versions antérieures d'ASP.NET : vous pouvez modifier le jeu d'autorisations dans le jeu d'autorisations nommé d'ASP.NET. Vous pouvez également ajouter des définitions CodeGroup supplémentaires qui ont des conditions d'appartenance personnalisées. Comme indiqué précédemment, les nouvelles personnalisations CAS doivent être effectuées dans les fichiers de stratégie de confiance partielle tels que web_mediumtrust.config. Les fichiers dont le nom commence par "legacy" sont analysés et utilisés lorsque l'attribut LegacyCasModel de l'élément trust a la valeur true.

Pour ASP.NET 4, toutes les définitions CodeGroup personnalisées doivent être mappées à l'un des trois jeux d'autorisations possibles : FullTrust, ASP.Net (autrement dit, le jeu d'autorisations de confiance partielle) ou Nothing. Étant donné que les domaines d'application de confiance partielle d'ASP.NET 4 sont homogènes par défaut, les entrées de stratégie personnalisées doivent correspondre à un jeu limité d'autorisations. Même si vous pensez pouvoir définir des jeux d'autorisations nommés différents lorsque vous utilisez le modèle CAS d'ASP.NET 4, tout code qui correspond à un jeu d'autorisations autre que FullTrust, ASP.Net ou Nothing lèvera une exception SecurityException lors de l'exécution. Cela indique que le CLR n'a pas reconnu le jeu d'autorisations évalué.

Le jeu d'autorisations FullTrust indique que le code s'exécute en mode confiance totale. Le jeu d'autorisations ASP.Net est le jeu d'autorisations de confiance partielle nommé qui est généralement utilisé pour les domaines d'application de confiance partielle. Comme décrit précédemment, Nothing n'est pas un jeu d'autorisations réel reconnu par le CLR ; il s'agit du jeu d'autorisations vide. Si le CLR détermine qu'un assembly est associé à un jeu d'autorisations vide, il lève une exception SecurityException et ne charge pas l'assembly.

De plus, ASP.NET 4 vous permet de modifier le nom du jeu d'autorisations ASP.Net à l'aide de l'attribut PermissionSetName de l'élément trust. Vous pouvez définir un nom différent pour l'attribut PermissionSetName. Au moment de l'exécution, ASP.NET 4 recherchera un élément PermissionSet du même nom dans le fichier de stratégie de confiance partielle. Ce jeu d'autorisations nommé sera ensuite utilisé comme jeu d'autorisations de confiance partielle pour un domaine d'application homogène. Il est peu probable que vous ayez à faire cela. Toutefois, la possibilité d'affecter au jeu d'autorisations de confiance partielle un nom différent de ASP.Net a été ajoutée pour s'adapter aux environnements d'hébergement comme SharePoint, qui définissent leur propre jeu d'autorisations nommé comme une entité distincte du jeu d'autorisations par défaut d'ASP.NET. (Souvenez-vous que dans le nouveau modèle CAS, il n'est plus possible d'avoir plusieurs jeux d'autorisations nommés qui définissent des autorisations de confiance partielle.) Bien que vous puissiez affecter au jeu d'autorisations de confiance partielle un nom différent de ASP.Net, il ne peut y avoir encore qu'un seul jeu d'autorisations de confiance partielle en vigueur pour une application.

Spécification des assemblys auxquels la confiance totale sera accordée

La deuxième personnalisation de stratégie déclarative est une nouvelle fonctionnalité d'ASP.NET 4, qui vous permet d'établir explicitement une liste des identités d'assembly auxquelles la confiance totale qui sera toujours accordée. La configuration securityPolicy contient une nouvelle section de configuration fullTrustAssemblies enfant. La section FullTrustAssembliesSection est une collection standard qui prend en charge les opérations d'ajout, de suppression et d'effacement au cours desquelles vous pouvez spécifier une ou plusieurs identités d'assembly auxquelles la confiance totale sera accordée au moment de l'exécution. L'exemple suivant présente une section de configuration fullTrustAssemblies.

<system.web>

<securityPolicy>

<fullTrustAssemblies>

<add assemblyName="MyCustomAssembly"

version="1.0.0.0"

publicKey="a 320 hex character representation

of the public key blob used with a

signed assembly"

/>

</fullTrustAssemblies>

</securityPolicy>

</system.web>

Chaque entrée dans l'élément fullTrustAssemblies identifie un assembly par son nom de l'assembly et la version d'assembly, et par une chaîne de 320 caractères qui est la représentation hexadécimale des caractères de la moitié publique de la clé de signature.

Notes

Dans le futur, les nouveaux assemblys .NET Framework pourront peut-être utiliser des clés de signature 2048 bits.Si de nouveaux assemblys utilisant des clés de signature 2048 bits sont libérés, cela provoquera des chaînes hexadécimales longues de 576 caractères.

Aucun emplacement d'assembly n'est spécifié dans la définition. Il appartient à l'environnement d'hébergement individuel (tel qu'ASP.NET 4) de rechercher et de charger des assemblys. Si un assembly chargé correspond aux informations contenues dans l'un des éléments add dans fullTrustAssemblies, le niveau de confiance totale est accordé à l'assembly.

Vous devez utiliser fullTrustAssemblies pour les assemblys qui ne sont pas déployés dans le GAC, mais qui doivent toujours s'exécuter avec une confiance totale. Dans la mesure où les assemblys répertoriés dans fullTrustAssemblies peuvent être personnalisés à tout moment dans la hiérarchie de configuration (du fichier Web.config racine aux fichiers Web.config au niveau de l'application), il est plus simple et plus flexible d'utiliser ce paramètre pour accorder la confiance totale, plutôt que d'utiliser une condition d'appartenance et un groupe de codes dans un fichier de stratégie de confiance partielle. Vous pouvez personnaliser les listes fullTrustAssemblies pour les applications individuelles en spécifiant des informations distinctes pour les différentes applications. Cette opération peut être effectuée dans les fichiers Web.config au niveau de l'application ou dans le fichier Web.config racine, à l'aide des éléments location.

Le jeu d'assemblys de confiance totale est établi immédiatement au moment de la création d'un domaine d'application de confiance partielle. Par conséquent, si un fichier de stratégie de confiance partielle contient des informations qui produisent un jeu d'autorisations différent pour un assembly répertorié dans l'élément fullTrustAssemblies, les informations sont ignorées et la confiance totale est accordée à l'assembly.

Personnalisation d'autorisations par programmation

Vous pouvez également modifier par programmation l'association d'un jeu d'autorisations à un assembly en créant une implémentation personnalisée du type HostSecurityPolicyResolver d'ASP.NET 4. Au moment de l'exécution, ASP.NET 4 utilise sa propre implémentation du type CLR HostSecurityManager . Un objet HostSecurityManager est appelé par le CLR chaque fois qu'un assembly est chargé. L'une des fonctions de la propriété HostSecurityManager est de retourner un objet PermissionSet qui doit être associé à un assembly spécifié et pour un jeu de preuves. ASP.NET 4 vous permet de personnaliser ce processus en appelant un objet HostSecurityPolicyResolver personnalisé chaque fois que le CLR demande une décision de jeu d'autorisations à ASP.NET 4.

Vous pouvez configurer un objet HostSecurityPolicyResolver personnalisé à l'aide de l'attribut HostSecurityPolicyResolverType de l'élément trust. Si ASP.NET 4 détermine qu'un objet HostSecurityPolicyResolver personnalisé est configuré pour une application, il appelle la méthode ResolvePolicy du programme de résolution personnalisé chaque fois que le CLR demande une décision de jeu d'autorisations. Toutefois, contrairement à un objet HostSecurityManager, un objet HostSecurityPolicyResolver ne peut retourner qu'un jeu limité de décisions possibles à ASP.NET 4. La valeur de retour de la méthode ResolvePolicy doit faire partie de l'une des valeurs suivantes dans l'énumération HostSecurityPolicyResults :

• DefaultPolicy. Cela indique qu'ASP.NET 4 doit utiliser sa propre logique pour déterminer le jeu d'autorisations approprié pour l'assembly. Vous devez retourner DefaultPolicy pour les assemblys dans lesquels vous ne voulez pas que l'objet HostSecurityPolicyResolver prenne une décision à propos du jeu d'autorisations. Lorsque vous retournez DefaultPolicy, ASP.NET détermine le jeu d'autorisations d'un assembly selon les groupes de codes déclaratifs et les conditions d'appartenance définies dans le fichier de stratégie de confiance partielle pour le niveau de confiance ASP.NET actuel.

• FullTrust. La confiance totale doit être accordée à l'assembly.

• AppDomainTrust. Le jeu d'autorisations de confiance partielle associé au domaine d'application doit être accordé à l'assembly. Habituellement, cela signifie que les autorisations définies dans le jeu d'autorisations ASP.Net nommé seront accordées à l'assembly.

• None. Le jeu d'autorisations pour l'assembly correspondra à Nothing.

Étant donné que la classe HostSecurityPolicyResolver de base a une demande d'héritage pour une autorisation de sécurité non restreinte, et qu'un objet HostSecurityPolicyResolver personnalisé doit pouvoir être chargé sans qu'un autre objet HostSecurityPolicyResolver ait besoin d'établir la confiance totale, les implémentations concrètes d'une classe HostSecurityPolicyResolver doivent toujours être signées et déployées dans le GAC.

L'exemple suivant affiche un objet HostSecurityPolicyResolver personnalisé qui accorde la confiance totale à tous les assemblys chargés à partir d'un répertoire spécifique. Ce scénario peut s'adresser aux organisations qui ajoutent des assemblys compilés dans un emplacement spécifique sur disque (pas le GAC) et veulent que tous les fichiers à cet emplacement s'exécutent automatiquement avec la confiance totale. Pour que les applications ASP.NET puissent charger des assemblys depuis l'extérieur de la structure du répertoire d'une application Web, vous devez ajouter des redirections de liaison d'assembly explicites qui associent les identités d'assembly à différents emplacements de disque physiques.

[Visual Basic]

Public Class MyCustomResolver 
    Inherits HostSecurityPolicyResolver 
    Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
            As Evidence) As HostSecurityPolicyResults 
        Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)() 
        
        If (urlEvidence IsNot Nothing) AndAlso _
            (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then 
            Return HostSecurityPolicyResults.FullTrust 
        End If 
        
        ' Specify that ASP.NET should perform its own logic.
        Return HostSecurityPolicyResults.DefaultPolicy 
    End Function 
End Class

public class MyCustomResolver : HostSecurityPolicyResolver
{ 
  public override HostSecurityPolicyResults 
                              ResolvePolicy(Evidence evidence)
  {
            Url urlEvidence = evidence.GetHostEvidence<Url>();
            if ( (urlEvidence != null)  && 
                 (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
               )
                return HostSecurityPolicyResults.FullTrust;

            // Specify that ASP.NET should perform its own logic.
            return HostSecurityPolicyResults.DefaultPolicy;
  }
}

APTCA conditionnel

Dans les versions du .NET Framework antérieures à la version 4, de nombreux assemblys d'un niveau de confiance totale (notamment les assemblys ASP.NET) étaient marqués avec l'attribut AllowPartiallyTrustedCallersAttribute (APTCA). Cet attribut octroie aux appelants de confiance partielle l'accès à des membres et des types publics définis dans les assemblys marqués de cette façon. Dans .NET Framework 4, le CLR inclut une variation d'APTCA connue sous le nom d'APTCA conditionnel. (La notation abrégée pour APTCA conditionnel est C-APTCA.) L'APTCA conditionnel active des assemblys marqués avec l'attribut APTCA pour conserver les caractéristiques APTCA dans certains environnements hébergés uniquement. Par conséquent, l'APTCA conditionnel permet à ASP.NET 4 de contrôler plus facilement dans quels environnements d'hôte de confiance partielle les appelants de confiance partielle pourront appeler des API ASP.NET 4 publiques avec succès.

Fonctionnement de l'APTCA conditionnel

Les environnements d'hôte de confiance partielle et les assemblys d'un niveau de confiance totale participent au fonctionnement de l'APTCA conditionnel. Les environnements d'hôte de confiance partielle dans lesquels les jeux d'autorisations sont importants peuvent fournir au CLR une liste d'assemblys dont le paramètre APTCA doit toujours être respecté. Les assemblys d'un niveau de confiance totale dont les caractéristiques APTCA doivent être activées dans certains environnements d'hôte uniquement l'indiquent en utilisant la variation suivante de l'attribut APTCA de niveau assembly :

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

Au moment de l'exécution, lorsque le CLR est invité à charger un assembly marqué comme APTCA conditionnel, il vérifie la liste des assemblys APTCA conditionnel valides fournie par l'environnement d'hôte. Si l'assembly est dans la liste, le CLR traite tout le code exposé publiquement dans l'assembly comme si l'assembly avait été marqué avec l'attribut APTCA dans les versions antérieures du .NET Framework.

Si un assembly APTCA conditionnel ne se trouve pas dans la liste de l'environnement d'hôte des assemblys devant être traités comme APTCA, l'assembly est chargé, mais sans ses caractéristiques APTCA. La disponibilité réelle des API publiques pour le code utilisateur de confiance partielle dans ce type d'assembly varie selon que l'assembly est 100 % transparent de sécurité ou pas. Autrement dit, cela dépend si l'assembly est marqué avec un attribut SecurityTransparentAttribute de niveau assembly. (La transparence de sécurité dans ASP.NET 4 est décrite dans une section ultérieure de cette rubrique.)

En résumé, les API publiques dans ASP.NET 4 peuvent se comporter de l'une des façons suivantes :

• Pour la plupart des assemblys ASP.NET, toutes les API publiques deviennent indisponibles pour les appelants de confiance partielle. En effet, cela empêche la majorité des API publiques dans ASP.NET 4 d'être utilisées dans des environnements de confiance partielle autres que les applications Web.

• Quelques assemblys ASP.NET marqués comme 100 % transparents de sécurité peuvent encore être appelés par des appelants de confiance partielle. Toutefois, si les chemins de code dans ces assemblys atteignent finalement le reste du code base d'ASP.NET, les appels échouent. Il en résulte le même comportement que dans les versions antérieures d'ASP.NET, sauf que les appels aux API dans les assemblys ASP.NET 4 vont plus loin avant d'échouer.

  Notez ce qui suit à propos des assemblys marqués comme transparents de sécurité :

  • Seuls deux assemblys ASP.NET sont marqués comme transparents de sécurité au niveau de l'assembly : System.Web.DynamicData.dll et System.Web.RegularExpressions.dll.

  • System.Web.Routing.dll n'est pas considéré comme 100 % transparent de sécurité dans ASP.NET 4, car tous les types définis dans cet assembly dans les versions antérieures d'ASP.NET ont été déplacés vers System.Web.dll. En effet, dans ASP.NET 4, System.Web.Routing.dll est un assembly de métadonnées uniquement.

Dans ASP.NET 4, la variation de l'attribut APTCA conditionnel est incluse dans les assemblys suivants :

• System.Web.dll

• System.Web.Extensions.dll

• System.Web.DynamicData.dll

• System.Web.DataVisualization.dll

• System.ComponentModel.DataAnnotations.dll

• System.Web.ApplicationServices.dll. Cet assembly est nouveau dans ASP.NET 4.

• System.Web.Abstractions.dll. Les types dans cet assembly ont été déplacés vers System.Web.dll pour ASP.NET 4.

• System.Web.Routing.dll. Les types dans cet assembly ont été déplacés vers System.Web.dll pour ASP.NET 4.

APTCA conditionnel et attributs d'autorisation d'hébergement d'ASP.NET

L'APTCA conditionnel a rendu pratique la suppression de l'attribut AspNetHostingPermission de 99 % des API publiques dans ASP.NET 4. L'attribut AspNetHostingPermission est encore utilisé dans ASP.NET 4, mais seulement aux emplacements où l'intention des autorisations a du sens. Partout ailleurs, les deux utilisations suivantes de l'attribut AspNetHostingPermission n'existent plus :

<AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>

[AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]

Ces définitions d'autorisations étaient utilisées dans les versions antérieures d'ASP.NET pour empêcher que les assemblys ASP.NET soient chargés dans des environnements de confiance partielle non Web. Le plus grand environnement concerné regroupait les applications managées et les contrôles managés de confiance partielle qui étaient chargés dans des navigateurs comme Microsoft Internet Explorer et Mozilla Firefox. Lorsque l'APTCA conditionnel est utilisé, les mêmes protections sont appliquées car les applications ClickOnce et les contrôles managés basés sur le navigateur ne définissent pas d'assemblys d'APTCA conditionnel pour le traitement comme APTCA complet.

Personnalisation de la liste ASP.NET 4 d'APTCA conditionnel

Comme mentionné précédemment, les environnements d'hôte peuvent fournir au CLR une liste d'assemblys d'APTCA conditionnel dont les caractéristiques APTCA doivent être respectées. ASP.NET 4 fournit au CLR une liste codée de manière irréversible qui contient tous les assemblys d'ASP.NET 4. Si ASP.NET 4 ne le fait pas, les applications Web échouent immédiatement lorsque la première ligne de code interne ASP.NET est exécutée dans un domaine d'application de confiance partielle.

Dans .NET Framework 4, l'APTCA conditionnel est un nouveau concept CAS qui n'a pas encore été implémenté dans d'autres parties du .NET Framework. Par conséquent, il est probable que les versions ultérieures du .NET Framework incluront plus d'assemblys d'APTCA conditionnel. De plus, à mesure que vous vous familiarisez avec l'APTCA conditionnel et l'utilisez pour vos propres assemblys de confiance totale, le jeu d'assemblys d'APTCA conditionnel grossit. Comme il est impossible pour ASP.NET 4 de connaître à l'avance tous les assemblys d'APTCA conditionnel possibles, ASP.NET 4 inclut une section de configuration où les assemblys d'APTCA conditionnel peuvent être ajoutés.

La section securityPolicy existante a une section de configuration enfant nommée partialTrustVisibleAssemblies. C'est une collection standard qui prend en charge les opérations d'ajout, de suppression et d'effacement, au cours desquelles vous pouvez spécifier une ou plusieurs identités d'assembly qui doivent être traitées comme APTCA (si elles sont également marquées pour l'APTCA conditionnel). L'exemple suivant présente une section partialTrustVisibleAssemblies.

<system.web>
  <securityPolicy>
    <partialTrustVisibleAssemblies>

      <add assemblyName="MyCustomAssembly"
           publicKey="a 320 hex character representation 
                      of the public key blob used with a 
                      signed assembly"
      />

    </partialTrustVisibleAssemblies>
  </securityPolicy>
</system.web>

Chaque entrée dans la section partialTrustVisibleAssemblies identifie un assembly par nom de l'assembly. Chaque entrée est également identifiée par une chaîne de 320 caractères (par exemple, 0x03FA4D...) qui est la représentation hexadécimale des caractères de la moitié publique de la clé de signature utilisée sur l'assembly auquel est attribué l'APTCA conditionnel. Vous n'avez pas à spécifier un attribut de version. Seul le nom de l'assembly et le jeton de la clé publique sont requis par le CLR.

Lorsque vous activez un assembly d'APTCA conditionnel vous devez, pour des raisons de performances, activer également la fermeture transitive des assemblys d'APTCA conditionnel. Par exemple, si l'assembly d'ATPCA conditionnel A dépend de l'assembly d'APTCA B, et si l'assembly d'APTCA B dépend à son tour de l'assembly d'ATPCA conditionnel C, lorsque vous activez l'ATPCA conditionnel pour A, vous devez également l'activer pour C. Sinon, les performance de votre application risquent de s'en trouver affectées. Par exemple, le partage de code et les images NGen seront désactivés si la fermeture complète d'ATPCA conditionnel n'est pas activée.

Impact de l'APTCA conditionnel sur les applications de confiance partielle non Web

Dans les versions d'ASP.NET antérieures à ASP.NET 4, certains types et espaces de noms n'étaient pas marqués avec l'attribut AspNetHostingPermission. Cela permettait à ces types d'être appelés à partir d'environnements de confiance partielle non ASP.NET tels que les applications ClickOnce. Les types et les espaces de noms qui pouvaient être appelés de cette façon étaient les suivants :

• Types dans l'espace de noms System.Web.ClientServices.

• Types dans l'espace de noms System.Web.ClientServices.Providers.

• Type HttpUtility.

Les types System.Web.ClientServices ne sont pas utilisables dans les environnements de confiance partielle de .NET Framework 4 tels que ClickOnce. Dans la mesure où l'assembly contenant (System.Web.Extensions.dll) est un assembly ASP.NET 4 marqué pour l'APTCA conditionnel et où ClickOnce n'autorise pas APTCA pour les assemblys d'APTCA conditionnel, aucun des types de services clients ne peut être appelé à partir d'applications ClickOnce de confiance partielle.

Cette erreur peut se produire pour ce comportement : En premier lieu, .NET Framework 4 a été fractionné dans un client et dans une référence étendue, et l'hypothèse est que de nombreuses applications ClickOnce cibleront la référence cliente. L'effort nécessaire pour refactoriser les types de services clients d'ASP.NET dans la référence cliente est considérable.

Ensuite, il est difficile de déterminer comment refactoriser les types clients tout en maintenant les limites d'APTCA conditionnel obligatoires. Par conséquent, dans .NET Framework 4, les types de services clients sont uniquement disponibles pour les environnements de confiance totale non ASP.NET, notamment les applications ClickOnce configurées pour s'exécuter avec la confiance totale à l'aide de la référence .NET Framework 4 étendue.

Pour le type HttpUtility, l'effet de l'APTCA conditionnel dépend des méthodes utilisées, comme indiqué dans les scénarios suivants :

• Le code de confiance partielle appelait la méthode HtmlEncode ou HtmlDecode de la classe WebUtility. Le type WebUtility contient les implémentations d'encodage et de décodage HTML ASP.NET, mais celles-ci ont été refactorisées et déplacées vers l'espace de noms System.Net (dans System.dll). Étant donné que System.dll est disponible dans tous les environnements d'hôte de confiance partielle, il n'y a aucun problème avec les méthodes du type WebUtility accédant aux applications de confiance partielle non ASP.NET.

• Le code de confiance partielle appelait l'une des autres méthodes de la classe WebUtility. Dans ce cas, le même problème que celui décrit précédemment pour les types de services clients se produit. Autrement dit, WebUtility est uniquement disponible pour les appelants de confiance totale non ASP.NET dans .NET Framework 4.

Transparence de sécurité dans ASP.NET 4

La transparence de sécurité vous permet d'indiquer au CLR si un bloc de code effectuera une opération de sécurité sensible. Le code transparent ne peut jamais déclarer des autorisations, satisfaire une demande de liaison, contenir du code non vérifiable, appeler dans le code natif ou appeler du code critique de sécurité. Cela est vrai, que le code transparent soit d'un niveau de confiance totale (par exemple dans le GAC) ou partielle.

La transparence de sécurité est une fonctionnalité puissante pour les fonctionnalités .NET Framework comme ASP.NET. Elle permet à ASP.NET d'indiquer au CLR que des parties de code ASP.NET ne déclareront jamais des autorisations, et que le code n'implémentera ou n'exécutera jamais des opérations de sécurité sensibles telles que les appels PInvoke en code natif. Le code .NET Framework peut ainsi réduire substantiellement l'exposition aux risques de sécurité d'un grand nombre d'API publiques et internes, même si le code .NET Framework se trouve dans le GAC d'un niveau de confiance totale.

La transparence de sécurité peut s'appliquer à un assembly entier ou à un sous-ensemble du code dans l'assembly. Bien que le marquage d'un assembly entier pour la transparence de sécurité soit la solution idéale, du code dans le code .NET Framework a une spécification légitime pour effectuer des tâches de sécurité sensibles. Les assemblys qui contiennent du code 100 % transparent de sécurité sont marqués à l'aide d'un attribut SecurityTransparentAttribute au niveau de l'assembly.

Les assemblys qui contiennent un mélange de code transparent et non transparent n'ont pas d'attribut de transparence au niveau de l'assembly. À la place, les classes individuelles dans l'assembly peuvent être marquées à l'aide de l'attribut SecuritySafeCriticalAttributel ou de l'attribut SecurityCriticalAttribute.

Le comportement des classes non attribuées est complexe. Toutefois, en termes simples, les types non attribués dans les assemblys ASP.NET 4 qui ont adopté le nouveau modèle de transparence sont considérés comme transparents de sécurité. Les types dans les assemblys ASP.NET 4 qui ne sont pas attribués et n'ont pas adopté le nouveau modèle de transparence sont considérés comme critiques sécurisés (security-safe-critical).

Transparence de sécurité en pratique et RuleSets de sécurité

Étant donné que la base de code ASP.NET 4 se trouve presque intégralement dans System.Web.dll, il n'était pas pratique de convertir tout le code ASP.NET 4 dans le nouveau modèle de transparence. À la place, le code ASP.NET 4 peut être partitionné dans les catégories suivantes :

• Le code qui n'a pas adopté le nouveau modèle de transparence, notamment le code dans les assemblys suivants :

  • System.Web.dll

  • System.Web.ApplicationServices.dll

  • System.Web.Mobile.dll. Les types dans cet assembly ont été marqués comme obsolètes dans ASP.NET 4. Bien que l'assembly existe encore, on suppose qu'avec le temps, vous cesserez d'utiliser les types dans cet assembly.

• Le code qui utilisait le nouveau modèle de transparence, notamment le code dans les assemblys suivants :

  • System.Web.Extensions.dll

  • System.Web.DynamicData.dll (100 % transparent de sécurité)

  • System.Web.RegularExpressions.dll (100 % transparent de sécurité)

  • System.ComponentModel.DataAnnotations.dll

  • System.Web.DataVisualization.dll

• Les assemblys qui sont uniquement des métadonnées et dont les types ont été déplacés vers un assembly ASP.NET différent, notamment les assemblys suivants :

  • System.Web.Abstractions.dll. Les types qui se trouvaient dans cet assembly dans les versions antérieures d'ASP.NET ont été déplacés vers System.Web.dll. Par conséquent, Sytem.Web.Abstractions.dll est un assembly de métadonnées uniquement dans ASP.NET 4.

  • System.Web.Routing.dll. Les types qui se trouvaient dans cet assembly dans les versions antérieures d'ASP.NET ont été déplacés vers System.Web.dll. Par conséquent, System.Web.Routing.dll est un assembly de métadonnées uniquement dans ASP.NET 4.

Dans .NET Framework 4, le CLR a introduit un nouveau concept appelé ensemble de règles de sécurité. Il existe deux niveaux de configurations SecurityRuleSet : le niveau un et le niveau deux. La configuration SecurityRuleSet pour tous les types est spécifiée à l'aide de l'attribut SecurityRulesAttribute de niveau assembly. Les assemblys ASP.NET 4 qui ont adopté le nouveau modèle de transparence sont marqués à l'aide de l'attribut de niveau assembly suivant :

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)

Les assemblys ASP.NET 4 qui utilisent le modèle de transparence de .NET Framework 2.0 (pas de transparence pour ASP.NET, car ASP.NET avant ASP.NET 4 n'a jamais utilisé les concepts de transparence) sont marqués à l'aide de l'attribut de niveau assembly suivant :

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)

Pour les assemblys ASP.NET qui ont adopté le nouveau modèle de transparence (et les types publics qui sont dans les assemblys), la plupart du code est considéré comme transparent de sécurité. Une petite de quantité de code dans ces assemblys exécute des opérations de sécurité sensibles, et ce code est marqué comme critique sécurisé ou code critique.

Pour les assemblys ASP.NET qui n'ont pas adopté le nouveau modèle de transparence (en laissant de côté les assemblys obsolètes ou redirigés par type), toutes les API publiques peuvent être appelées à partir du code utilisateur de confiance partielle et peuvent effectuer en interne des opérations de sécurité sensibles. La combinaison de l'accès ouvert pour les appelants de confiance partielle et de la possibilité d'exécution d'opérations de sécurité sensibles signifie que le code ASP.NET 4 plus ancien requiert un niveau de surveillance plus élevé. Toutefois, comme la majorité des nouvelles fonctionnalités ASP.NET sont implémentées dans de nouveaux assemblys tels que System.Web.Extensions.dll et System.Web.DynamicData.dll, ou dans des versions séparées comme ASP.NET MVC, la plupart du nouveau code ASP.NET est transparent de sécurité et donc, par défaut, plus sécurisé que l'ancien code.

Par défaut, le CLR considère que les API publiques de tous les assemblys ASP.NET 4 marquées comme SecurityRuleSet.Level1 sont critiques sécurisées (ce qui équivaut au marquage avec l'attribut SecuritySafeCriticalAttribute) tant que l'environnement d'hébergement respecte l'attribut APTCA. Si l'attribut APTCA n'est pas respecté, le CLR déclenche une demande de liaison en confiance totale, qui échoue lorsque la pile contient du code utilisateur de confiance partielle. En d'autres termes, lorsque l'attribut APTCA n'est pas respecté pour un assembly ASP.NET marqué comme SecurityRuleSet.Level1, vous constatez le même comportement que dans les versions précédentes du .NET Framework, lorsque le code de confiance partielle tentait d'appeler un assembly de confiance totale qui n'était pas marqué avec l'attribut APTCA.

Par défaut, le CLR considère que les API publiques de tous les assemblys ASP.NET 4 marquées comme SecurityRuleSet.Level2 sont transparentes de sécurité (ce qui équivaut à l'attribution avec SecurityTransparentAttribute) tant que l'environnement d'hébergement respecte l'attribut APTCA. Sinon, le comportement suivant est défini :

• Si l'attribut APTCA n'est pas respecté et si un assembly marqué comme Level2 n'est pas 100 % transparent de sécurité, le CLR considère la surface publique comme critique de sécurité. Par conséquent, tous les appelants de confiance partielle qui essaient d'utiliser la surface publique échoueront probablement avec une exception MethodAccessException, TypeAccessException ou FieldAccessException.

• Si l'attribut APTCA n'est pas respecté et si un assembly marqué comme Level2 est 100 % transparent de sécurité, les appelants de confiance partielle pourront appeler avec succès les API publiques dans cet assembly. En pratique, cela signifie qu'une exception SecurityException se produit ultérieurement dans le chemin d'appel lorsque le code dans l'assembly 100 % transparent de sécurité appelle finalement un assembly ASP.NET de niveau 1 ou un assembly ASP.NET de niveau 2 qui n'est pas 100 % transparent de sécurité.

Transparence et compilation ASP.NET

La sortie créée par le système de compilation ASP.NET est également affectée par l'adoption, par ASP.NET 4, du nouveau modèle CAS et du nouveau modèle de transparence de sécurité. Cela inclut des éléments comme les assemblys de page, les assemblys précompilés et les résultats compilés du répertoire App_Code. Le comportement du système de compilation varie en fonction du paramètre de l'attribut LegacyCasModel de l'élément trust.

Le tableau suivant décrit comment les objets compilés dynamiquement sont marqués dans le modèle CAS hérité et le nouveau modèle CAS.

Paramètre de l'attribut legacyCasModel	Niveau de confiance du site Web	Attributs appliqués aux assemblys compilés
False (nouveau modèle CAS)	Confiance totale	SecurityRules(SecurityRuleSet.Level2)
	Niveau de confiance élevé ou inférieur	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True (ancien modèle CAS)	Confiance totale	SecurityRules(SecurityRuleSet.Level1)
	Niveau de confiance élevé ou inférieur	SecurityRules(SecurityRuleSet.Level1)

Étant donné que le comportement du système de compilation ASP.NET 4 varie selon les paramètres de l'attribut LegacyCasModel de l'élément trust, il peut exister des restrictions sur la manière dont vous partagez le code compilé dans les différentes applications ASP.NET 4 de confiance partielle. En général, vous ne voyez aucun changement au niveau du comportement des applications. Toutefois, dans certains scénarios, les artefacts compilés créés à partir d'une application de confiance partielle dont l'attribut LegacyCasModel a la valeur false (autrement dit, qui utilise le nouveau modèle CAS) ne fonctionnent pas comme prévu lorsqu'ils sont utilisés avec d'autres applications. Par conséquent, pour certains scénarios (par exemple, une bibliothèque partagée de contrôles .ascx compilés qui sont signés, attribués avec ATPCA et déployés dans le GAC), vous devez peut-être appliquer explicitement les attributs critiques sécurisés et critiques à du code lorsque la bibliothèque est marquée avec Level2.

Voir aussi

Autres ressources

Sécurité des applications ASP.NET dans les environnements hébergés