Upravit

Sdílet prostřednictvím

Code access security in Reporting Services

  • Článek

Code access security centers on these core concepts: evidence, code groups, and named permission sets. In Reporting Services, the Report Manager, Report Designer, and Report Server components each have a policy file that configures code access security for custom assemblies. This policy file also configures code access for data, delivery, rendering, and security extensions. The following sections provide an overview of code access security. For more detailed information about the articles covered in this section, see "Security Policy Model" in the Microsoft .NET Framework SDK documentation.

Reporting Services uses code access security because, although the report server is built on ASP.NET technology, there's a substantial difference between a typical ASP.NET application and the report server. A typical ASP.NET application doesn't execute user code. In contrast, Reporting Services uses an open and extensible architecture that allows users to program against the report definition files using the Code element of the Report Definition Language and to develop specialized functionality into a custom assembly for use in reports. Furthermore, developers can design and deploy powerful extensions that enhance the capabilities of the report server. This power and flexibility comes with the need to provide as much protection and security as possible.

Reporting Services developers can use any .NET Framework assembly in their reports and natively call upon all of the functionality of assemblies deployed to the global assembly cache. The only thing that the report server can control is what permissions are given for report expressions and loaded custom assemblies. In Reporting Services, custom assemblies receive Execute-only permissions by default.

Evidence

Evidence is the information that the common language runtime (CLR) uses to determine a security policy for code assemblies. Evidence indicates to the runtime that code has a particular characteristic. Common forms of evidence include digital signatures and the location of an assembly. Evidence can also be custom designed to represent other information that is meaningful to the application.

Both assemblies and application domains receive permissions based on evidence. For example, the location of an assembly that Reporting Services is attempting to access is one common form of evidence for weak-named assemblies. This example is known as URL evidence. URL evidence for a custom data processing extension deployed to a report server might be C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll. The strong name or digital signature of an assembly is another common form of evidence. In this case, the evidence is the public key information for an assembly.

Code groups

A code group is a logical grouping of code that has a specified condition for membership. Any code that meets the membership condition is included in the group. Administrators configure a security policy by managing code groups and their associated permission sets.

A membership condition for a code group is based on evidence. For example, a URL membership for a code group is based on URL evidence. The common language runtime (CLR) uses identifying characteristics such as URL evidence to describe the code and to determine whether a group's membership condition has been met. For example, if the membership condition of a code group is "code in the assembly C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll", the runtime examines the evidence to determine whether the code originates from that location. An example of a configuration entry for this type of code group might look like the following example:

<CodeGroup class="UnionCodeGroup"  
   version="1"  
   PermissionSetName="FullTrust"  
   Name="MyCodeGroup"  
   Description="Code group for my data processing extension">  
      <IMembershipCondition class="UrlMembershipCondition"  
         version="1"  
         Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll"  
       />  
</CodeGroup>

You should work with your system administrator or application deployment expert to determine the type of code access security and code groups that your custom assemblies or Reporting Services extensions require.

Named permission sets

A named permission set is a set of permissions that administrators can associate with a code group. Most named permission sets consist of at least one permission, a name, and description for the permission set. Administrators can use named permission sets to establish or modify the security policy for code groups. More than one code group can be associated with the same named permission set. The CLR provides built-in named permission sets like Nothing, Execution, Internet, LocalIntranet, Everything, and FullTrust.

Note

Custom data, delivery, rendering, and security extensions in Reporting Services must run under the FullTrust permission set. Work with your system administrator to add the appropriate code group and membership conditions for your Reporting Services extensions.

You can associate your own custom levels of permissions for custom assemblies that you use with reports. For example, if you want to allow an assembly to access a specific file, you can create a new named permission set with specific file I/O access and then assign the permission set to your code group. The following permission set grants read-only access to the file MyFile.xml:

<PermissionSet class="NamedPermissionSet"  
   version="1"  
   Name="MyNewFilePermissionSet"  
   Description="A special permission set that grants read access to my file.">  
    <IPermission class="FileIOPermission"  
       version="1"  
       Read="C:\MyFile.xml"/>  
    <IPermission class="SecurityPermission"  
       version="1"  
       Flags="Assertion, Execution"/>  
</PermissionSet>

A code group that you grant this permission set might look like the following example:

<CodeGroup class="UnionCodeGroup"  
   version="1"  
   PermissionSetName="MyNewFilePermissionSet"  
   Name="MyNewCodeGroup"  
   Description="A special code group for my custom assembly.">  
   <IMembershipCondition class="UrlMembershipCondition"  
      version="1"  
      Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\MyCustomAssembly.dll"/>  
</CodeGroup>

Related content