Maybe you're tired of putting your SharePoint web application in full trust and running web applications with huge security surface areas. Or maybe you've become tired of GAC'ing assemblies just so that they can run in full trust. Heck, maybe you've even read this article and decided to finally start handling Code Access Security in a more elegant way.
All of the above are good reasons to make a custom Code Access Security policy file, and in the following section we're going to do just that. If you're curious as to why you might be doing this in the first place, it might be a good idea to peruse common code access security issues described here.
Creating A Custom Policy File
The intent of the custom policy we're about to make is to allow your code and only your code to run in full trust regardless of where it is (doesn't have to be in the GAC). All other code in the application will be running as WSS_Minimal which means it will have a reduced set of privileges (see table). For example, codes running in WSS_Minimal can't access the SharePoint object model. Your code however will be running in full trust and will be able to do whatever it wants.
This is often desirable since we have no idea what web parts information workers or administrators will lob into our SharePoint application. It's a little presumptuous to assume that they're all safe and won't do anything malicious. Granting them full trust allows them to do things like write to sensitive areas of the disk, access the registry, etc... Users with high privileges (ie. administrators) get duped in to running malicious code all the time, that's one of the reasons Code Access Security exists in the first place. If you're curious about what the difference between code running in full trust and code running in WSS_Minimal is, refer to the table in the link above. Onward.
- First make a copy of C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CONFIG\WSS_Minimal.config and put it in your application folder, call it WSS_Custom.config. If you want to increase the privileges of other code you can start with WSS_Medium, this will allow other code to access the SharePoint API without having security exceptions thrown.
- Strong name your assembly. We're not going to put in the GAC, but it still needs to be strong named so that it can be uniquely identified by the WSS_Custom.config policy file.
- Open up the Visual Studio Command Prompt (or go find sn.exe) and extract the public key from your .snk file into another file. (It's worth noting that the Public Key is not the same as the Public Key Token that you might get from your assembly using Reflector). sn -p YourStongNameFile.snk PublicKeyOnly.snkYou should see the output "Public key written to PublicKeyOnly.snk".
- Now we print out that public key with the following command: sn -tp PublicKeyOnly.snk
- Copy that insanely long stream of numbers (your assembly's public key). Add the following line to your WSS_Custom.config just below the <CodeGroup class="FirstMatchCodeGroup"...>'s <IMembershipCondition> element.
<CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Nothing">
<IMembershipCondition class="AllMembershipCondition" version="1" />
<!--[Your Entry Here]-->
<CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
<IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="[Your Public Key]"></IMembershipCondition>
- Now ensure that you're web.config uses your custom policy file. Add the following line right under <SecurityPolicy>:
<trustLevel name="WSS_Custom" policyFile="[path to wss_custom.config]" />
- Finally change your web applications trust level to use your custom policy file. Ensure that the <trust/> element looks like below:
<trust level="WSS_Custom" originUrl="" />
- That's it, you're done! You may need to restart IIS if you get an "Assembly <assemblyName> security permission grant set is incompatible".
I've posted a sample WSS_Custom.config if the above was confusing.
If you were getting security exceptions before they should be gone now, at least all those coming from your assembly. Other code will continue to run in WSS_Minimal (or WSS_Medium if you used that .config as a template) and may throw security exceptions should they try to access APIs that they don't have the privileges to do so.
This is a lot more preferable than two popular alternatives:
- Having the entire web application run in full trust (which gives all assemblies full trust).
- Putting your assemblies in the GAC just so that they can run in full trust.
Hope that helps.