Sécurisation des composants WebPart dans SharePoint Foundation

Dernière modification : mardi 2 novembre 2010

S’applique à : SharePoint Foundation 2010

Dans cet article
Sécurité d'accès du code
Paramètres de sécurité intégrés
Création d'une stratégie de sécurité d'accès du code

Dans Microsoft SharePoint Foundation, les composants WebPart sont un outil puissant, qui permet aux utilisateurs d’interagir avec d’autres systèmes. SharePoint Foundation 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.

Les composants WebPart peuvent également être créés dans une solution en bac à sable (sandbox). Par défaut, une solution en bac à sable (sandbox) dispose d’un accès restreint au système sous-jacent. Cela renforce la sécurité et la surveillance du composant WebPart. Pour plus d’informations sur les solutions en bac à sable, voir Solutions en mode bac à sable.

Sécurité d'accès du code

La sécurité d’accès du code (CAS) est une stratégie 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. SharePoint Foundation 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, SharePoint Foundation 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. Vous pouvez créer une stratégie CAS personnalisée pour votre composant WebPart ou 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 de composants WebPart dans SharePoint Foundation.

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

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

• WSS_UserCode

• WSS_Minimal

• WSS_Medium

Ces niveaux de confiance prolongent les niveaux de confiance ASP.NET à utiliser avec SharePoint Foundation. Les niveaux de confiance sont définis dans des fichiers de stratégie, qui se trouvent dans le système de fichiers de chaque serveur Web.

Important   Par défaut, les fichiers de stratégie SharePoint Foundation intégrés dans SharePoint Foundation, nommés wss_usercode.config, wss_minimaltrust.config et wss_mediumtrust.config se trouvent dans le répertoire %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG.

Par défaut, SharePoint Foundation 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 SharePoint Foundation 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_Medium, WSS_Minimal et WSS_UserCode dans l’environnement ASP.NET 2.0.

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

SharePoint Foundation permet de déployer un fichier de stratégie CAS avec une solution. Il est recommandé d’utiliser les autorisations relatives aux solutions en mode bac à sable (sandbox), et qui sont listées dans le fichier wss_usercode.config ; toutefois, vous pouvez également créer des autorisations personnalisées pour vos composants WebPart et utiliser SharePoint Foundation pour 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 SharePoint Foundation.

<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 (Solution).

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 -CASPolicies avec SharePoint Management Shell. La commande est la suivante :
Install-SPSolution –Identity <insert name> -CASPolicies <true/false>

Voir aussi

Autres ressources

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