The Mit's Blog

SharePoint 2010 & CAS : le GAC n’est pas l’unique solution de déploiement de vos composants

Un sujet qui revient souvent dans le monde SharePoint mais bizarrement moins depuis la version 14 alors que très à la mode sous 2003 et 2007.

Le Code Access Security : CAS et la problématique des stratégie de contrainte ..

Référence MSDN (très bonne d’ailleurs)
http://msdn.microsoft.com/en-us/library/cc768613.aspx ou http://msdn.microsoft.com/fr-fr/library/cc768613.aspx

Introduction : “Comment gérer le modèle d’exécution de vos composants sous SharePoint 2010 ?“

Il est vrai que sous SP14, il existe 3 modèles

• Full trust : déploiement GAC ou Farm Global
  • avantage : pleine puissance
  • inconvénient : disponible de maniére transverse dans toutes les Web Apps de votre ferme
    
• Bin/CAS : déploiement en Bin de vos sites IIS SharePoint
  • avantage : des droits dépendants de vos CAS et composants disponibles uniquement sur les Web App ciblés
  • inconvénient : rédiger les dites CAS
    
• SandBox : déploiement dans la gallerie de solution de votre Site Collection
  • avantage : isolation assuré par le déploiement par collection avec CAS spéciale
  • inconvénient : aucune ouverture sauf si utilisation des sandbox proxy

Rappel sur les modèles d’exécution:

• http://leedale.wordpress.com/2011/06/06/execution-models-for-sharepoint-2010-part-1-full-trust/
• http://leedale.wordpress.com/2011/06/06/execution-models-for-sharepoint-2010-part-2-%e2%80%93-bincas/
• http://leedale.wordpress.com/2011/06/10/execution-models-for-sharepoint-2010-part-3-%e2%80%93-sandboxed-solutions/

Certes, Microsoft encourage fortement le développement Sandbox, mais bien souvent, sur des problématiques plus complexes (avec des WS, des appels cross collections, …) le modèle Farm est nécessaire, et je ne vous parle pas de certaines problématiques de maintenance de sandbox

Et la ce pose la question du déploiement Web App ou Global, pardon, ferme ou bin 
>>> bien souvent, la plupart des développeurs utilise le développement global car simple et TRES efficace

Le soucis, vos composants deviennent transverses à la ferme et si vous hébergez plusieurs intranets SharePoint, vous vous retrouvez avec une maelstrom de feature toute mélangé (genre l’intranet, le collaboratif, la gestion de projet les blogs) alors que les composants sont fonctionnellement différents …

D’un point de vue Gouvernance (hello Christian), clairement, il faut mieux travailler en silo et isoler les composants au plus proche de leur application. Donc travailler avec des solutions avec CAS en BIN

Et d’un point de vue sécurité …  vous évitez aussi d’avoir des dll en GAC qui ont … tout pouvoirs soit dit en passant …

Mais comment déployer en Bin ?

Les développeurs SP12 connaissent bien la méthode et surtout WSPBuilder mais sous VS 2010 c’est différent. Il suffit de modifier les propriétés de votre projet

Mais par contre, vous devez au préalable, préparez les références de CAS … C’est la que le problème devient épineux

je vous renvoie dans un premier temps sur le MSDN pour que vous puissiez mieux comprendre, découvrir, approfondir le concept qui est pur .Net et non SharePoint, d’ailleurs

http://msdn.microsoft.com/en-us/library/cc768613.aspx

Cet ancien article du MSDN sur une WebPart WSS 3 de feu Patrick Tisseghem est d’ailleurs toujours une référence, surtout le dernier chapitre sur Code Access Security and Web Part Solutions

• http://msdn.microsoft.com/en-us/library/bb530301(v=office.12).aspx#WSSDevToolsTechs_P2_CodeAccessSecurityandWebPartSolutions
  • http://archive.msdn.microsoft.com/MsdnSpCasPaper

En pratique, vous devez recenser les permissions minimales pour l’exécution de votre code sous ce format

