Export (0) Print
Expand All
Creating Audit Tables, Invoking COM Objects, and More
Exception-handling Techniques
Exploring SQL Server Triggers: Part 2
Deliver User-Friendly Reports from Your Application with SQL Server Reporting Services
SQL Server: Display Your Data Your Way with Custom Renderers for Reporting Services
Updating Data in Linked Servers, Information Schema Views, and More
XML Features in SQL Server 2000
Expand Minimize

Code Access Security in SQL Server 2000 Reporting Services

SQL Server 2000
 

Bryan Keller
Microsoft Corporation

January 2004

Applies to:
   SQL Server 2000

Summary: This document outlines the new code access security policies of Microsoft® SQL Server™ 2000 Reporting Services. (15 printed pages)

Introducing Code Access Security in Reporting Services
Why Reporting Services Needs Code Access Security
Understanding Security Policies
Using Reporting Services Security Policy Files
Using Custom Assemblies with Reports
Conclusion

The Microsoft® .NET Framework provides a rich security system that can run code in tightly constrained, administrator-defined security contexts. The .NET Framework system that secures code is referred to as code access security (or evidence-based security). Under code access security, a user may be trusted to access a resource, but if the code the user executes is not trusted, access to the resource will be denied.

Security based on code, as opposed to specific users, permits security to be expressed for custom assemblies or data, delivery, rendering, and security extensions that you develop for Reporting Services. Your extension code may be executed by any number of users of Reporting Services, all of which are unknown at development time. The custom assemblies or extensions that you develop require specific security policies in Reporting Services. These security policies are represented as types in the .NET Framework. For a more complete understanding of code access security in the .NET Framework, see "Code Access Security" in the .NET Framework Software Development Kit (SDK), available in the MSDN Library.

Introducing Code Access Security in Reporting Services

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 as well as data, delivery, rendering, and security extensions. The following sections provide an overview of code access security in Reporting Services. For more detailed information about the topics covered in this section, see "Security Policy Model" in the .NET Framework SDK.

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 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\MSSQL\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\MSSQL\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:

<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\MSSQL\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 a 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; among these are 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:

<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\MSSQL\Reporting 
         Services\ReportServer\bin\MyCustomAssembly.dll"/>
</CodeGroup>

Why Reporting Services Needs Code Access Security

Why does Reporting Services use code access security, when doing so makes developing and deploying custom assemblies and extensions more laborious? Although the report server is built on ASP.NET technology, there is a substantial difference between a typical ASP.NET application and the report server. A typical ASP.NET application does not execute user code. In contrast, Reporting Services' open and extensible architecture allows users to be able to develop using the Code element of the report definition or to define specialized functionality into a custom assembly for use in reports. Furthermore, developers can design and deploy powerful extensions that enhance the capabilities of the server. With this power and flexibility comes the need to provide as much protection and security as possible.

Users of Reporting Services can use any .NET 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.

Understanding Security Policies

Any code that is executed by a report server must be part of a specific code access security policy. These security policies consist of code groups that map evidence to a set of named permission sets. Often, code groups are associated with a named permission set that specifies the allowable permissions for code in that group. The runtime uses evidence provided by a trusted host or by the loader to determine which code groups the code belongs to and, therefore, which permissions to grant the code. Reporting Services adheres to this security policy architecture as defined by the .NET Framework common language runtime (CLR). The following sections describe the various types of code in Reporting Services and the policy rules associated with them.

Report Server Assemblies

Report server assemblies are those that contain code that is part of the Reporting Services product. Reporting Services is written using managed code assemblies; all of these assemblies are strongly named (that is, digitally signed). The code groups for these assemblies are defined using the StrongNameMembershipCondition, which provides evidence based on public key information for the assembly's strong name. The code group is granted the FullTrust permission set.

Report Server Extensions (Rendering, Data, Delivery, and Security)

Report server extensions are custom data, delivery, rendering, and security extensions that you or other third-parties create in order to extend the functionality of Reporting Services. You must grant FullTrust to these extensions or assembly code in the policy configuration files associated with the Reporting Services component you are extending. Extensions shipped as a part of Reporting Services are signed with the report server public key and receive the FullTrust permission set.

IMPORTANT   You must modify the Reporting Services policy configuration files to allow FullTrust for any third-party extensions. If you do not add a code group with FullTrust for your custom extensions, they cannot be used by the report server.

