Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

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:

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

image

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

image

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

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

image

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 Sourire

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

Liens pratiques :

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

  1. Modifier les propriétés de déploiement

    image
  2. Ajoutez le CAS dans le designer de package

    image
  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

image

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

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

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

image

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

Mots clés Technorati : ,,,,,

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: vendredi 4 mai 2012 14:01 par themit

Commentaires

nicoboo a dit :

Tant qu'il n'y aura pas de solutions automatiques ou assistées devrai-je dire, de génération de ces CAS, le développeur, par fainéantise, choisira la solution la plus simple et déploiera soit dans le GAC, soit dans le BIN en Full Trust (ou WSS_Medium).

Je m'y suis cassé les dents à de nombreuses reprises, l'écriture de ces CAS est une plaie si elle n'est pas prévue au fil du développement et surtout lorsque cette considération n'est pas connu du développeur utilisant la plateforme SharePoint (Et tu sais mieux que moi que c'est souvent le cas avec les "développeurs SharePoint").

Bref, les CAS c'est bien, mais si c'est pour en fait nimporte quoi et attribuer des droits sans connaître l'impact, ça revien à la même chose. A considérer avec prudence comme tu l'indiques, la sécurité n'a pas de prix... même si pour le développeur, souvent la problématique de prix et lié au temps de développement/réalisation de la solution et que c'est précisément l'édition de ces CAS qui devient couteuse et amène un prix à la sécurité :)

# mai 4, 2012 15:06
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Nettoyage des versions de List Item avant migration depuis SharePoint On Premise vers SharePoint Online par Blog Technique de Romelard Fabrice le 08-08-2017, 15:36

- Office 365: Comment supprimer des éléments de liste SharePoint Online via PowerShell par Blog Technique de Romelard Fabrice le 07-26-2017, 17:09

- Nouveau blog http://bugshunter.net par Blog de Jérémy Jeanson le 07-01-2017, 16:56

- Office 365: Script PowerShell pour assigner des droits Full Control à un groupe défini par Blog Technique de Romelard Fabrice le 04-30-2017, 09:22

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06