By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.
Harden MS Reporting Services Using Custom Extensions
An incredibly flexible extensibility model is included with Microsoft Reporting Services and hammering down a custom security model is one smart way to take advantage. Shore up your implementation with forms authentication and role membership.
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:
URL addressability: The report is requested by submitting an HTTP-GET request to the report server. In its simplest implementation, URL addressability can be initiated by clicking on a static hyperlink in which the report URL has been embedded. For example, to request the sample customer orders report, the hyperlink can be set as follows:
http://<ComputerName>/ReportServer?/<FolderPath>/Customer Orders, where
ComputerName specifies the machine name where the report server is installed. FolderPath specifies the full folder path where the report is deployed.
The RS Web service is where the report is requested by submitting SOAP request to the RS Web service.
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.
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.
