ne of the most useful features of Microsoft Reporting Services is its extensibility model. Just about any aspect of Reporting Services can be custom-tailored to meet your specific requirements. Part one of this two-part series explains how to replace the default Windows-based security model of Reporting Services with forms authentication security. First, you'll learn the ropes of implementing forms authentication security and how you can leverage it for Web-based reporting. Then you'll enhance the form's authentication extension by adding role-membership features to simplify the security maintenance.
With Reporting Services (referred as RS for short through the rest of this article), your reports are Web-enabled by default. Once a report is deployed to the report server, it can be requested in one of two ways:
What follows is a discussion of how both options stack against each other.
URL Addressability
URL addressability provides better user experience because it supports all RS interactive features, such as drilldown, drillthrough, document maps, etc. In addition, when a report is requested by URL, the report server can optionally generate the handy HTML Viewer toolbar, minimizing your development effort by automating mundane reporting chores, such as parameter handling, paging, searching, zooming, etc.
On the downside, URL addressability presents a potential security risk. First, it mandates a direct access to the report server. Typically, with URL addressability, the HTTP-GET request is initiated on the client-side of the application and submitted directly to the report server. Second, a malicious user could easily find out the report URL and try to exploit it—for instance, generate a confidential report by guessing the report parameters. For this reason, you should always take extra steps to protect sensitive reports that can be requested by URL. For example, you can implement horizontal data filtering at the data source based on the user identity, as the sample customer orders report will demonstrate.
RS Web Service
The RS Web service excels in functionality and flexibility. With URL addressability, you are limited to requesting reports only. The RS Web service exposes the full report server feature set through a vast number of SOAP APIs, allowing you to programmatically manage the report catalog. For example, you may need to programmatically generate a report and upload it to the report catalog. In this case, once the report definition file is generated, by using XML DOM, the client can call the CreateReport SOAP API to deploy the report.
Moreover, the RS Web service supports flexible reporting scenarios. You can generate reports on the server-side of an ASP.NET application or report off custom data structures produced in the application middle tier, like ADO.NET datasets. Or, you can generate reports in an unattended mode. Finally, RS Web service provides a more secure environment since the report request is not automatically exposed to the end user. For instance, strict security requirements may dictate that certain business rules must be validated before a report is generated. To respond to this need, an ASP.NET application can verify the report request on the server-side of the application before submitting it to the report server.
The major tradeoff of using the RS Web service is that it doesn't support report interactive features. It's also more involved than URL addressability because you need to take care of certain reporting tasks taken for granted when reports are requested by URL, such as loading the report images, rendering the report to the end user, and cookie management.
