Sladescross's Blog

Blogging about Sharepoint related stuff

Simple Steps to a Custom Policy File for Code Security May 15, 2011

Filed under: Code Access Security — sladescross @ 3:38 pm

Using the SmartPart to create web parts solves these issues. You don’t need to create a DWP file and you don’t need to change your Web.Config! Once you have deployed your web part, you may have some problems regarding Code Access Security. Out-of-the-box SharePoint is running with a trust level that contains very limited privileges. For example: you can not access the object model or a web service; this will give you a security exception. If you take a look at the Web.Config file, you will see that SharePoint is running using the WSS_Minimal trust level (<trust level=”WSS_Minimal” originUrl=”” />). Where is this WSS_Minimal defined? Well if you look in the securityPolicy section of the Web.Config you will find:

<securityPolicy> <trustLevel name="WSS_Medium" 
policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_mediumtrust.config" /> <trustLevel name="WSS_Minimal" 
policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_minimaltrust.config" /> </securityPolicy>

So WSS_Minimal is pointing to a trust level which is defined in the wss_minimaltrust.config on your hard disk. As you can see, another default trust level is WSS_Medium which will add permissions to access the object model. If you write a web part that uses the SharePoint object model, make sure you set the trust level to WSS_Medium. What about web parts that contain really dangerous stuff like accessing a web service or, even worse, writing a file on the hard disk? Well you need to make sure that you web part is running with elevated privileges. So far the theory, how can we do this? There are several possibilities:

  • Set the trust level in the Web.Config to full.This will solve all your CAS problems because everything will be running with full trust. Of course this is not a good solution, so use it only on your dev machine for testing reasons!
  • Deploy your web part assembly to the GAC instead of to the BIN folder.Assemblies deployed to the GAC will run with full trust, so it solves all CAS issues for the assembly in the GAC. Is this a good solution? In my opinion this is abusing the GAC to gain full trust permissions. I know some people would argue differently, but my advice: do not abuse the GAC for this. Especially during your development cycle, assemblies deployed to the GAC are cached so you will need an IISReset when you deploy a new version.
  • Create a custom policy file that will grant full trust to your own assembly. This is my favorite solution; it’s the most difficult to implement, but it’s very secure and you only have to do the work once.

Code Access Security December 10, 2010

Filed under: caspol.exe,Code Access Security — sladescross @ 4:18 pm

Note that Code Access Security is based on two key concepts, namely, Code Groups and Permissions. Each and every .NET assembly belongs to a particular Code Group. Each Code Group in turn is granted a set of permissions that are specified in the permission set to which it is associated. You can use the following command in the command line to see the code groups defined on your system:

Assemblies are matched to code groups dependent on the membership conditions they match. You can easily view the code groups that an assembly is a member of using this command: caspol.exe –resolve group firstApplication.dll


Code Access Security December 3, 2010

Filed under: Code Access Security — sladescross @ 10:54 am

You will first need references to Microsoft.SharePoint.Security and System.Security.Permissions. Next add the following line. It allows for the assembly to run outside of Full Trust.

[assembly: System.Security.AllowPartiallyTrustedCallers()]

The last thing I recommend in your AssemblyInfo.cs is a static file version during development. The reason for this is that you have to specify the version number on your Safe Control statement later.

[assembly: AssemblyVersion("")]

Now the fun part. Specifying Code Access Security. You will need to add a reference to Microsoft.SharePoint.Security to your project. Let me first show you the section and then I will attempt to explain why each one is required.

      <PermissionSet version="1"
	Description="Permission set for MyAssembly.">
        <IPermission version="1"
        <IPermission version="1"
	  Flags="Execution, ControlPrincipal, ControlAppDomain,
          version="1" ObjectModel="True" Impersonate="True" UnsafeSaveOnGet="True"
          version="1" Read="UserName">
        <IPermission version="1"
          Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$">
        <Assembly Name="MyAssembly" >

ASP.NET Impersonation Methods November 24, 2010

Filed under: Code Access Security,Impersonation — sladescross @ 12:26 am

Microsoft article on how to build a custom Generic Principal.

Thread on how to setup the user principal before web page is built.

List of approaches

Some code.

HttpContext context = HttpContext.Current;   
// Get the service provider from the context           
 IServiceProvider iServiceProvider = context as IServiceProvider;
//Get a Type which represents an HttpContext           
Type httpWorkerRequestType = typeof(HttpWorkerRequest);
 // Get the HttpWorkerRequest service from the service provider           
// NOTE: When trying to get a HttpWorkerRequest type from the HttpContext           
// unmanaged code permission is demanded.           
HttpWorkerRequest httpWorkerRequest =
            iServiceProvider.GetService(httpWorkerRequestType) as HttpWorkerRequest;
 // Get the token passed by IIS           
IntPtr ptrUserToken = httpWorkerRequest.GetUserToken();
// Create a WindowsIdentity from the token           
WindowsIdentity winIdentity = new WindowsIdentity(ptrUserToken);           
Response.Write(“Before impersonation: ” + WindowsIdentity.GetCurrent().Name + “<br>”);
// Impersonate the user           
WindowsImpersonationContext impContext = winIdentity.Impersonate();
Response.Write(“Impersonating: ” + WindowsIdentity.GetCurrent().Name + “<br>”);
// Place resource access code here     
// Stop impersonating           
Response.Write(“After Impersonating: ” + WindowsIdentity.GetCurrent().Name + “<br>”);

Impersonation and consideration of code access security issues to allow web part to impersonate.

Thread with references for impersonation.


Code Access Security Introduction For Sharepoint Administrators December 19, 2009

Filed under: Code Access Security,Sharepoint — sladescross @ 3:01 pm



Get every new post delivered to your Inbox.

Join 63 other followers