Granular SharePoint Security: 3rd Party DLLs and SharePoint 2010 Custom Security Files
Sometimes you might need to incorporate third party DLLs into your SharePoint 2010 solutions; we’re big fans of the Aspose family of solutions (http://www.aspose.com) over here at LimeLeap. They provide powerful components that can read and write Microsoft Office files, such as Excel workbooks. I was coding against Aspose.Cells the other day, and when I tested the code on my SharePoint site, one of the component’s formatting methods threw an object reference error. This wasn’t a method one would think would cause a problem; just a method that auto size’s Excel columns. I contacted Aspose for support, and they had me write a console app I could send to them to highlight the issue. My only problem; the console app worked as it was supposed to!
It then occurred to me that SharePoint might be blocking something. As a rule, even on my development machines, I never run my entire SharePoint site under FullTrust. It’s a discipline thing. Before you know it, you wind up running FullTrust on your SharePoint test sites, and then eventually the practice invades your Production sites. Best to nip bad FullTrust practices in the bud at the development level.
So here’s how I fixed the problem:
1) I created a copy of the “wss_minimaltrust.config” configuration file, which is usually located in SharePoint’s CONFIG directory, and named it “wss_custom.config”
2) In the new file, I then added the following entry for the Aspose.Cells component under the “FirstMatchCodeGroup”, giving it and only it FullTrust permissions. (If you have security auditing procedures, you might want to make sure the component you are doing this for can be approved for FullTrust execution).
<CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
<IMembershipCondition class="UrlMembershipCondition" version="1"
3) In my SharePoint site’s web.config file, I then added the following line for my new security file within the <securityPolicy> tag.
<trustLevel name="WSS_Custom" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_custom.config" />
4) In the same web.config file, I then set the <trust> tag to use that setting:
<trust level="WSS_Custom" originUrl="" />
Everything worked great at that point, and my custom Excel reports started working in SharePoint 2010.
So, what are the morals of this story?
1) Don’t be surprised if 3rd party DLLs without additional security permissions within SharePoint 2010 stop working while doing something seamingly light. The Aspose.Cells component worked great until I needed to use that one auto-resize function. Test your code outside of SharePoint if you can to isolate SharePoint as the factor causing the issue.
2) If you do need to grant a component extra permissions, do it granularly using custom security files. Do NOT enable FullTrust throughout your entire SharePoint 2010 site.
3) For components you do need to run with FullTrust permissions, make sure you talk with your organization’s IT powers-that-be, so that those components can be approved for deployment.
4) You might also want to try out permission levels between Minimal and FullTrust; SharePoint 2010 has levels in between that you can try your 3rd party DLLs with; find the lowest permission level that will allow your component to operate and go with that.
Follow the author Paul Katz, Chief Software Architect for LimeLeap, on Twitter: @napkatz