<CodeAccessSecurity>
  <PolicyItem>
    <PermissionSet class="NamedPermissionSet" version="1">
      <IPermission class="SecurityPermission" version="1" Flags="Execution" />
      <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
      <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" />
    </PermissionSet>
    <Assemblies>
      <Assembly Name="$SharePoint.Project.AssemblyName$" 
                Version="$SharePoint.Project.AssemblyVersion$" 
                PublicKeyBlob="$SharePoint.Project.AssemblyPublicKeyBlob$"/>
    </Assemblies>
  </PolicyItem>
</CodeAccessSecurity>

Par défaut SharePoint fonctionne avec la policy WSS_minimal qui ne vous laisse même pas utiliser le modèle objet, c’est dire … Il faut donc préciser les CAS (ou modifier le Trust du Web.config de SharePoint mais je ne préfère pas vous parler de cette option, pas vraiment à conseiller sous 2010)

Si vous oubliez, SharePoint vous le rappellera sans politesse

…

Mais bien souvent, vos WebParts et autres développement se ressemblent souvent, vous pouvez donc partir du modèle précédent et le réutiliser à travers vos différents projets. Et surtout l’adaptez à vos besoins

Merci à Waldek pour son template de base très utile

Liens pratiques :

• http://blog.mastykarz.nl/code-access-security-policy-template-visual-studio-2010-sharepoint-developer-tools/
• http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2009/11/20/deploying-a-web-part-with-code-access-security-in-visual-studio-2010-sp2010.aspx
• http://alexanderst.wordpress.com/2011/03/03/adding-cas-permissions-to-wsp-in-sharepoint-2010/
• http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2007/07/05/how-to-configure-code-access-security-for-a-web-part.aspx

Ainsi, dans Visual Studio, la démarche n’est pas si compliqué

1. Modifier les propriétés de déploiement
   
   
   
2. Ajoutez le CAS dans le designer de package
   
   
   
3. Rajouter le tag [assembly: AllowPartiallyTrustedCallers()] dans AssemblyInfo.cs

Et voila, enfin presque, il existe un bug bien embêtant qui bloque le déploiement depuis VS2010, à priori, un bug est passé à travers la matrice de test de la RTM … mais la KB donne un fix très efficace :

http://social.msdn.microsoft.com/Forums/en-US/vssharepointdevelopment/thread/eaa2077a-b86b-42c0-9dfd-491c37a1b35e
>>>  http://support.microsoft.com/kb/2022463

Il reste cependant une dernière question : Mais comment identifier les bonnes IPermissions de votre CAS ?

C’est effectivement le point le plus compliqué car il peut dépendre de votre connaissance pleine du fonctionnement de .Net …

Et si vous en oubliez une, la sanction est sans appel

Vous remarquerez que l’erreur vous donne de bonne indications sur la permission manquante d’ailleurs

A noter que vous pouvez les retrouver aussi via une petite introspection via Reflector

• http://daniellarson.wordpress.com/2008/05/27/troubleshooting-sharepoint-cas-code-access-security/

Mais vous pouvez aussi le chercher via une simple gestion d’erreur et votre débuggeur VS2010. Il vous suffit de traquer une exception de type SecurityException et de cherchez ex.m_demanded

Waldek (encore lui) a découvert cette astuce

• http://blog.mastykarz.nl/working-easier-custom-cas-policies/
• http://www.stuartroberts.net/index.php/2012/04/03/get-cas-ipermission-exception/

Au final, rien de bien compliqué, non ?

Mais bon courage quand même

Avant de partir, je vous laisse avec un petit dilemme

"Untrusted solutions – Deploying custom code in bin folders can cause slow server performance. Every time a page containing untrusted code is requested, SharePoint Server 2010 must perform security checks before the page can be loaded.Unless there is a specific reason to deploy untrusted code, you should install custom assemblies in the GAC to avoid unnecessary security checking."

http://technet.microsoft.com/en-us/library/ff758647.aspx 

Mais la sécurité n’a pas de prix, à moins de pouvoir l’évaluer dans votre contexte projet

Renaud Comte aka TheMit (“Waldek fan 4 ever” comme beaucoup d’ailleurs)
Member of WygTeam
http://www.wygwam.com