Sécurisation des composants WebPart dans Windows SharePoint Services

Windows SharePoint Services 3

Dans Windows SharePoint Services, les composants WebPart sont un outil puissant, qui permet aux utilisateurs d'interagir avec d'autres systèmes. Windows SharePoint Services comporte des paramètres de sécurité intégrés qui restreignent l'accès d'un composant WebPart aux systèmes sous-jacents. Un développeur peut créer des fichiers personnalisés de stratégie de sécurité pour accorder à un composant WebPart un accès moins limité au système sous-jacent. Cette rubrique présente les paramètres intégrés et fournit une vue d'ensemble d'une stratégie de sécurité d'accès du code (CAS, Code Access Security) ; elle explique également comment inclure une telle stratégie personnalisée dans une solution Windows SharePoint Services.

Sécurité d'accès du code

La sécurité d'accès du code est un modèle de contraintes concernant des ressources, qui limite l'accès d'un assembly aux ressources et aux opérations protégées du système. Windows SharePoint Services comporte des stratégies de sécurité intégrées qui ont été créées d'après les stratégies de sécurité intégrées d'ASP.NET. Par défaut, Windows SharePoint Services utilise un ensemble limité d'autorisations, afin de protéger le serveur et l'infrastructure sous-jacente contre tout code malveillant.

Si votre composant WebPart nécessite un accès plus étendu que celui fourni par les paramètres de base, il existe plusieurs façons d'augmenter les autorisations de votre composant WebPart, mais une seule est recommandée. La méthode recommandée consiste à créer une stratégie personnalisée de sécurité d'accès du code pour votre composant WebPart. La seconde méthode consiste à augmenter le niveau de confiance global de la batterie de serveurs dans le fichier web.config. Cela présente un risque au niveau de la sécurité et n'est pas recommandé. Pour plus d'informations sur le déploiement, voir Déploiement des composants WebPart dans Windows SharePoint Services.

Paramètres de sécurité intégrés

Windows SharePoint Services est une application de confiance partielle par défaut. Windows SharePoint Services peut utiliser les niveaux de confiance intégrés d'ASP.NET, mais le programme définit deux niveaux de confiance qui lui sont propres :

  • WSS_Minimal

  • WSS_Medium

Ces niveaux de confiance prolongent les niveaux de confiance Minimal et Medium d'ASP.NET à utiliser avec Windows SharePoint Services. Les niveaux de confiance sont définis dans des fichiers de stratégie, dans le système de fichiers de chaque serveur Web.

Important   Par défaut, les fichiers de stratégie Windows SharePoint Services intégrés, appelés wss_minimaltrust.config et wss_mediumtrust.config, se trouvent dans %SYSTEMDRIVE%\Program Files\Common Files\Microsoft Shared\web server extensions\12\config.

Par défaut, Windows SharePoint Services applique le niveau de confiance WSS_Minimal pour le serveur virtuel. Ce niveau de confiance accorde toutes les autorisations du niveau de confiance ASP.NET Minimal, ainsi que les connexions des composants WebPart. La stratégie WSS_Minimal empêche le composant WebPart d'accéder à de nombreuses ressources pour des opérations avancées, dont celles qui portent sur le modèle objet et les fichiers.

Le niveau de confiance WSS_Medium accorde un accès plus important à l'environnement. De plus, WSS_Medium permet d'accéder au modèle objet Windows SharePoint Services et aux opérations sur les fichiers, dont la lecture, l'écriture, l'ajout et la découverte de chemins. Ce niveau de confiance permet également d'accéder aux variables d'environnement.

Le tableau suivant décrit les autorisations spécifiques accordées avec les fichiers de stratégie WSS_Minimal et WSS_Medium dans l'environnement ASP.NET 2.0.

Autorisation WSS_Medium Niveau de confiance WSS_Minimal Niveau de confiance

AspNetHostingPermission

Medium

Minimal

DirectoryServicesPermission

Aucun

Aucun

DnsPermission

Illimité

Aucun

EnvironmentPermission

Lecture : TEMP, TMP, OS, USERNAME, COMPUTERNAME

Aucun

EventLogPermission

Aucun

Aucun

