What does partial trust mean the Web Part developer?
If you install assemblies into the BIN directory, you must ensure your code provides error handling in the event that required permissions are not available. Otherwise, unhandled security exceptions may cause your Web Part to fail and may affect page rendering on the page where the Web Part appears.
The following is a typical example of a security exception:
Request for the permission of type Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c failed As stated previously, the WSS_Minimal trust level does not grant permission to the SharePointPermission.ObjectModel to assemblies in the BIN directory for an application. Therefore, if your code attempts to use the Microsoft SharePoint object model, the common language runtime (CLR) throws an exception.
Since the minimal permission set provides the smallest set of permissions required for code to execute, the likelihood of additional security exceptions is increased.
Recommendation Try-catch critical areas to address situations where you may not have the necessary permissions to accomplish a specified objective.
What if my assemblies are installed in the GAC?
By default, assemblies installed in the global assembly cache (GAC) run with Full trust. Although, installing your Web Part assembly in the GAC is a viable option, it is recommended that you install Web Part assemblies in the BIN directory for a more secure deployment.
How can I raise the trust level for assemblies installed in the BIN directory?
Windows SharePoint Services can use any of the following three options from ASP.NET and the CLR to provide assemblies installed in the BIN directory with sufficient permissions. The following table outlines the implications and requirements for each option.
| Option | Pros | Cons |
| Increase the trust level for the entire virtual server. For more information, see "Setting the trust level for a virtual server" | Easy to implement. In a development environment, increasing the trust level allows you to test an assembly with increased permissions while allowing you to recompile assemblies directly into the BIN directory without resetting IIS. | This option is least secure. This option affects all assemblies used by the virtual server. There is no guarantee the destination server has the required trust level. Therefore, Web Parts may not work once installed on the destination server. |
| Create a custom policy file for your assemblies. For more information, see "How do I create a custom policy file?" | Recommended approach. This option is most secure. An assembly can operate with a unique policy that meets the minimum permission requirements for the assembly. By creating a custom security policy, you can ensure the destination server can run your Web Parts. | Requires the most configuration of all three options. |
| Install your assemblies in the GAC | Easy to implement. This grants Full trust to your assembly without affecting the trust level of assemblies installed in the BIN directory. | This option is less secure. Assemblies installed in the GAC are available to all virtual servers and applications on a server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary In a development environment, you must reset IIS every time you recompile assemblies. Licensing issues may arise due to the global availability of your assembly. |
I changed the trust level in the web.config file—now my entire site fails to render. What should I do?
If you change the trust level in the web.config file, Windows SharePoint Services may fail to render on subsequent requests. The following is an example of a typical error:
Assembly security permission grant set is incompatible between appdomains. To resolve the conflicting trust setting, reset Internet Information Services (IIS) such as by using iisreset.
Note This is a known issue related to the architecture of ASP.NET and the .NET Framework.
How do I create a custom policy file?
To customize one of the built-in policy files, it is recommended that you make a copy of it and make changes to the copy to ensure that you can reuse the original file if necessary.
The following procedure describes how to give access to the Microsoft SharePoint object model to a specific assembly.
To give access to an assembly
- Copy the wss_minimaltrust.config file.
- Rename the file new_file_name.config.
- Using a text editor such as NotePad, open new_file_name.config
- Under the
element, add a reference to the SharePointPermission class as follows:
5. 6. 7. 8. Description="Microsoft.SharePoint.Security.SharePointPermission, 9. Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, 10. PublicKeyToken=71e9bce111e9429c" /> 11. - Search for the
tag where the name attribute equals ASP.Net. - Copy this entire tag and all of its children, and paste a copy of it immediately below the one you copied.
- Change the name of the new PermissionSet element from ASP.Net to New_File_Name:
Example (Before)
Example (After)
Name="New_File_Name"> - Add the following
node to the element where the name attribute equals New_File_Name:
16. 17. version="1" 18. ObjectModel="True" /> Therefore, the resulting customized
New_File_Name"> Level="Minimal" /> /> /> ObjectModel="True" /> - Once you define the customized element, you must create a code group to specify when the CLR should apply the permission set.
Important By default, the AllCode code group is a FirstMatchCodeGroup in ASP.NET policy files. Therefore, the CLR stops assigning permissions to an assembly after the first match to a specific code group. To apply the custom permissions, you must declare the specific code group assigning the custom permissions to your assembly as the first code group within the AllCode group. This ensures that the CLR assigns the MyCustomPermissions permission set and stops without proceeding to the default $AppDirUrl$/* code group that is used to assign permissions based on whether the assembly is located in BIN directory.
In the following example, the membership condition for the new code group is based on strong name membership:
version="1" PermissionSetName="MyCustomPermissions"> version="1" PublicKeyBlob="... see note below ..." Name="MyAssemblyName" /> Note To retrieve the public key blob for an assembly, use the secutil.exe tool as follows:
secutil.exe -hex -s MyAssemblyName.dll For more information about secutil.exe, see Secutil Tool.
- Save and close the file. The policy file is ready to use.
- Open the web.config file for the virtual server extended with Windows SharePoint Services and add the following
tag to the SecurityPolicy element:
22. 23. policyFile="new_file_name.config" /> In the web.config file, change the
- Save and close the web.config file.
- Reset IIS, such as by using iisreset, to apply the custom policy to the specified virtual server.
What if my assembly is not strongly named? How does my code group change?
You can specify membership conditions for a code group in several ways. You can use the UrlMembershipCondition to specify conditions as follows:
version="1" PermissionSetName="MyCustomPermissions"> version="1" Url="$AppDirUrl$/bin/MyAssemblyName.dll" />My assembly refers to a library assembly. Everything works when the assembly is installed in the GAC, but fails once the assembly is placed in the BIN directory. What is going on?
Assuming you granted the required permissions to an assembly, the reason your assembly cannot run may be related to how the library assembly was built. By default, strongly named assemblies allow only callers who are granted Full Trust. Therefore, the CLR blocks a partially trusted assembly from calling into a Full Trust-only assembly.
You have several possible solutions, both of which have security implications that you must consider:
- When compiling the assembly, you can add the AllowPartiallyTrustedCallersAttribute attribute to the specified library assembly.
Important You can only add this attribute to the source code. If you are using a third-party assembly and do not have access to the source, you cannot choose this option. If you choose this option, you are allowing partially trusted callers to execute code from within the library. This could represent a potential security risk as it opens the specified library assembly for use by other callers with partial trust.
- You can give your assembly Full trust by installing it to the GAC.
Important Assemblies installed in the GAC are available to all virtual servers and applications on the server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary.
- You can give your assembly Full trust by creating a custom policy file as outlined in the previous section.
Important It is recommended that you choose this option as it allows you to explicitly grant the required minimum level of permission to your assembly without increasing the scope of access to a larger number of callers.
I am trying to access a Web service by using a Web Part. When I do so, I get a Security Exception as follows:
Request for the permission of type System.Net.WebPermission, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed. By default, assemblies in the BIN directory do not have the required permission, System.Net.WebPermission, to access Web services. To grant this permission, add the following to the corresponding IPermission element in the appropriate policy file:
I want to access a Web service from my Web Part. When I do so, I get an InvalidOperationException as follows:
One or more assemblies referenced by the XmlSerializer cannot be called from partially trusted code. When you create a reference to a Web service, Microsoft Visual Studio®.NET creates and places one or more objects in your assembly to store the argument data passed to the method(s) in the Web service. These objects are serialized using the XmlSerializer class when you invoke one or more of the methods in the Web service. By default, if your assembly is strongly named and resides in the BIN directory, callers with partial trust cannot access objects within that assembly. When you make the call to the Web service method, the XmlSerializer detects that there are partially trusted callers on the callstack (i.e. your assembly) and prevents the serialization from taking place even though the object resides in the same assembly.
You have several possible solutions, both of which have security implications that you must consider:
- You can add the AllowPartiallyTrustedCallersAttribute attribute to the specified library assembly.
Important You can only add this attribute to the source code. If you are using a third-party assembly and do not have access to the source, you cannot choose this option. If you choose this option, you are allowing partially trusted callers to execute code from within the library. This could represent a potential security risk as it opens the specified library assembly for use by other callers with partial trusts.
- You can give your assembly Full trust by installing it to the GAC.
Important Assemblies installed in the GAC are available to all virtual servers and applications on the server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary.
- You can give your assembly Full trust by creating a custom policy file as outlined in the previous section.
Important It is recommended that you choose this option as it allows you to explicitly grant the required minimum level of permission to your assembly without increasing the scope of access to a larger number of callers.
Where can I learn more about code access security?
For more information about code access security, see the following:
No comments:
Post a Comment