Here is scenario:
Global Exception Logging:
I created an HttpModule that will log all handled exceptions in my ASP.NET applications. I wanted the exception logging to be done without requiring every application to add its own reference to the HttpModule. Simple enough. Strong name the assembly, install it in the GAC and then add a line to the machine.config and its all done.
Reporting Services throws an exception on my Exception Handler:
”Exception Details: System.Security.SecurityException: Request for the permission of type System.Web.AspNetHostingPermission, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.”
I started looking into the way security is done in reporting services and discovered that it was defining its own security policy and trust level.
<
securityPolicy>
<trustLevel name="RosettaMgr" policyFile="rsmgrpolicy.config"/>
</securityPolicy>
<trust level="RosettaMgr" originUrl=""/>
After trying some Google searches and Microsoft Knowledge Base searches I realized I was not going to be able to figure this one out quickly on my own. Everything related to custom security policies that I found seemed to be for SharePoint server. It was going to require a call to Microsoft to get an understanding of what needed to be changed in the security configuration and where it needed to be changed.
Microsoft indirectly provides the solution:
I spent a hour or so on the phone with support playing the try this game. We got nowhere. It was Friday. Monday morning I received an Email update asking me to try adding an assembly attribute in my own code. That did not work either. It is something required for code you may call from inside of a report, but not for code that runs outside of report services itself. However, the link I was given describing Using Strong-Named Custom Assemblies took me to the place within MSDN where I was able to find my answer. Don't ask me why, but I never considered diving into MSDN for help on this issue. Once I got down into the section for Programming Reporting Services I found a nice section on Understanding Code Access Security in Reporting Services. That was exactly what I needed. Too bad I did not find the documentation before I called Microsoft. It would have saved us both a few hours.
The Solution
Using Reporting Services Security Policy Files described for me exactly how I could define a security policy for my assembly and then copy it into the Reporting Services policy configuration files. Through the process I also decided to trust all code that was strong-named with my key so that future appropriately signed global assembly additions would not break Reporting Services.
In the rsmgrpolicy.config I now have a section of code the I copied out of my security.config and everything is working great.
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Attributes="LevelFinal"
Name="Idaho_Strong_Name"
Description="This code group grants Idaho custom code full trust.">
<IMembershipCondition class="StrongNameMembershipCondition"
version="1"
PublicKeyBlob="--INSERTHERE--" />
</CodeGroup>
I hope this information helps someone else avoid the same problem I ran into.