Integrating Dynamics CMS with Sharepoint ASCX SecurityException Issue

Question

Hi,

I've an ASCX control (WebParts aren't used in this solution) which interrogates CMS 4's data via the API provided by Microsoft.Crm.Sdk and Microsoft.Crm.SdkTypeProxy.

The solution works until it's deployed to Sharepoint.

Initially I received the following error:

[SecurityException: That assembly does not allow partially trusted callers.]
   MyApp.SharePoint.Web.Applications.MyAppUtilities.RefreshUserFromCrm(String login) +0
   MyApp.SharePoint.Web.Applications.MyApp_LoginForm.btnLogin_Click(Object sender, EventArgs e) +30
   System.Web.UI.WebControls.Button.OnClick(EventArgs e) +111

Then I tried wrapping the calling code in the ASCX with SPSecurity.RunWithElevatedPrivileges:

SPSecurity.RunWithElevatedPrivileges(delegate()
{
   // FBA user may not exist yet or require refreshing
   MyAppUtilities.RefreshUserFromCrm(txtUser.Text);
});

But this resulted in the following error (I'm thinking RunWithElevatedPrivileges isn't for this sort of thing anyway, but someone suggested it):

[SecurityException: Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.]
   MyApp.SharePoint.Web.Applications.MyApp_LoginForm.btnLogin_Click(Object sender, EventArgs e) +0
   System.Web.UI.WebControls.Button.OnClick(EventArgs e) +111

When I elevate the trust level in the Sharepoint site to full everything works fine, however I need to come up with a solution that uses minimal trust (or a customised minimal trust). I'm also trying to stay clear of adding anything to the GAC. Any ideas?

I assume the issue is occuring when trying to call functionality from Microsoft.Crm.*

Thanks in advance for any help anyone can provide.

Cheers, Gavin

Answer 1

Which method from Microsoft.Crm.Sdk exactly throws SecurityException? Check on MSDN and see what permissions does it need to be called.

Regarding to RunWithElevatedPrivileges, you can see from documentation that it needs

[SharePointPermissionAttribute(SecurityAction.Demand, Impersonate=true)] 
[SharePointPermissionAttribute(SecurityAction.Demand, ObjectModel=true)] 

And the user in comments provided an example of CAS permission set to enable those permissions:

<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration, UnmanagedCode" />
<IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" Impersonate="True" UnsafeSaveOnGet="True"/>

Otherwise you don't have necessary permissions to call the code if assembly is not fully trusted. The same probably goes with some method from Microsoft.Crm.Sdk

Answer 2

I would use the GAC.

I understand where you are coming from. I tried to avoid using the GAC when I first started with SharePoint development. But it's really the way to go.

Add the following into the manifest.xml of your solution package:

<Assemblies>
    <Assembly Location="MyApp.SharePoint.Web.Applications.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>

And then deploy your package using:

stsadm.exe -o deploysolution -name MyApp.wsp -immediate -allowgacdeployment -force

If you still want to stay out of the GAC, you can try adding the following to AssemblyInfo.cs:

[assembly: AllowPartiallyTrustedCallers]

But if you are then going to call DLLs (like Microsoft.Crm) and if those DLLs don't allow Partially Trusted Callers, then you are stuck.

In addition, if you haven't already, you will probably need to create a custom policy file. It was the manual creation and registration of a custom policy file that granted privileges too broadly that finally convinced me to move to the GAC. Haven't looked back since.