Internet Deployment Considerations


Reporting Services is not specifically designed for Internet- facing scenarios. This is, partially, because the default authentication mechanism of Reporting Services is Windows integrated security. For security reasons, SQL Server setup does not provide options to deploy SSRS with anonymous access to reports .

Note

Chapter 18 provides additional details on securing Reporting Services installations .


Several deployment options are available to a SSRS administrator to make reports accessible over the Internet:

  • Keep only public data in the SSRS catalog and enable Report Server for anonymous access.

  • Deploy SSRS with Windows authentication and leverage Kerberos delegation to authenticate users.

  • Use programmatic options (such as custom security extensions) to authenticate and authorize users.

Note

When an administrator deploys Reporting Services on the Internet, his web server security might not allow installation to proceed. The work-around is to block the target server from Internet access, relax security, install SSRS, and tighten security again .


Internet Deployment Option 1: Enable Report Server for Anonymous Access

This scenario is designed to distribute public information. In this scenario, none of the reports are secured and all of the users would get the same information. When accessing Reporting Services deployed in this fashion, Internet users will not be prompted for login credentials. Best practice for this scenario is to place the SSRS catalog database on the same server with an instance of the Report Server. Because the Report Server has web components , this option means that the SQL Server 2005 instance that hosts catalog data will also be running on the web server and there are no queries that cross boundaries of the web server.

To reduce data exposure in this scenario, the catalog must only contain a limited subset of public data. To further reduce data exposure, reports can be configured to be rendered from an execution snapshot; in this latter case, the SSRS catalog would only contain the snapshot data.

Note

To configure a report's rendering from a report execution snapshot, an administrator can use the Report Manager, navigate to a report that needs to be configured, then navigate to the Properties tab, Execution screen and select the Render This Report from a Report Execution Snapshot option .


Because this scenario does not protect data from unauthorized access, it might only be used when a company intends to publish public data, such as a product catalog. Secure Sockets Layer (SSL) configuration is not required for this scenario.

To provide public data (or snapshots with public data) to the SSRS catalog in this configuration, an administrator can use replication or SQL Server Integration Services to "copy" public data (or snapshots) from an internal data source to the SSRS catalog placed on a web server.

Internet Deployment Option 2: Deploy Report Server with Windows Authentication

This scenario leverages a default authentication mechanism of SSRS and uses a corresponding security extension.

In this scenario:

  1. A company would have a domain associated with web-facing servers and use Kerberos delegation to validate a user by interacting with a corporate domain inside the firewall.

  2. Customers can configure Reporting Services virtual directories with either Windows Integrated or Basic authentication.

  3. When accessing Reporting Services deployed in this fashion, Internet users will be prompted for credentials. After a user is validated , she will have the level of access to a report corresponding to her credentials.

If this option is chosen , an administrator must configure SSL for proper security, especially for basic authentication.

Internet Deployment Option 3: Use the Programmatic Approach

Some of the situations in which a programmatic approach can be used:

  • Users do not have Windows accounts.

  • User IDs and passwords are stored in a third-party security provider, which, in turn , is used for user authentication.

  • Single sign-on technology (such as Microsoft Passport) is used in place of Windows authentication.

To programmatically handle security, a company can develop a custom Security Extension, handle security within a .NET application, or use the new Report Viewer control.

Note

Please keep in mind that security breaches can have far-reaching financial consequences for a business; thus, use custom security solutions with caution, especially when a reporting solution is exposed on the Internet .


This book discusses some aspects of security extensions in Chapter 26, "Writing Custom Reporting Services Extensions." An example of a security extension is provided with SQL Server 2005.

On a high level, to handle security within an application, a developer could

  • Authenticate a user in the code by either collaborating authentication processing with a third-party security provider or perhaps simply comparing the user's identifier and password to the values stored in a database.

  • After the user is successfully authenticated, the code would either query a third-party security provider or a database for the user's security access options.

  • Lastly, the code needs to control access to a report, based on the user's security access options.

You have several options to control a user's access to a report. Depending on the need of the reporting application, a code can impersonate a Windows user, who mapped to the SSRS Content Manager role (an administrative access). In turn, the code itself would control which reports can be accessed by a user.

Alternatively, depending on the actions that the code must take, the code may impersonate different Windows users who have finer granularity of permissions. In this case, there could be a Windows user who has access to just a single report.

After a user is impersonated, the code can, for example, use the function Render to access the report's data stream or use the Report Viewer control.

The Report Viewer control can process remote server as well as local reports. When the Report Viewer control processes local reports, it does it internally and does not need access to a Report Server.

Most data sources (like SQL Server) that a Report Viewer control uses require user identification and a password to access data. In this case, an application can collect, for example, a user's SQL Server credentials and pass those credentials to a data source, thereby restricting the user's access to data.

Enabling a Report Manager for Internet Access

A couple of options allow users to access the Report Manager over the Internet:

  1. Install a Report Manager on the same computer as the Report Server.

  2. Install a Report Manager on a different computer than the Report Server.

The following are the steps to enable report management over the Internet (unless marked otherwise , steps are applicable to both options A and B):

1.
Install SSRS on the Internet-facing web server using the Install But Do Not Configure installation option.

2.
Option B only. The instance installed in step 1 hosts only the Report Manager. Use the SQL Server Surface Area Configuration tool to disable the Reporting Services service.

3.
Option B only. Repeat step 1 to install another instance of SSRS on a different computer, normally behind the firewall. This instance hosts the Reporting Services service.

4.
Option A only. Secure the connection between the web server and SQL Server computer that will host the SSRS catalog. This can be achieved using IPSec.

5.
Run the Reporting Services Configuration Tool, connect to the server that hosts the Reporting Services service, specify service accounts, configure virtual directories, and create the SSRS catalog (if SQL Server is in a different domain and Kerberos is not enabled, use SQL Server credentials to connect to the database server).

6.
Option B only. On the computer that hosts Report Manager, modify RsWebApplication.config so the <UI> tag looks like:

 <UI>       <ReportServerVirtualDirectory></ReportServerVirtualDirectory>       <ReportServerUrl>https://{SERVER}/ReportServer</ReportServerExternalURL>       <ReportServerExternalURL>https://{SERVER}/ReportServer</ReportServerExternalURL>       <ReportBuilderTrustLevel>FullTrust</ReportBuilderTrustLevel> </UI> 

Where <ReportServerUrl> indicates to the Report Manager that it should access remote server, < ReportServerExternalURL > allows Internet users to use the Report Builder, and {SERVER} is a fully qualified domain name (like www.microsoft.com) of the computer that runs the Reporting Services service.

Note

Just like with any SSRS deployment, to make sure that Reporting Services Internet deployment is successful, users should be able to access SSRS by typing: http(s):// {SERVER} /ReportServer .




Microsoft SQL Server 2005 Reporting Services
Microsoft SQL Server 2005 Reporting Services
ISBN: 0672327996
EAN: 2147483647
Year: 2004
Pages: 254

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net