Code Access Security across multiple assembly security extension

Hello there I have trying to figure out for days how to enable FullTrust for my Reporting Services security extension.

I can successfully run the sample, but my implementation which splits the data and verification logic across two dlls fails each time it reaches the data layer.

Simply and succinctly as I can write it my security extension consists of the following.

Business.dll
This dll is configured in RSReportServer.config, again as per the Microsoft sample.
This dll is also configured in rssvrpolicy.config, I have used UrlMembershipCondition and StrongNameMemberCondition successfully.
This is called successfully by Reporting Service security extension as it is set up no differently to the samples from Microsoft.
I can even debug into this dll to the point it fails.

Data.dll
This is called by the Business.dll to get any data from the database used to authenticate the user.

It is the call to Data.dll that fails, with System.Web.Services.Protocols.SoapException: Server was unable to process request. > System.Security.Policy.PolicyException: Required permissions cannot be acquired

So how do I enable the security extension to allow access to Data.dll.

I imagine it is a matter of finding the right code group combination but I can't seem to fathom it out. Or am I barking up the wrong tree.

I am also using Enterprise Library, so I guess I would have to apply any solution to those dlls too.

Many thanks for any help in advance,

Gurbhajan

ps ignore my lame signature below.Forgive me I just realised this is 2005 only forum, I was referring to 2000.

If the same solution applies to 2005 and 2000, I shall be happy to hear that too as I shall use the 2005 when it released and so will have to migrate the code.

Thanks again,

Gurbhajan|||i am experiencing a similar issue. my custom authentication DLL worked until i changed it to call out to a web service using WSE2.0(sp3). as soon as it tries to create the instance of my proxy class, i get that error. has anyone figured this out?|||i should add that my authentication DLL actually calls methods in two other DLLs - Microsoft.Web.Services2.dll and a little error logger i wrote. i configured the error logger in rssrvpolicy.config, and it works without a hitch. i tried the same with the WSE DLL, in c:\program files\microsoft wse\v2.0, but no go. is it because Microsoft.Web.Services2.dll is in the GAC? how do i go about instructing Reporting Services to trust a DLL that's in the GAC?

... so i decided to see if i could find out before posting that... and it was good thinking. i added the following to rssrvpolicy.config:

<CodeGroup class="UnionCodeGroup" Version="1" PermissionSetName="FullTrust" Name="assemblies in the GAC">
<IMembershipCondition class="UrlMembershipCondition" Version="1" Url="$Gac$/*" />
</CodeGroup>

and my WSE proxy went and did its thing and there was much rejoicing. now, i'm guessing that the $GAC$/* is probably overkill since it trusts everything in the GAC, but i believe we've learned that you can trust assemblies in the GAC with $GAC$/assembly name. i'll try later, but i'm satisfied with this for now.

to the original poster: does your DLL reference any GAC DLLs that aren't signed with the Microsoft strong name (WSE apparently is not)? i tried to fix the error by wrapping my proxy in another DLL, into which i could step with the debugger fine, but i still got that error as soon as any method tried to touch a reference to the WSE proxy class. that's what keyed me off to trusting the DLL in the GAC.

i hope this helps.|||i couldn't get $gac$/assemblyname to work. but i replaced it with a StrongNameMembershipCondition with the PublicKeyBlob extracted from Microsoft.Web.Services2.dll, and i am now in business.

but if you're not using WSE, then this probably won't help. but i guess good advice would be to make sure any assemblies your custom DLL is using have a strong name, and be sure they're in the policy file.|||

sorry to spam your thread. but i belatedly noticed that you said you're using Enterprise Library. so make sure the EL assemblies are signed (you may have to sign them yourself) and add a code group for that (there are already a few StrongNameMembershipCondition code groups in rssrvpolicy.config, if you need examples) or just add code groups for the individual assemblies you're using. basically, everything you're using needs to be trusted, or it probably won't work.

|||Thank you Scott, I have only just returned to this thread after having solved the problem some time ago with the very solution you have described.

It is rather a big job signing Enterprise Library but the trick is to sign it with one key so that you only need to add one Code Group to the policy file to cover all of the dlls that may be loaded by your custom extension.

I shall update this thread further a little later on as I am now in the middle of deploying the solution and add any new experiences if I encounter them.

Gurbhajan|||

Also, if you have assemblies that you CANNOT sign, try using the UrlMembershipCondition for those assemblies. I just did this with a custom FormsAuth Security Extension that had dependencies upon 3rd party libraries that were not signed.

Someone really needs to write a small whitepaper on CAS and Sql Reporting extensions, since it can be quite a pain.

Maybe I'll blog about it one day when I have more time.... (note to self)

~Lance

|||

I echo that. There are very few documented use cases and majority of developers are struggling with security set-up. A lot of time can be saved if clear examples are given.

We also need recommnedations for best practices as there are many ways to implement code security.