Sharepoint Faq

SharePoint Web Part Deployment & Security
A Bamboo Solutions FAQ Version 1.0
Contents Introduction .................................................................................................................................. 2 Frequently Asked Questions (FAQ) ................................................................................................... 3 Will I need a dictionary to read this FAQ? ................................................................................... 3 What is code access security and how does it relate to SharePoint? ............................................... 3 What are my options when installing Web Parts on my SharePoint server? ..................................... 3 What is a trust level? What are the differences between the different levels? ................................. 5 So, should I install this Web Part in the \BIN directory or the Global Assembly Cache (GAC) or should I create a custom security policy?.................................................................................... 6 The Web Part installation was fine, but an error message A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as a safe control shows up in the page? ........................................................................................... 6 I received an error message when trying to install the Web Part Can not connect to the configuration database? ........................................................................................................ 7 I received this warning message after installing the Web Part?...................................................... 7 I changed the trust level in the web.config file and now my SharePoint site fails to render? .............. 7 What exactly happens when I run the installation, where are the files going?.................................. 7 How do I manually install the Web Part?..................................................................................... 8 So I heard the term virtual server tossed around quite a lot here. What does it really mean? ........ 9 I have multiple virtual servers on my machine, and I cant seem to install the Web Part on one of my virtual servers? ................................................................................................................ 11 Is there anything I can do to check and make sure my Web Part is installed and behaves correctly on my server?.......................................................................................................... 11 What does strong name mean when referring to a Web Part? ................................................... 12 How do I create a custom policy file? ....................................................................................... 12 I created a custom policy file using the example above, but I cant get it to work. What am I doing wrong? ........................................................................................................................ 15 What if my Web Part assembly is not strong name? How can I add it to a code group? .................. 15 Help, Im looking at a policy file and Im really confused! ........................................................... 15 How is my policy file being evaluated? ..................................................................................... 21 Why are some Web Parts showing up in the Virtual Server Gallery and some in other galleries? ...... 22 References.................................................................................................................................. 23
Authors: Lam Le, Julie Martin, Wes Bryan Last Update: December 16, 2005
SharePoint Web Part Deployment & Security FAQ V1.0
Introduction
This Frequently Asked Questions provides information related to the topic of Code Access Security when installing Web Parts in Microsoft SharePoint environment. The primary emphasis is to provide additional tips to the IT administrators, SharePoint site architects, and web designers who are responsible for setting up and maintain a secured SharePoint portal. This FAQ is maintained at http://store.bamboosolutions.com/c-7-sharepoint-tips.aspx. Please send comments and questions to sptpm@bamboosolutions.com.
About Bamboo Solutions Corporation Bamboo Solutions Corporation is a software technology provider specializing in collaborative software solutions built on .Net, Microsoft SharePoint Technology and Services. Our business collaboration solution is designed for clients who need rapid implementation, quick user acceptance and immediate productivity gains. Bamboo Solutions is a privately held company with headquarters in Reston, Virginia. Bamboo Solutions Corporation 11417 Sunset Hills Road, Suite 105 Reston, VA 20190 store.bamboosolutions.com
12/09/05
Bamboo Solutions FAQ
Page 2 of 23.
Frequently Asked Questions (FAQ)