For more information about the policy configuration files in Reporting Services, see "Using Reporting Services Security Policy Files" later in this document.

Expressions Used in Reports

Report expressions are inline code expressions or user-defined methods contained within the Code element of a report definition language file There is a code group that is already configured in the policy files that grants these expressions the Execution permission set by default. The code group looks like the following:

<CodeGroup
   class="UnionCodeGroup"
   version="1"
   PermissionSetName="Execution"
   Name="Report_Expressions_Default_Permissions"
   Description="This code group grants default permissions for code in 
      report expressions and Code element. ">
    <IMembershipCondition
       class="StrongNameMembershipCondition"
       version="1"
       PublicKeyBlob="002400..."
    />
</CodeGroup>

Execution permission allows code to run (execute), but not to use protected resources. All expressions found within a report are compiled into an assembly (called an "expression host" assembly) that is stored as a part of the compiled report. When the report is executed, the report server loads the expression host assembly and makes calls into that assembly to execute expressions. Expression host assemblies are signed with a specific key that is used to define the code group for all expression hosts.

Report expressions reference report object model collections (fields, parameters, etc.) and perform simple tasks like arithmetic and string operations. Code that performs these simple operations only requires Execution permission. By default, report user-defined methods in the Code element and any custom assemblies are granted Execution permission in Reporting Services. Thus, for most expressions, the current configuration does not require that you modify any security policy files. To grant additional permissions to expression host assemblies, an administrator needs to modify the policy configuration files of the report server and Report Designer, and change the report expressions code group. Because it is a global setting, changing default permissions for the expression hosts affects all reports. For this reason, it is highly recommended that you place all code that requires additional security into a custom assembly. Only this assembly will be granted the permissions you need.

SECURITY: Code that makes calls to external assemblies or protected resources should be incorporated into a custom assembly for use in reports. Doing so gives you more control over the permissions requested and asserted by your code. You should not make calls to secure methods within the Code element. Doing so requires you to grant FullTrust to the report expression host and grants all custom code full access to the CLR.
CAUTION   Do not grant FullTrust to the code group for a report expression host. If you do, you enable all report expressions to make protected system calls.

Custom Assemblies Referenced in Reports

Some report expressions can call third-party code assemblies, also known in Reporting Services as custom assemblies. The report server expects these assemblies to have at least Execution permission in the policy configuration files. By default, policy files that ship with Reporting Services grant Execution permission to all assemblies starting from the 'My Computer' zone. You can grant additional permissions to custom assemblies as needed.

In some cases, you may need to perform an operation that requires specific code permissions in a report expression. Typically, this means that a report expression needs to make a call to a secured CLR library method (such as one that accesses files or the system registry). The .NET Framework documentation describes the code permissions that are required to make this secure call; to execute the call, the calling code must be granted these specific, secure permissions. If you make the call from a report expression or the Code element, the expression host assembly must be granted the appropriate permissions. However, once you grant the expression host the permissions, all code that runs in any expression in any report is now granted that specific permission. It is much more secure to make the call from a custom assembly and grant that custom assembly the specific permissions.

Using Reporting Services Security Policy Files

Reporting Services stores security policy information in three configuration files that are copied to the file system during setup. These configuration files can contain a combination of internal-use and user-defined security policies for code assemblies in Reporting Services. The three configuration files correspond to three securable components in Reporting Services: The report server and Windows service, the Report Manager Web application, and the Report Designer preview window.

NOTE   There are two preview modes for Report Designer: the preview tab and the pop-up preview window that is launched when your report project is started in DebugLocal mode. The Preview tab is not a securable component and does not apply security policy settings. The preview window is meant to simulate the report server functionality and therefore has a policy configuration file that you or an administrator must modify to use custom assemblies and custom extensions in Report Designer.

The security policy configuration files contain security class information, some default named permission sets, and the code groups for assemblies in Reporting Services. The policy configuration files of Reporting Services are similar to the security.config file that determines the code group hierarchy and permission sets associated with machine and enterprise level policies in the .NET Framework. The location of this file is C:\WINDOWS\Microsoft.NET\Framework\v1.2.21213\CONFIG\security.config.

Policy Files in Reporting Services

The following table lists the policy configuration files in Reporting Services, their locations (assuming a default installation), and their respective functions.

