Export (0) Print
Expand All

Specifying Connections for Custom Data Processing Extensions

New: 5 December 2005

You can create or use third-party custom data processing extensions on a report server to enhance the data processing capability of supported data sources, or to support additional types of data sources that are not available in a default Reporting Services installation. Connections are handled differently depending on the implementation. The following implementations are available for data processing extensions:

  • Custom .NET Framework data providers (if you are accessing data from DB2.NET, Oracle, ODP.NET, or Teradata data sources, you might be using a custom .NET data provider)
  • Custom data processing extensions that support IDbConnection
  • Custom data processing extensions that support IDbConnectionExtension
ms345229.note(en-US,SQL.90).gifNote:
Check with your third-party provider to find out how your custom data processing extension is implemented.

If your custom data processing extension connects to data sources using impersonation, you must use the Open method on either the IDbConnection or IDbConnectionExtension interfaces to make the request. Alternately, you can store the user identity object (System.Security.Principal.WindowsIdentity) and then reuse it in the other data processing extension APIs.

In previous releases of Reporting Services, all custom data processing extensions were called under user impersonation. In this release, only the Open method will be called while impersonating the user. If you have an existing data processing extension that requires integrated security, you must modify your code to use the Open method or store the user identity object.

When configuring a report to use a specific data source, you set properties that determine the data source type, connection string, and credentials that are used to access the data source. The following table describes the credential types that are supported for .NET Framework data providers. For more information about setting report data source properties, see Specifying Credential and Connection Information.

Credentials Connections

Integrated security

If your data provider supports it, you can use Windows integrated security. The request is sent using the credentials of the current user.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).

Windows authentication

If your data provider supports it, you can use a Windows domain user account. The report server impersonates the user account before the data processing extension is called.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).

Database credentials

Database authentication is not supported for connections made through a custom .NET data provider. The report server will fail the connection in all cases.

No credentials

You can use the no credentials option with custom .NET data providers. If the unattended execution account is specified, the connection string determines the credentials that are used. The report server impersonates the unattended execution account to make the connection.

If the unattended execution account is not defined, the report server will fail the connection. For more information about defining the account, see Configuring an Account for Unattended Report Processing.

If you are using a custom data processing extension that only supports IDbConnection, you must specify the connection in the following way:

  1. Configure the unattended execution account. Configuring this account is required for connections made using IDbConnection. The report server impersonates the account when making the connection.
  2. Configure the data source properties on the report to use No credentials.
  3. Put the credentials used to connect to the data source in the connection string.

When using IDbConnection, the following credential types are not supported: integrated security, Windows user accounts, and database credentials. If a data source connection uses these options, the connection will fail on the report server.

If you are using a custom data processing extension and supports, IDbConnectionExtension, you can specify the connection in the following ways:

Credentials Connections

Integrated security

If your data provider supports it, you can use Windows integrated security with custom data processing extensions that use IDbConnectionExtension.

When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).

Windows authentication

If your data provider supports it, you can use a Windows domain user account for custom data processing extensions that use IDbConnectionExtension.

The report server impersonates the user account before the data processing extension is called. When defining the connection string, be sure to include arguments that specify integrated security (for example, a connection to a SQL Server data source might include Integrated Security=SSPI on the connection string).

Database credentials

You can use database authentication to configure connections for custom data processing extensions that use IDbConnectionExtension.

No credentials

If the unattended execution account is specified, the connection string determines the credentials that are used.

If the unattended execution account is not defined, the report server will fail the connection.

Community Additions

ADD
Show:
© 2014 Microsoft