Will I need a dictionary to read this FAQ? The bad news is yes, if you re not familiar with .Net, most of this content will look like Greek (or is it Geek). The good news is there is some help in the Administrator's Guide for Windows SharePoint Services, and do not forget to use the glossary in the online help for the SharePoint Portal Server.
What is code access security and how does it relate to SharePoint? Before the release of ASP.NET 1.1, role-based security was the primary means of protecting access to system resources. This basically means that access to our resources such as the file system, databases, registry, and environment variables were available to our applications as long as the user who runs the program had the appropriate permissions. This type of role-based security leaves security holes that allow buggy and/or malicious code to potential wreak havoc in the environment once it was able to get behind the firewall, such as scripts that embedded in a body of an email message. Code Access Security (CAS) is the new feature introduced in ASP.NET 1.1 to prevent this problem. Basically, CAS is an added security model that allows an assembly (Web Part) to execute within its environment. SharePoint, being based on the ASP.NET framework, interacts with code access security to set the execution permissions on the assemblies code, and grants access only to the resources it needs to execute successfully and no more. This is also referred to as partially trusted code. So your main job as the system administrator is to make sure Web Parts are loaded properly into the SP environment, set the correct permission to do its job, and prevent it from accessing other resources.
What are my options when installing Web Parts on my SharePoint server? Out of the box, SharePoint implements a trust level of WSS_Minimal (see details below on WSS_Minimal) for all sites. Any Web Parts that are deployed to a virtual server (default at \inetpub\wwwroot\bin) directory are affected by the trust level set in the web.config file for that virtual server. As a result, any Web Parts deployed to this directory operate with significant limitations. For example, they do not have access to the SharePoint object model. If the Web Part you are installing attempts to access an
12/09/05
Page 3 of 23.
unauthorized resource, the Common Language Runtime (CLR is responsible for running all programs under .Net) will throw an exception error. When a Web Part fails to run due to a security issue, you will find a message like this on the server event log file:
If you want certain Web Parts to be able to access resources that require a higher trust level, you have three options: Raise the trust level for all SharePoint sites, Deploy your Web Parts to the Global Assembly Cache (GAC), or Create your own custom policy. 1. Raising the trust level for all SharePoint sites in a virtual server You can raise the trust level for all SharePoint sites of a virtual server by simply editing the <trust> element in the web.config file to apply the WSS_Medium trust level. Raising the trust level in this manner is convenient for development environments but is not recommended for production server. To raise the trust level, edit the appropriate web.config file for the virtual server, search for the <system.web> section, and modify the code in the <trust> element. Once you have raised the trust level, reset IIS to have the changes take effect.
<system.web> <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> <httpHandlers> < remove for clarity > <pages enableSessionState="false" enableViewState="true" enableViewStateMac="true" validateRequest="false" /> <trust level="Full" originUrl="" /> <machineKey validationKey="27C52DA26AA7E55ED5F5F4F9E65F78A9AD4B808561EA464F" decryptionKey="D454F34A11239C18781B9889EF91DB1CC3A7084FF69FDFC9" validation="SHA1" /> </system.web>
Note: In some IIS configurations, you must install assemblies in the GAC. For example, when you configure an IIS virtual server, extended by using Windows SharePoint Services that has a host header name, you must install Web Part assemblies in the GAC. But generally, you should install custom Web Parts in the Bin directory.
12/09/05
Page 4 of 23.
2. Deploying Web Parts to the GAC The GAC resides in the \windows\assembly directory on the server, and any assemblies that are placed in this directory are available to all virtual servers and applications running WSS, and run at full-level trust. This is also not an appropriate option for a production environment, since assemblies could unintentionally create problems on the system due to buggy code. Assemblies residing in the GAC are not affected by the trust level of the assemblies installed in the virtual server \inetpub\wwwroot\bin directory. To deploy your Web Part assembly to the GAC, you can copy the assembly file into the \windows\assembly directory. You can use the gacutil.exe command-line tool to install the Web Part. This tool is usually in the Windows\Microsoft.NET\Framework\<version> directory. Use:
Gacutil.exe I i myassembly.dll.
Another method for deploying an assembly into the GAC is the stsadm.exe tool:
stsadm.exe -o addwppack -filename <path to Web Part Package> [-url <URL>] [-globalinstall]
-filename specifies the path to the cabinet file containing the Web Parts and associated
resources.
-url optionally specifies the URL of the virtual server on which to install the Web Parts. To install the Web Parts on every virtual server on a server, omit the -url parameter.
-globalinstall tells Stsadm.exe to install the Web Parts in the global assembly cache (GAC) rather than in the Bin directories of each virtual server.
Assemblies installed in the GAC are available to all applications on the server. This is less secure than installing in \bin directories because it potentially grants a higher level of permission to your assemblies across a larger scope than might be necessary. 2. Create your own custom policy file See the How to create custom policy file FAQ item below.
What is a trust level? What are the differences between the different levels? The trust level determines the access granted to a Web Part. There are five ASP.NET trust levels defined by the .NET framework: full, high, medium, low, and minimal. Full trust grants applications unrestricted code access permissions. By default, Web applications built using the .NET Framework version 1.0 run with full trust. Web applications built using the .NET Framework version 1.1 also run with full trust by default; however, the trust level is configurable. If the trust level for an application is set to anything other than full, then it is referred to as a partial-trust application. SharePoint is an example of such an application, since its trust level, by default, is set to WSS_Minimal. The WSS_Minimal trust level is a custom trust level defined by SharePoint that applies a specific set of permissions using a custom policy file. Each trust level maps to a specific XML policy file, which lists the set of permissions and code groups defined for a specific trust level. The default policy files are located in %windir%\ Microsoft.NET\ Framework\<version>\CONFIG directory. SharePoint-specific policy files are located in the <local drive>\Program Files\Common Files\Microsoft Shared\web server extensions\60\CONFIG directory. The <trust> element of the machine.config or the web.config files controls whether CAS is enabled for a Web application.
<securityPolicy> <trustLevel name="WSS_Medium" po1icyFile="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\1Web Server Extentions\60\config\wss_mlnimaltrust.config" /> <securityPolicy> <trust leve1="WSS_Minimal" originUrl=/ <system.web>
12/09/05
Page 5 of 23.
So, should I install this Web Part in the \BIN directory or the Global Assembly Cache (GAC) or should I create a custom security policy? Here are the different pros and cons for the above options. We highly recommend setting up a custom policy file on your SharePoint production server. By creating a custom policy file, you will be able to provide the least amount of privilege to a specific assembly file, thus allowing the most granular and targeted permissions. OPTIONS
Increase the trust level for the entire virtual server.
PRO
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.
CON
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. 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 Licensing issues may arise due to the global availability of your assembly. Requires the most work of all three options, but you only have to do it once.
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.
Create a custom policy file for your assemblies. For more information, see "How do I create a custom policy file?"
Recommended approach as 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.
The Web Part installation was fine, but an error message A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as a safe control shows up in the page? This is a SharePoint error message that indicates: Error when an instance of a Web Part cannot be created or Error when a Web Part does not have the right to rendering on the page by its current setting in the SafeControls list. You configure an Internet Information Services (IIS) virtual server that has an assigned IP address, and then extend that virtual server by using Windows SharePoint Services. See this KB article. You configure an IIS virtual server that has a host header name, you extend that virtual server by using Windows SharePoint Services, and then you install Web Part assemblies in the Bin folder instead of in the global assembly cache. See this KB article.
The most likely problem will be a security (or lack of) issue, so make sure that you review the permissions and rights where the Web Part was installed. Check the following conditions: Set the Trust level in the web.config of the specific virtual server to Full; lowering security requirement on the SP site usually helps make the Web part work. You can then lower the Trust level to WSS_medium and then work backwards to determine what the security issue may be. Remove and re-install the Web Part into the GAC. Put the assembly in the GAC temporarily to make sure that it isn't a security issue.
12/09/05
Page 6 of 23.
If you are installing a Web Part assembly that refers to other DLLs, and if the referenced DLL is in the GAC, but the Web part itself is not, the referenced DLLs may not be written with the AllowPartiallyTrustedCallers so that non-trusted assemblies can be loaded. Make sure to reset IIS with IISRESET after making changes to web.config file.
Remember that in the event a code access security exception is encountered, the exception is recorded in the servers application event log.
I received an error message when trying to install the Web Part Can not connect to the configuration database? This is because the logged in user doesn't have access to the SQL Server. The installation program accesses its database directly so the user account must have access to the database. To solve this problem, make sure you use the appropriate account when installing the Web Part. Or if you know the name and password of the application pools identity, you can try to use the RUNAS command to start a command prompt as the application pools user identity, and manually install the Web Part using STSADM from that command prompt. For example:
1. Locate the STSADN. 2. Press and hold down the SHIFT key while you right-click the program icon, and then click Run as. 3. Click Run the program as the following user, and then type the user name, password, and domain of the administrator account that you want to use. NOTE: If you want to use the administrator account on your computer, type the name of the computer in the Domain box. If you want to use the domain administrator account, type the name of the domain in the Domain box.
I received this warning message after installing the Web Part?
This is most likely a warning after the installation process when current trust level is detected to be set to Full on the virtual server where we attempt to apply CAS settings. This warning can be ignored in this case, but you should check to see if the trust level on this server can be lowered.
I changed the trust level in the web.config file and now my SharePoint site fails to render? If you change the trust level in the web.config file, Windows SharePoint Services may fail to render on subsequent requests. In the SPS you may be directed to a Web Part maintenance page, and in WSS you may see an error like:
Assembly <assemblyName> security permission grant set is incompatible between app domains.
To resolve the conflicting trust setting, reset Internet Information Services (IIS) by using IISRESET.
What exactly happens when I run the installation, where are the files going? Web Parts from vendors such as Bamboo Solutions typically deliver an installation file and a CAB file. The CAB file contains all the files that are needed for the Web Part. The installation program (STSADM) extracts the CAB file and installs the Web part where you select to do the global install (GAC or \BIN).
12/09/05
Page 7 of 23.
Basically, installation does three things: Copies the DLL file: If you're doing a non-global install, the Assemblies are copied to the \bin directory of the IIS virtual server (Web site). If there's an associated PDB debug file, it is copied to the \bin directory too. If you're installing globally, then the DLL files are registered in the GAC rather than copied to the \bin directory. Register the Web Part as a safe control: If there are safe control entries in the assembly tags of the manifest.xml file they are added to the web.config. These will contain the assembly's strong name, if there is one. The DWP files are copied to the \wpcatalog directory. If the DWP references an assembly with a strong name, the DWP file will be renamed to the name of the assembly with an underscore followed by the version number, followed by another underscore, followed by the public key token, followed by yet another underscore, and finally the original DWP name.
Note that the safe controls in the web.config file are updated. This in turn, will reset ASP.NET worker process because it is designed to reset when the web.config file is changed. You'll need to be careful about installing Web parts while the system is in use.
How do I manually install the Web Part? Web Part usually ship with an installation file (.msi) and a CAB file. To manually install the Web Part onto the server, use the following steps: 1. 2. CAB file should contain the assembly DLL, DWP file(s), Manifest.XML and Resource files (if needed) Install with the STSADM.EXE utility (Located in [drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN):
Stsadm -o addwppack -filename <path to Web Part Package> [-url <URL>] [-globalinstall]
o o o
filename specifies the path to the cabinet file containing the Web Parts and associated resources. url optionally specifies the URL of the virtual server on which to install the Web Parts. To install the Web Parts on every virtual server on a server, omit the -url parameter. globalinstall tells Stsadm.exe to install the Web Parts in the global assembly cache (GAC) rather than in the Bin directories of each virtual server.
You can also unpack the content of the CAB file and manually install using the following method: 1. Copy assembly DLL to either: o o 2. 3. /bin directory for a given IIS virtual server (e.g.,[drive]:\inetpub\wwwroot\bin) Global Assembly Cache (e.g.,[drive]:\windows\assembly)
Copy DWP file to [drive]:\Inetpub\wwwroot\wpcatalog Copy resources to: o o For GAC-registered parts, [drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\wpresources For Web Parts in the \bin directory, [drive]:\Inetpub\wwwroot\wpresources
4.
Adjust the web.config file: o o Register as SafeControl Select Code Access Security settings
The manifest.xml is the most interesting file in the CAB since STSADM uses the content to set up the Web Part. Here is an example:
<?xml version="1.0"?>  
12/09/05
Page 8 of 23.
<WebPartManifest xmlns="http://schemas.microsoft.com/WebPart/v2/Manifest"> <Assemblies> <Assembly FileName="Bamboo.SqlView.WebPart.dll">   <ClassResources> <ClassResource FileName="Bamboo.View.ascx"/> </ClassResources> <SafeControls> <SafeControl Namespace="Bamboo.SqlView.WebPart" TypeName="*" /> </SafeControls> </Assembly> </Assemblies> <DwpFiles> <DwpFile FileName="Bamboo.View.dwp"/> </DwpFiles> </WebPartManifest>
The first section of the CAB file, which falls under the <Assemblies> tag, contains the DLLs, supporting files, and configuration entries that are made by STSADM. The second section, DWP Files, falls under the <DwpFiles> tag and contains all of the DWP files for the package. DWP files are what the user sees when adding a Web Part to the site. They contain the title to display, the description for the hover text, the assembly to load and what the properties are that should be loaded into the Web Part. They are the configuration part of a Web Part, whereas the assembly is the code that is running. Here is an example:
<?xml version="1.0" encoding="utf-8"?> <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" > <Title>Bamboo SQL View Web Part</Title> <Description>Quickly generate a SQL Statement or database view for SharePoint list data to use with popular reporting applications, such as Microsoft Access or Crystal Reports. </Description> <Assembly>Bamboo.SqlView.WebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=57781735432e690a</Assembly> <TypeName>Bamboo.SqlView.WebPart.ViewWebPart</TypeName>  </WebPart>
The <Assembly> tag (which might be grouped under <Assemblies> when the Web Part has more than one assembly) has a FileName attribute that defines the name of the assembly being described. Web Parts assembly also have a <SafeControl> tag that has an attribute for Namespace and TypeName. The Namespace is the namespace that the type belongs in and the TypeName is the specific name of the type in the namespace to make safe (or a * to indicate that all types in the specified Namespace are good). These <SafeControl> tags are used to create the appropriate entries in the web.config file. The attribute <TypeName> just describes the fully qualified name of the Web Part type including the namespace.
So I heard the term virtual server tossed around quite a lot here. What does it really mean? SharePoint is an application that runs on top of ASP.Net, and a SP site configuration starts at the level of the IIS Web Site. When you install a default SP site, an IIS Web Site is created and is named Default Web Site that is configured to listen for incoming HTTP requests across port 80. So basically SP calls an IIS Web Site as a virtual server. Obviously, the reason for a new name is because its not just an ASP.Net web site. A virtual server must be extended with SP in order to run as a SP site.
12/09/05
Page 9 of 23.
There are several other things that happen when you create a SP virtual server that are helpful to understand when dealing with the Web Part installation Unlike the standard ASP.NET application, SP doesn't configure each Web site using an IIS virtual directory. Instead, SP tracks all configuration information for SP sites inside the configuration database and content databases. This means that once WSS has extended a virtual server, your SP sites do not appear in IIS. This architecture allows SP to benefit in scalability and improved maintenance of its sites. When you create a virtual server, SP adds a web.config file to the root directory of the hosting virtual server. This web.config file provides initial configuration settings for SP and for all Web Part code that runs from inside that virtual server. By default, this web.config file contains WSS_minimal permission, which is a fairly restrictive security setting. You will be required to modify sections of this web.config file when you want your code to run with higher permissions.
So, a virtual server is a way of breaking up the Web server structure, giving you finer control over settings for particular groups of Web sites. So, rather than configuring a setting for an entire server, you can configure it for just a virtual server. You can also configure authentication on a virtual server basis, so that different virtual servers can use different authentication methods. This is a typical scenario for setting up a SP site that is accessible from an intranet (integrated windows authentication) and extranet (basic authentication) environment. This is also possible since SP allows you to extend a virtual server so that it attaches to the same content database used by another virtual server. Each virtual server can also be configured using an IIS Application Pool to run its SP Web sites in an isolated process, thus protected from other virtual servers. You will most likely use several different ways that virtual servers are created on a server (or farm): IP-bound virtual servers: This is probably the most typical situation. In this case, you will create each IIS web site with a different IP address, and extend each of those IIS web sites into a SP virtual server. Note that this configuration needs Service Pack 2 to be installed on your server, see details at the end of this section. Single IP with multiple host headers virtual servers: This is the easiest and most straight forward for end users. This method allows you to create multiple host headers (which are essentially a DNS alias) that point to the same IP address, thus allow you to have multiple virtual servers. Warning: (1) You must install Service Pack 2 if host header is to be used with SSL. This is due to the fact that IIS can not read the encrypted header containing the host name on an SSL package, thus IIS will not be able to forward the requests to the correct virtual server. (2) When you configure an IIS virtual server, extended by using Windows SharePoint Services that has a host header name, you must install Web Part assemblies in the GAC. Single IP with multiple port virtual servers: This is the same as the previous method, except you would assign a different virtual server to operate on a specific TCP/IP port. Unfortunately, users will have to supply the port name to their URL (http://myPortal:88). You will also have to supply the correct port number when installing a Web Part into a virtual server that is configured in this fashion.
Figure 1. Example of multiple virtual server using single-ip-multiple-ports and ip-bound
Service Pack 2 Note: Support for IP-Bound Virtual Servers Previous releases of SharePoint Portal Server did not support assigning static IP addresses to IIS virtual servers extended with SharePoint Portal Server. Instead, it was required that you use host headers and configure all virtual servers with an IP address setting of All Unassigned. This limitation, as described in
12/09/05
Page 10 of 23.
Knowledge Base article KB 830342: "Soap:Server Exception of Type Microsoft.SharePoint.SoapServer.SoapServerException", prevented the ability to host multiple virtual servers with Secure Sockets Layer (SSL) on one Web server. In Office SharePoint Portal Server 2003 SP2, this limitation has been removed, and SharePoint Portal Server now supports assigning a static IP address to a virtual server that has been extended with SharePoint Portal Server. More detailed information is available here: Administrator Guide for WSS.
I have multiple virtual servers on my machine, and I cant seem to install the Web Part on one of my virtual servers? Virtual servers can be created in SharePoint in a few different ways. When you install the Web Part into a SharePoint server that contains multiple virtual servers, you need to be aware of how it was configured. See the last FAQ item for more information. Basically, you will most likely run into one of the following situations: You are using one IP address for all virtual servers with different port number. In this case you have to specify http://myPortal:port when referring to the virtual server. If you are using host headers, then the Web Part must be installed in the GAC.
Is there anything I can do to check and make sure my Web Part is installed and behaves correctly on my server? After installing your Web Part, we strongly recommend that you run the SharePoint Configuration Analyzer. SCA is a tool that you can download from the Microsoft Download Center to analyze and report on your SharePoint Services installation and content. SharePoint Configuration Analyzer reports on a wide range of configuration errors and also copies a set of log files, configuration files, and other data to a results folder for further analysis or archiving. It is very useful for Web Part analyzing since it also reports on Web Part usage on your server and retrieves a set of log files, configuration files, and Web Part packages used by Windows SharePoint Services and Internet Information Services (IIS).
Figure 2. SharePoint Configuration Analyzer
12/09/05
Page 11 of 23.
SharePoint Configuration Analyzer verifies the following and reports any errors it finds. Web Part and Web Control assemblies are installed in a way that is compatible with IIS. Web Part and Web Control assemblies listed in the SafeControls list exist. Web Part instances on pages are associated with Web Part assemblies. Policy files listed in web.config files exist.
In addition to verifying the above information, SharePoint Configuration Analyzer can retrieve the following: All security policy files that are referred to from the root web.config file. All IIS and Windows SharePoint Services log files. List of all Web Parts and Web Controls listed in the SafeControls list. For each Web Part type found in the database, a list of the pages that contain an instance of that Web Part. List of all Web Part packages installed in the Global Assembly Cache (GAC) and \bin directories. List of all files contained within the main application root.
More information on the SCA can be found on MSDN site here.
What does strong name mean when referring to a Web Part? In order for a Web Part to run in a SharePoint site, it needs to have a strong name, which informs SharePoint that the Web Part can be trusted. A strong name consists of the assembly's identity, a public key, and a digital signature and can be assigned to a Web Part assembly using the strong name tool (sn.exe). The public key generated by the strong name tool is specified when registering a Web Part as a safe control.
<Assembly> Bamboo.SqlView.WebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=57781735432e690a </Assembly>
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 the file and make changes to the copy to ensure that you can reuse the original file if necessary. The following procedure, which we borrow from a Microsoft article, describes how to give access to the Microsoft SharePoint object model to a specific assembly by adding the specific SharePoint object model permission to a new policy file: 1. Copy the wss_minimaltrust.config file (or wss_mediumtrust.config, much less work). These files are in [local_drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\60\config. Rename the file wss_customtrust.config. Using a text editor such as Notepad, open wss_customtrust.config. Under the <SecurityClasses> element, add a reference to the SharePointPermission class as follows: Syntax:
<SecurityClasses> Name="<Name of the class that implement the security permission>" Description=<"Description of the security class> </SecurityClasses>
2. 3. 4.
Example (Before)
<SecurityClasses>  <SecurityClass Name="SharePointPermission" Description="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
12/09/05
Page 12 of 23.
</SecurityClasses>
5.
Locate the <NamedPermissionSets> element and create a new permission set by specifying a PermissionSet element and an IPermission element. This new permission set should grant you all the rights you need to have for the new policy, including permission to access SharePoint object model. One simple way to do this is to search for the <PermissionSet> 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 BambooCustomTrust (for this example, you should use your own desired name). Now you should have a new permission set based on the ASP.NET set. Syntax
<PermissionSet class="NamedPermissionSet" version="<version of the permission set>" Name="<friendly name"> Description="<description of the permission set"> <IPermission class ="<class name of the permission set>" version="<version number"> <permission name>="<value"> </PermissionSet>
6. 7.
Example (Before)
<PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net">  </PermissionSet>
Example (After)
<PermissionSet class="NamedPermissionSet" version="1"Name=" ASP.Net">  </PermissionSet> <PermissionSet class="NamedPermissionSet" version="1"Name="BambooCustomTrust">  </PermissionSet>
8.
Add the following <IPermission> node to the<PermissionSet> element where the name attribute equals BambooCustomTrust:
<PermissionSet class="NamedPermissionSet" version="1" Name="BambooCustomTrust"> <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" /> <IPermission class="SecurityPermission" version="1" Flags="Execution"/> <IPermission class="WebPartPermission" version="1" Connections="True"/> <IPermission class="SharePointPermission" version="1" ObjectModel="True"/> </PermissionSet>
The AspNetHostingPermission class contains the base to create the new permission set, and adding the <PermissionSet> element allows this class to access the SharePoint object model. 9. Once you define the customized element, you must create a code group to specify when the CLR should apply the permission set.
10. Remember that by default, the root 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. In other words, you must create the new code group as the first child code group of the root code 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 the BIN directory. In the following example, add the following section right after the FirstMatchCodeGroup. The membership condition for the new code group is based on strong name membership: Syntax
<CodeGroup
12/09/05
Page 13 of 23.
class="Assembly that implement the code group" version="<version number>" PermissionSetName="<name of permission set>" <IMembershipCondition class="<Assembly that implements the membership condition>" version="<version number>" PublicKeyBlob="public key Name="AssemblyName" /> </CodeGroup>
Example
 <CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Nothing"> <IMembershipCondition class="AllMembershipCondition" version="1" /> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="BambooCustomTrust"> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob= 0024000004800000940000000602..86A9CEBD87D94D1D3" Name=" Bamboo.SqlView.WebPart" /> </CodeGroup>
11. Note: The public key blob for our Web Part assemblies are listed in their respective Application Notes. To retrieve the public key blob for an assembly, use the secutil.exe tool as follows:
C:\>secutil.exe -hex -s MyAssemblyName.dll
Microsoft (R) .NET Framework SecUtil 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All rights reserved. Public Key = 0x002400000480000094000000060200000024000052534131000400000100010097A0C9008F6E62 2DC645EE0AD5D080B05E6A7E254D4917C3F8B29F034111A344632530BC4BD58113AB74FC76711DD2 4F18205C24FF219F771B48954DC70C55631E79504A088BFECD5C3A8A73169513D02CA4638484E303 A8931EF2A203699B5563FCA43960801E6062801AB9E41ECFDF156748022747E9086A9CEBD87D94D1D3 Name = Bamboo.SqlView.WebPart Version = 1.0.0.0 Success
C:\>
This program comes with Visual Studio, usually in C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin. The easiest way to run secutil is under the Visual Studio .Net command prompt, the change the directory to where the assembly file is, and run the secutil command as specified above. For more information about secutil.exe, see Secutil Tool. Alternatively, you can also use the ildasm.exe. Use the File, Open from the menu to select the assembly. A tree appears with a tree node called "MANIFEST". Double-click this node and the manifest of the assembly is shown. Scrolling down you will find something like:
.assembly Bamboo.SharePoint.WebParts.Welcome { // lot of custom instance void rows .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00 B3 DB 7C A6 EE 5B 69 D2 23 E7 88 5A 13 66 03 91 41 8F 80 9B 6C 34 C5 30 5A 6B 0F F1 BA B6 55 FE 92 A5 78 2E E3 43 42 37 02 F0 38 1A D4 88 72 4C DE 31 CC B2 99 D1 33 74 A8 D2 DC AB 47 D3 32 3E
12/09/05
Page 14 of 23.
C6 E9 7C 97 7D FD 8F 79 E8 39 58 24 2E 41 A6 68 A8 0D AD EB 0B 99 07 70 A5 D4 DA 53 7A 92 2F B4 2E 79 56 7D 05 56 4F 10 63 5F E1 D4 0F 4A 38 C1 B4 D0 19 79 8C 00 08 DD 1E 95 2B DC 5D 95 19 B8 ) }
Copy the contents of the .publickey and remove all spaces between the hexadecimal figures. 12. Save and close the file. The policy file is ready to use. This wss_customtrust.config file associates the BambooCustomTrust permission set with the Bamboo.SqlView.WebPart.dll, thus allowing this Web Part to access the WSS object model. 13. The next step is to tell ASP.NET where to find the custom policy file: o Open the web.config (usually default at [drive]:\inetpub\wwwroot) file for the virtual server extended with Windows SharePoint Services and add the following <trustLevel> tag to the SecurityPolicy element:
<trustLevel name="BambooCustomTrustLevel" policyFile="wss_customtrust.config" />
In the web.config file, change the <trust> tag so that it refers to the newly defined trust level.
<trust level=" BambooCustomTrustLevel" originUrl="" />
14. Save and close the web.config file. 15. Reset IIS, such as by using IISRESET, to apply the custom policy to the specified virtual server.
I created a custom policy file using the example above, but I cant get it to work. What am I doing wrong? There are several common mistakes when you create a custom policy file, centered around (a) your CodeGroup is not matching the assembly or (b) another CodeGroup in front of yours is matching first. Your CodeGroup is not matching the assembly, double-check the following: 1. 2. 3. 4. StrongNameMembershipCondition: don't include the hex notation prefix ("0x") in the PublicKeyBlob. StrongNameMembershipCondition: the Name property should be the Web Part AssemblyName not the file name (i.e. "MyWebPart" vs. "MyWebPart.dll"). MembershipCondition: Check the path and/or URL. Open the file in an XML editor instead of Notepad to see if there are errors in the XML code.
For a better understanding of how policy files work, please refer to the next few FAQ sections. You can also get a more positive experience when starting your custom policy file from the wss_mediumtrust.config and removing permissions, instead of starting from wss_minimumtrust.config.
What if my Web Part assembly is not strong name? How can I add it to a code group? You can specify membership conditions for a code group in several ways. For example, you can use the UrlMembershipCondition this way:
<IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/bin/MyWebPartName.dll" />
Help, Im looking at a policy file and Im really confused! By setting up a custom policy file, what you are basically doing is giving your Web Part assembly the appropriate permissions to execute and access resources in your environment. The SharePoint security policy file is based on ASP.NET and is configured by you as the system administrator. Policy can be established at four levels:
12/09/05
Page 15 of 23.
Enterprise. The enterprise security policy applies to all machines in an Active Directory deployment. Machine. The machine security policy applies to all users on a specific machine. User. The user security policy is specific to an individual user on a specific machine. Application Domain. Used to configure the application domain into which an assembly is loaded.
ASP.NET, and thus SharePoint relies on the application domain level policy file, and has three main elements: the code groups, their associated permission sets and the security classes. Figure 2 shows the basic structure and elements that comprise a policy file.
Figure 3. Security Policy file structure
Code Groups Code Groups are containers for Permissions that a Web Part can have based on the Evidence, which are the XML elements within the policy configuration file. An assembly belongs to a Code Group based on the Membership Condition, which reflects the evidence that has been collected or provided to a policy evaluator while assembly was loading. Evidence is used by the .NET Framework security system to identify assemblies. Code access security policy uses evidence to help grant the right permissions to the right assembly. There are 7 default evidence types which has a one-to-one relationship to Membership Condition element of Code Group, plus one Allcode condition that maps all of the code. This tree consists of a root code group that may have child code groups, which in turn may have their own child code groups.
Table 1. Code Group Membership Attributes
File name
Allcode URL Site Application directory Zone Strong name Publisher
Purpose
Set to True to access the SharePoint object model. The URL that the assembly was obtained from. This is the codebase URL in its raw form, for example, http://webserver/vdir/bin/assembly.dll or file://C:/directory1/directory2/assembly.dll The site the assembly was obtained from, for example, http://webserver. The site is derived from the codebase URL. The base directory for the running application. The zone the assembly was obtained from, for example, LocalIntranet or Internet. The zone is also derived from the codebase URL. This applies to assemblies with a strong name. Strong names are one way to digitally sign an assembly using a private key. The Authenticode signature; based on the X.509 certificate used to sign code, representing the development organization. Note: Publisher evidence (the Authenticode signature) is ignored by the ASP.NET host and therefore cannot be used to configure code access security policy for server-side Web applications. This evidence is primarily used by the Internet Explorer host. The assembly hash is based on the overall content of the assembly and allows you to detect a particular compilation of a piece of code, independent of version number. This is useful for detecting when third party assemblies change (without an updated version number) and you have not tested and authorized their use for your build.
Hash
A code group is assigned a specific membership condition that defines the criteria an assembly must meet in order to assign to that code group. Table 2 lists the IMembershipCondition classes used by SharePoint.
MembershipCondition AllMembershipCondition StrongNameMembershipCondition Table 2. SharePoint Membership Condition Description Represents a membership condition that matches all code. Determines whether an assembly belongs to a code group by testing its strong name.
12/09/05
Page 16 of 23.
UrlMembershipCondition
ZoneMembershipCondition
Determines whether an assembly belongs to a code group by testing its URL. The complete URL is considered, including the protocol (HTTP, HTTPS, FTP) and the file. For example, http://www.name.com/site/page.htm is a complete URL. URLs can be matched exactly or by a wildcard in the final position. For example, http://www.name.com/site/* is a wildcard URL. Determines whether an assembly belongs to a code group by testing its zone of origin.
Examples:
<IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/bin/Bamboo.WebPart.dll" /> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="000111...222111" Name="MyAssemblyName" />
So how does the security police (CLR in this case) match a Web Part assembly with the right code group? It is easiest to think of this as an organization chart, with each node in the policy level representing a membership condition and a pointer to a permission set. The hierarchy structure allows multiple permission sets to be assigned to an assembly, with simple AND and OR logic. Each code group is either a type of FirstMatchCodeGroup or a UnionCodeGroup. When traversing the tree, CLR compares the assembly's evidence against the code group's membership condition. If a match is found, and: 1. If the code group is of the FirstMatchCodeGroup type, the membership condition of each child code group is tested until the first match occurs. So, the result of the FirstMatchCodeGroup is ultimately the union of the policy statement of the root code group and the policy statement of the first child code group matched. If a match is made on the membership condition of a UnionCodeGroup, then the policy statement of the parent root code group combines with the policy statement of the matching child code group, including any matches that are made with its child code groups. The UnionCodeGroup is the most common type of code group, and it is a child code group of the root code group.
2.
For example, consider the sample security policy shown:
Figure 4. Code Groups Hierarchy
1.
Any assembly originating from the MyComputerZone (any locally installed assembly), is granted the permissions defined by the FullTrust permission set. This is a built-in permission set defined when the .NET Framework is installed and represents the unrestricted set of all permissions. Assemblies authored by Bamboo and originating from the intranet zone are granted the permissions defined by the built-in LocalIntranet permission set AND the custom BambooPolicy permission set. Any assembly downloaded from store.com is granted permissions defined by the custom StorePolicy permission set
2.
3.
12/09/05
Page 17 of 23.
Note: If the membership condition for a particular code group is not satisfied, none of its children are evaluated, so if you install the Bamboo Web Part in MyComputer zone, it will not use the same policy as the one in the IntranetZone and thus might not have the same permission set. The AllCode code group is a special code group that matches all assemblies. It forms the root of security policy and in itself grants no permissions, because it is associated with the permission set named Nothing. The following is an example of the wss_minimal code group; see if you can find out why any Web Parts from Microsoft always can be run with minimum trust level, and why any Web Part in GAC is fully trusted.
<CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Nothing"> <IMembershipCondition class="AllMembershipCondition" version="1" /> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="ASP.Net"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/*" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$CodeGen$/*" </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust"> <IMembershipCondition class="UrlMembershipCondition" Url="$Gac$/*" version="1" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="Nothing"> <IMembershipCondition class="ZoneMembershipCondition" version="1" Zone="MyComputer" /> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Microsoft_Strong_Name" Description="This code group grants code signed with the Microsoft strong name full trust "> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="0024 remove for clarity AD293" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Ecma_Strong_Name" Description="This code group grants code signed with the ECMA strong name full trust. "> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="00000000000000000400000000000000" /> </CodeGroup> </CodeGroup> </CodeGroup> />
Permission Sets A Permission Set, <NamedPermissionSets> element, is a set of permissions that can be granted to the code. The <NamedPermissionSets> element contains <PermissionSet> elements. Permissions represent the rights for your assembly code to access a secured resource or perform a privileged operation. The .NET Framework provides code access permissions and code identity permissions. Code access permissions encapsulate the ability to access a particular resource or perform a privileged operation. Code identity permissions are used to restrict access to code, based on an aspect of the calling code's identity such as its strong name. Each <PermissionSet> element in turn may have a number of <IPermission> elements, which define the permission at its most basic level. The following list shows the Permission Set of the wss_minimal policy file:
<NamedPermissionSets> <PermissionSet class="NamedPermissionSet" version="1" Unrestricted="true" Name="FullTrust" Description="Allows full access to all resources" /> <PermissionSet class="NamedPermissionSet" version="1" Name="Nothing" Description="Denies all resources, including the right to execu /> <PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net"> <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" /> <IPermission class="SecurityPermission" version="1" Flags="Execution" /> <IPermission class="WebPartPermission" version="1" Connections="True" /> </PermissionSet> </NamedPermissionSets>
In this example, the wss_minimal policy will have three <PermissionSet> elements nested within the <NamedPermissionSet> element: Full Trust, Nothing, and ASP.NET. Under the ASP.NET set, 3
12/09/05
Page 18 of 23.
<IPermission> elements are declared to allow access to the SharePoint Web Part connection, allow code to run, and allow access permissions in ASP.NET hosted environments. All permissions implement the class and version attributes. The class attribute references the class and assembly that implement the custom permission.
<PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net"> <IPermission class="AspNetHostingPermission" version="1" Level="Medium" /> <IPermission class="DnsPermission" version="1" Unrestricted="true" /> <IPermission class="EnvironmentPermission" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME" /> <IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" /> <IPermission class="IsolatedStorageFilePermission" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807" /> <IPermission class="PrintingPermission" version="1" Level="DefaultPrinting" /> <IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration" /> <IPermission class="SharePointPermission" version="1" ObjectModel="True" /> <IPermission class="SqlClientPermission" version="1" Unrestricted="true" /> <IPermission class="WebPartPermission" version="1" Connections="True" /> <IPermission class="WebPermission" version="1"> <ConnectAccess> <URI uri="$OriginHost$"/> </ConnectAccess> </IPermission> </PermissionSet>
And the wss_medium policy has quite a few more permissions elements as you can see in the above listing. An excellent way of trying to learn and verify the permission is to use the .Net Configurator 1.1 utility (should be listed in your Program-Administrator group). Run this utility, expand the Run Time Security ->Machine->Permission Set node, and add a new test permission set, you will see all the available permissions for ASP.NET 1.1 security permission.
Here is an example of how to give an assembly a specific permission to c:\temp directory in the File I/O permission:
12/09/05
Page 19 of 23.
If you experiment with the .Net Configuration program, you will notice two things: You can not modify the 7 pre-defined Permission Sets of ASP.NET: Nothing, Execution, Skip Verification, Internet, Local Intranet, FullTrust. Only Everything set can be modified. The second thing is that this program does not know about the additional SharePoint security permissions. Since the policy files defined by SharePoint are based on the default policy files defined by ASP.NET, they address many of the same permissions and add the two SharePoint-specific permissions: SharePointPermission and WebPartPermission. This next table shows the permission settings for the WSS_Minimal and WSS_Medium trust levels, respectively.
Permission AspNetHostingPermission Environment FileIOPermission IsolatedStorage Reflection Registry Security Socket WebPermission DNS Printing OleDBPermission SqlClientPermission EventLog Message Queue Service Controller Performance Counters Directory Service SingleSignonPermission SharePointPermission WebPartPermission Full Full Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted Unrestricted WSS_Medium Medium Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME Read, Write, Append, PathDiscovery:Application Directory AssemblyIsolationByUser, UserQuota specified WSS_Minimal Minimal
Flags=Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration Connect to origin host (if configured) Unrestricted=TRUE or all subpermissions granted Level=Default printing Unrestricted=true or all subpermissions granted
Execution
Access=True (Note: SPS Only) ObjectModel=True Connections =True
Connections=True
Notice that the FileIOPerrnission and WebPermission defined for the contain substitution parameters ($AppDir$, $OriginHost$). These parameters allow you to configure permissions to the assemblies that make up your Web application but reside in different locations. Each substitution parameter is replaced with an actual value the first time your Web application assembly is loaded. The $AppDir$ parameter represents the root application directory for a given application. The $OriginHost$ parameter is replaced by the OriginUrl attribute defined in the <trust> element of the web.config file.
Table 3. SharePoint Permission Attributes File name Purpose SharePointPermission ObjectModel Set to True to access the SharePoint object model SharePointPermission UnsafeSaveOnGet Set to True to save data on HTTP-GET requests SharepointPermission Unrestricted Set to True to enable all rights associated with this permission WebPartPermission Connections Set to True to participate in Web Part-to-Web Part communications
12/09/05
Page 20 of 23.
WebpartPermission Unrestricted
Set to True to enable all rights associated with this permission
Security Classes The <SecurityClasses> element defines the individual <SecurityClass> elements required to handle specific security permissions. Essentially, the <SecurityClass> element identifies what an assembly uses in its program. The attributes in the <SecurityClass> element specify the assembly, version, culture, and public key token. Here is an example that shows the SharePoint specific <SecurityClass> elements as defined in the WSS_Mediurn policy file.
<SecurityClasses> <SecurityClass Name="SharepointPemission Description=Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version =11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c /> <SecurityClass Name=WebPartPermission Description=Microsoft.SharePoint.Security.WebPartPermission, Microsoft.SharePoint.Securit, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c /> </SecurityClasses>
The SharePointPermission security class provides access to the SharePoint object model, and the WebPartPermission security class provides the ability to create Web Part connections. The WSS_Minimal policy file does not include the SharePointPermission security class, which means that Web Parts running under WSS_Minimal cannot access the SharePoint object model.
How is my policy file being evaluated? In a very simplified view, when you access a SharePoint site that has an embedded Web Part, the following steps are being performed to evaluate the permission before the Web Part is allowed to run:
Figure 5. Simplified view of policy evaluation process
1. 2.
The assembly is loaded. This operation is performed by the ASP.NET host. Evidence is gathered from the assembly and presented by the host.
12/09/05
Page 21 of 23.
3. 4. 5.
Evidence is evaluated against the defined security policy as specified in your virtual servers web.config file, which are pointed to the policy file in [drive]: \Program Files\ Common Files \Microsoft Shared \Web Server Extensions\ 60\ config\ xx.config The output from security policy evaluation is one or more named permission sets that define the permission grant for the assembly. Note: An assembly can include permission requests, which can further reduce the permission grant. If the assembly (and its callers) has been granted the demanded permission, the operation is allowed to proceed. Otherwise, a security exception is generated.
One of the important things to remember is that when evidence is run through the policy engine, the output is a permission set that defines the set of permissions granted to an assembly. The policy grant is calculated at each level in the policy hierarchy: Enterprise, Machine, User, and Application Domain. The policy grant resulting from each level is then combined using an intersection operation to yield the final policy grant. An intersection is used to ensure that policy lower down in the hierarchy cannot add permissions that were not granted by a higher level. This is why sometimes you will see a security exception thrown even when your Web Part is loaded in the GAC (where you assume that it is running at full trust). This Web Part might use other assemblies that loaded in partially trusted folders such as ..\bin.
Enterprise Machine User SharePoint
Printing=True Printing=True Printing=True Printing=True
SQLClient=True SQLClient=True SQLClient=True SQLClient=False
DirectoryServ=True DirectoryServ=False DirectoryServ=True DirectoryServ=True
TRUE
False
False
In the above figure, you can see that the intersection operation ensures that only those permissions granted by each level form part of the final permission grant. In this example, only the Printing permission is allowed throughout all the policy levels.
Why are some Web Parts showing up in the Virtual Server Gallery and some in other galleries? A Web Part Page Gallery, also referred to as a Web Part Library, is a central location from which users can retrieve Web Parts and add them to the Web Part Pages in their SharePoint site. Web Parts deployed to the galleries must be registered as safe controls in order to be successfully loaded onto a Web Part Page. Out of the box, SharePoint supports four types of Web Part Galleries: 1. Virtual Server Gallery: The Virtual Server Gallery lists the Web Parts that are available to all the sites on the server. Web Part Packages can be deployed to the Virtual Server Gallery using the stsadm.exe tool. 2. Site Gallery: The Web Parts that appear in the Site Gallery are available to a specific top-level site and all its sub sites and are also referred to as a site collection. The name of the Site Gallery matches the top level site. For example, the name for the Site Gallery of a site named "MyCompany" is " MyCompany Site Gallery". A number of default Web Parts appear in the Site Gallery upon creation depending on the site template applied. For example, the Team Site template contains a Content Editor Web Part, an Image Web Part, a Members Web Part, a Page Viewer Web Part, a Simple Form Web Part, and an XML Web Part. In addition, there will also be Web Parts representing each list or document library in the site (Announcements, Events, Shared Documents, etc.). The site administrator controls the Web Parts that appear in the Site Gallery and can easily add or remove Web Parts using the Manage Web Part Gallery site-administration page. 3. Online Gallery: By default, the Online Gallery maps to a site that contains Web Parts provided by Microsoft. Currently, this site contains several MSNBC Web Parts that display stock, news, and weather information. If the Online Gallery does not appear in your list of Web Part Galleries, check details on this issue and how to resolve it can be found in Microsoft Knowledge Base Article 823375. If you would prefer that this gallery point to a custom online Web Part Gallery, you can easily redirect the default location to your location of preference. Simply replace the URL referenced in the <OnlineLibrary> element of the web.config file with a URL that points to your custom online Web Part Gallery. 4. Web Part Page Gallery: The Web Part Page Gallery contains Web Parts that have been added to the current Web Part Page but are not currently visible.
12/09/05
Page 22 of 23.
References
Some contents in this article are from the following sources on the web: MSDN Article: Microsoft Windows SharePoint Services and Code Access Security MSDN Article: Code Access Security: WebPermission MSDN Book on ASP.NET security: Chapter 8: Code Access Security in Practice MSDN Book: Chapter 9: Using Code Access Security with ASP.NET MSDN Article: Using Wppackager to Package and Deploy Web Parts for Microsoft SharePoint Products and Technologies Additional information about CAS from these SharePoint experts: Jan Tielens' SharePoint, Code Access Security and the SmartPart, Maxim V. Karpovs Code Access Security (CAS) and Design Patterns Article on TheCodeProject, Maurice Prathers Why is Code Access Security important?
Copyright Notice This document is provided for informational purposes only and Bamboo Solutions makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Bamboo Solutions Corporation. Bamboo Solutions may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Bamboo Solutions, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Published work 2005 Bamboo Solutions Corporation. All rights reserved. Bamboo Solutions, WD3, are registered trademarks of Bamboo Solutions Corporation. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
12/09/05
Page 23 of 23.

Sharepoint Faq

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sharepoint Faq

Hochgeladen von

Copyright:

Verfügbare Formate

SharePoint Web Part Deployment & Security

A Bamboo Solutions FAQ Version 1.0

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Frequently Asked Questions (FAQ)

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Install your assemblies in the GAC

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

I received this warning message after installing the Web Part?

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Figure 1. Example of multiple virtual server using single-ip-multiple-ports and ip-bound

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Figure 2. SharePoint Configuration Analyzer

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

More information on the SCA can be found on MSDN site here.

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

<trust level=" BambooCustomTrustLevel" originUrl="" />

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Figure 3. Security Policy file structure

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

For example, consider the sample security policy shown:

Figure 4. Code Groups Hierarchy

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Access=True (Note: SPS Only) ObjectModel=True Connections =True

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Set to True to enable all rights associated with this permission

Figure 5. Simplified view of policy evaluation process

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0

Enterprise Machine User SharePoint

Printing=True Printing=True Printing=True Printing=True

SQLClient=True SQLClient=True SQLClient=True SQLClient=False

DirectoryServ=True DirectoryServ=False DirectoryServ=True DirectoryServ=True

Bamboo Solutions FAQ

SharePoint Web Part Deployment & Security FAQ V1.0