File nameLocation (default installation)Description
rssrvpolicy.configC:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServerThe report server policy configuration file. These security policies primarily affect report expressions and custom assemblies once a report is deployed to a report server. This policy file also affects custom data, delivery, rendering and security extensions deployed to the report server.
rsmgrpolicy.configC:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportManagerReport Manager policy configuration file. These security policies affect all assemblies that extend Report Manager; for example, subscription user-interface extensions for custom delivery.
rspreviewpolicy.configC:\Program Files\Microsoft SQL Server\80\Tools\ReportDesignerThe Report Designer stand-alone preview policy configuration file. These security policies affect custom assemblies and report expressions that are used in reports during preview and development. These policies also affect custom extensions, such as data processing extensions, that are deployed to Report Designer.

Modifying Configuration Files

Configuration settings are specified as either XML elements or attributes. If you understand XML and configuration files, you can use a text or code editor to modify user-definable settings. Security configuration files contain information about the code group hierarchy and permission sets associated with a policy level in Reporting Services. It is recommended that you use the .NET Framework Configuration tool (Mscorcfg.msc) or Code Access Security Policy tool (Caspol.exe) to modify security policies in the security.config file first, so that policy changes correspond to valid XML configuration elements for policy files. Once you have done that, you can cut and paste the new code groups and permission sets from security.config to the policy file for the component to which you are adding code permissions.

IMPORTANT   You should backup your policy configuration files prior to making any changes.

Using this approach accomplishes two things. First, it enables you to use a visual tool to build your code groups and permission sets for Reporting Services. This is much easier than writing XML configuration elements from scratch. Secondly, it ensures that you do not corrupt the security policy configuration files with malformed XML elements and attributes. For more information about the Code Access Security Policy Utility, see "Code Access Security Policy Tool (Caspol.exe)" in the .NET Framework SDK.

Before modifying policy configuration files, you should read all the information available in this section and related topics. Modifying the policy configuration of Reporting Services can have a significant security impact on how Reporting Services components execute external code modules.

Using Custom Assemblies with Reports

In Reporting Services, you can write custom code for report item values, styles, and formatting. For example, you can use custom code to format currencies based on locale, flag certain values with special formatting, or apply other business rules that are in practice for your company. One way to include this code in your reports is to create a custom code assembly using the .NET Framework that you can reference from within your report definition files. The server calls the functions in your custom assemblies when a report is run. Custom assemblies can be used to retrieve specialized functions that you plan to use in your reports.

Referencing Assemblies in an RDL File

To support the use of custom code assemblies in report definition files, two Report Definition Language (RDL) elements are included in the RDL specification: the CodeModules element and the Classes element.

The CodeModules element enables you to refer to managed code assemblies in report expressions. CodeModules is a top-level element that contains the reference to the assembly that you use in your report definition files to call specialized functions. An entry in a report definition that supports the use of a custom assembly might look like the following:

<CodeModules>
   <CodeModule>CurrencyConversion, Version=1.0.1363.31103, Culture=neutral, PublicKeyToken=null</CodeModule>
</CodeModules>

You can manually add CodeModule elements to your RDL file or you can use the Code tab of the Report Properties dialog to add references to assemblies in your report. For more information, see the Writing Custom Code topic in Reporting Services Books Online.

The Classes element supports the use of instance members in a report definition. Classes is a top-level element that contains a reference to the class name and an instance name. An entry in a report definition that supports the use of instance members might look like the following:

<Classes>
   <Class>
      <ClassName>CurrencyConversion.DollarCurrencyConversion</ClassName>
      <InstanceName>m_myDollarConversion</InstanceName>
   </Class>
</Classes>

Deploying a Custom Assembly

You need to place custom assemblies in the application folders of Report Designer and the report server. Additionally, to use custom assemblies you need to edit the configuration file rssrvpolicy.config for the report server and the configuration file rspreviewpolicy.config for the Report Designer preview window. By default, custom assemblies are granted Execution permission in Reporting Services.

NOTE   There are two preview modes for Report Designer: the preview tab and the pop-up preview window that is launched when your report project is started in DebugLocal mode. The preview tab executes all report expressions using the FullTrust permission set and does not apply security policy settings. The pop-up preview window is meant to simulate the report server functionality and therefore has a policy configuration file that you or an administrator must modify to use custom assemblies in Report Designer. This pop-up preview also locks the custom assembly. Therefore, you need to close the preview window in order to modify or update your custom assembly code.

To deploy a custom assembly

  1. Copy your custom assembly from your build location to the report server bin folder or the Report Designer folder. The default location of the bin folder for the report server is C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\bin. The default location of the Report Designer is C:\Program Files\Microsoft SQL Server\80\Tools\Report Designer.
  2. Open the appropriate configuration file. The default location of rssrvpolicy.config is C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer. The default location of rspreviewpolicy.config is C:\Program Files\Microsoft SQL Server\80\Tools\Report Designer.
  3. Add a code group for your custom assembly if you need to increase code permissions beyond the default execution permissions. For more information, see "Code Access Security in Reporting Services" earlier in this document.

Updating Custom Assemblies

At some point, you may need to update a version of a custom assembly that is currently being referenced by several published reports. If that assembly already exists in the bin directory of the report server or Report Designer and the version number of the assembly is incremented or changed in some way, the currently published reports will no longer work properly. You will need to update the version of the assembly that is referenced in the CodeModules element of the report definition and republish the reports.

If you know that you will frequently update a custom assembly and your currently published reports need to reference the new assembly, you may want to consider using the same version number across all updates of a particular assembly. If you do not need your currently published reports to reference the new version of the assembly, you can deploy your custom assembly to the Global Assembly Cache. The Global Assembly Cache can maintain multiple versions of the same assembly, so that your current reports can reference the previous version of your assembly and your newly published reports can reference the updated assembly. Yet another approach would be to set the binding redirect of the report server to force a redirect of all requests for the old assembly to the new assembly. You would need to modify the report server Web.config file and the report server ReportService.exe.config file. The entry might look like the following:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly"
                              publicKeyToken="32ab4ba45e0a69a1"
                              culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0"
                             newVersion="2.0.0.0"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Using Strong-Named Custom Assemblies

A strong name identifies an assembly and includes the assembly's text name, four-part version number, culture information (if provided), a public key, and a digital signature stored in the assembly's manifest.

A strong name uniquely identifies an assembly to the common language runtime (CLR) and ensures binary integrity. To use strong-named assemblies with reports, you must allow your strong-named assembly to be called by partially trusted code using the assembly attribute AllowPartiallyTrustedCallersAttribute.

Using the AllowPartiallyTrustedCallersAttribute

You can use the AllowPartiallyTrustedCallersAttribute to allow strong-named assemblies to be called by Report Designer or the report server in report expressions. Using the AllowPartiallyTrustedCallersAttribute is the recommended way in which strong-named assemblies can be incorporated into your reports.

SECURITY   Before deploying an assembly that contains the AllowPartiallyTrustedCallersAttribute to your report server, you should review what operations and resources its public members can access. Always perform a security review before deploying custom assemblies to your report server.

To allow partially trusted code to call strong-named assemblies

  • In your assembly attribute file, add the following assembly-level attribute:
[Visual Basic]
<assembly:AllowPartiallyTrustedCallers>

[C#]
[assembly:AllowPartiallyTrustedCallers]

AllowPartiallyTrustedCallersAttribute is only effective when applied by a strong-named assembly at the assembly level. For more information about applying attributes at the assembly level, see "Applying Attributes" in the Microsoft .NET Framework SDK documentation.

CAUTION   The presence of this assembly-level attribute prevents the default behavior of placing FullTrust LinkDemand security checks, making the assembly callable from any other partially trusted assembly.

When the AllowPartiallyTrustedCallersAttribute is present, all other security checks function as intended, including any class-level or method-level declarative security attributes that are present. This attribute blocks only the implicit fully trusted caller demand.

Asserting Permissions in Custom Assemblies

By default, custom assembly code runs with the limited Execution permission set. In some cases, you may wish to implement a custom assembly that makes secured calls to protected resources within your security system (like a file or the registry). In order to accomplish this, you must do the following:

  1. Identify the exact permissions that your code needs in order to make the secured call. If this is a method that is part of a .NET Framework library, this information should be included in the method documentation.
  2. Modify the report server policy configuration files in order to grant the custom assembly the required permissions. For more information about the security policy configuration files, see "Using Reporting Services Security Policy Files," earlier in this document.
  3. Assert the required permissions as part of the method in which the secure call is made. This is required because the custom assembly code that is called by the report server is part of the report expression host assembly which runs with Execution by default. The Execution permission set enables code to run (execute), but not to use protected resources.
  4. Mark the custom assembly with the AllowPartiallyTrustedCallersAttribute. This is required because custom assemblies are called from a report expression that is a part of the report expression host assembly, which by default is not granted FullTrust, thus is a 'partially trusted' caller. For more information, see "Using Strong Named Custom Assemblies," earlier in this document.
SECURITY   Whenever you implement custom assemblies for use in your report expressions, you should only grant narrowly targeted permissions to these assemblies to mitigate the risk of the assembly code being misused. Granting FullTrust or other broad-reaching permission sets is not recommended.

Implementing a Secure Call

You can modify the policy configuration files to grant your assembly specific permissions. For example, if you were writing a custom assembly to handle currency conversion, you might need to read the current currency exchange rates from a file. To retrieve the rate information, you would need to add an additional security permission, FileIOPermission, to your permission set for the assembly. You can make the following additional entry in the policy configuration file:

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

You then add a code group that references that permission set:

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

The previous entry represents a permission set and a code group for your assembly.

In order for your code to acquire the appropriate permission, you must assert the permission within your custom assembly code. For example, if you want to add read-only access to an XML file C:\CurrencyRates.xml, you must add the following code to your method:

// C#
FileIOPermission permission = new FileIOPermission(FileIOPermissionAccess.Read, @"C:\CurrencyRates.xml");
try
{
   permission.Assert();
   // Load the XML currency rates file
   XmlDocument doc = new XmlDocument();
   doc.Load(@"C:\CurrencyRates.xml");

You can also add assertions as a method attribute:

[FileIOPermissionAttribute(SecurityAction.Assert, Read=@"C:\CurrencyRates.xml")]

For more information, see ".NET Framework Security" in the .NET Framework Developer's Guide.

Accessing Custom Assemblies Through Expressions

Once you have created a custom assembly, made it available to Report Designer or the report server, added the appropriate security policy, and added a reference to your custom assembly in your report definition, you can access the members of the classes in your assembly using report expressions. To refer to custom code in an expression, you must call the member of a class within the assembly. How you do this depends on whether the method is static or instance based.

Calling Static Members from a Report Definition File

Static members belong to the class or type itself and not to an instantiated object. These members can be accessed by directly calling them from the class. You should use static members to call custom functions in a report whenever possible, because static members perform best. To call a static member, you need to reference it as an expression that takes the form =Namespace.Class.Method.

To call static members

To call a static member, set your expression equal to the fully qualified name of the member, which includes the namespace, class name, and member name. The following example calls a method ToGBP which converts the StandardCost field value from dollars to pounds sterling and displays it in a report:

=CurrencyConversion.DollarCurrencyConversion.ToGBP(Fields!StandardCost.Value)

Important Information Regarding Static Fields and Properties

Currently, all reports are executed in the same application domain. This means that reports with user-specific, static data expose this data to other instances of the same report. This condition might make it possible for the static data of one user to be available to all users currently running a particular report. For this reason, it is highly recommended that you not use static fields or properties in custom assemblies or in the Code element; instead, use instance fields or properties in your reports. Static methods can still be used, because they do not store state or data.

SECURITY   Do not use static fields or properties in a custom assembly or Code element used by a report. Doing so may expose data for one user of the report to all users currently running instances of that report.

Calling Instance Members from a Report Definition File

If your custom assembly contains instance members that you need to access in a report definition, you must add an instance name for your class to the report. You can add an instance name for a class using the Code tab of the Report Properties dialog. For more information about adding instances of classes to a report, see "Writing Custom Code," in Reporting Services Books Online.

To call a static member, you need to reference it as an expression that takes the form =Code.IntanceName.Method.

To call instance members

To call an instance member of a custom assembly, you must reference the Code keyword followed by the instance name and the method. The following example calls an instance method ToEUR which converts the StandardCost field value from dollars to euros and displays it in a report:

=Code.m_myDollarCoversion.ToEUR(Fields!StandardCost.Value)

Conclusion

Reporting Services follows the .NET security model of code access security for securing custom assemblies and extensions. Because your extension code may be executed by any number of users of Reporting Services, all of which are unknown at development time, code access security needs to be configured for the report server, Report Designer, and Report Manager components that use extensions. The custom assemblies that you develop also require specific security policies in Reporting Services. You have learned in the previous discussion how to obtain code permissions for your custom assemblies and how to design, deploy, and run reports that use expressions based on custom code. Be sure to consider the security policies that your custom code requires in order to access the necessary resources. At the same time, apply the principle of least privilege to custom code that is integrated into your reporting solution.

Show:
© 2014 Microsoft