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:
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 AccessThis 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 AuthenticationThis scenario leverages a default authentication mechanism of SSRS and uses a corresponding security extension. In this scenario:
If this option is chosen , an administrator must configure SSL for proper security, especially for basic authentication. Internet Deployment Option 3: Use the Programmatic ApproachSome of the situations in which a programmatic approach can be used:
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
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 AccessA couple of options allow users to access the Report Manager over the Internet:
The following are the steps to enable report management over the Internet (unless marked otherwise , steps are applicable to both options A and B):
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 . |