FileIOPermission

Lecture, Écriture, Ajout, Découverte du chemin : répertoire de l'application

Aucun

IsolatedStoragePermission

AssemblyIsolationByUser, Unrestricted UserQuota

Aucun

MessageQueuePermission

Aucun

Aucun

OleDBPermission

Aucun

Aucun

Compteurs de performances

Aucun

Aucun

PrintingPermission

Impression par défaut

Aucun

ReflectionPermission

Aucun

Aucun

RegistryPermission

Aucun

Aucun

SecurityPermission

Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration

Exécution

ServiceControllerPermission

Aucun

Aucun

SharePointPermission

(Microsoft.SharePoint.Security)

ObjectModel = true

Aucun

SocketPermission

Aucun

Aucun

SqlClientPermission

AllowBlankPassword=false

Aucun

WebPermission

Connexion à l'hôte d'origine (s'il est configuré)

Aucun

Remarque Remarque :

Pour plus d'informations sur la sécurité d'accès du code, voir Utilisation de la sécurité d'accès au code avec ASP.NET et Conseils de sécurité pour .NET Framework 2.0 (en anglais) .

Création d'une stratégie de sécurité d'accès du code

Windows SharePoint Services 3.0 permet désormais de déployer un fichier de stratégie CAS avec une solution. Cela facilite la création d'autorisations personnalisées pour vos composants WebPart et permet à Windows SharePoint Services de gérer le déploiement.

L'exemple de code suivant montre la structure de base d'un fichier de stratégie de sécurité d'accès du code dans un package de solution Windows SharePoint Services.

<CodeAccessSecurity>
   <PolicyItem>
     <PermissionSet class="NamedPermissionSet" version="1"
      Description="Permission set for custom test WebParts">
        <IPermission class="AspNetHostingPermission" version="1" 
        Level="Minimal" />
        <IPermission class="SecurityPermission" version="1" 
        Flags="Execution" />
        <IPermission 
        class="Microsoft.SharePoint.Security.SharePointPermission, 
        Microsoft.SharePoint.Security, version=11.0.0.0, 
        Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" 
        ObjectModel="True" />
        <IPermission class="System.Net.WebPermission, System, 
        version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1">
          <ConnectAccess>
            <URI uri="https?://.*" />
          </ConnectAccess>
        </IPermission>
        <IPermission 
        class="System.Security.Permissions.SecurityPermission, 
        mscorlib, version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1" 
        Flags="ControlThread, UnmanagedCode" />
        <IPermission 
        class="System.Security.Permissions.EnvironmentPermission, 
        mscorlib, version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1" Read="UserName" />
     </PermissionSet>
     <Assemblies>
       <Assembly PublicKeyBlob=PublicKeyBlob />
     </Assemblies>
   </PolicyItem>
</CodeAccessSecurity>

La liste ci-dessous inclut certaines instructions générales qui s'appliquent lorsque vous utilisez une section <CodeAccessSecurity> dans votre manifeste de solution.

  • Il ne peut y avoir qu'une seule section <CodeAccessSecurity> par manifeste de solution.

  • Il peut y avoir plusieurs nœuds <PolicyItem>.

  • Chaque nœud <PolicyItem> ne peut contenir qu'un seul nœud <PermissionSet>.

  • Chaque nœud <PolicyItem> ne peut contenir qu'un seul nœud <Assemblies>.

  • Chaque nœud <PermissionSet> peut contenir plusieurs nœuds <IPermission>.

  • Il peut y avoir plusieurs nœuds <Assembly> sous le nœud <Assemblies>.

Pour plus d'informations sur le schéma de la zone <CodeAccessSecurity>, voir CodeAccessSecurity, élément (en anglais).

Lorsque vous déployez votre assembly à l'aide d'une stratégie de sécurité d'accès du code personnalisée, vous devez utiliser l'option -allowCasPolicies avec l'utilitaire stsadm.exe. La commande est la suivante : stsadm -o deploySolution -name <insert name> -allowCasPolicies

Pour plus d'informations sur l'utilisation de stsadm pour déployer une solution, voir Outil de ligne de commande Stsadm .

Voir aussi

Afficher: