You might be wondering about alternatives for providing reports in a non-Windows?authenticated environment. One such viable approach is the use of the Report Server Web service. As SQL Server 2005 Books Online (BOL) explains, "Reporting Services provides access to the full functionality of the report server through the Report Server Web service." In other words, you could programmatically request and render a report on behalf of an end-user by using a bit of .NET code and the login credentials of your application or Web server for authentication purposes. This type of security architecture is common among Internet-facing applications that use a single login to access back-end relational databases. Additionally, this approach gives you tight control not only over who views reports but also over the manner in which the reports are accessed.
Related Main Article: Using Reporting Services in an Internet/Extranet Environment
But the use of Web services for requesting and rendering reports also has a few key drawbacks. Most importantly, it limits the features and interactivity of reports. Specifically, many report capabilities— such as automatic sorting, hiding or showing report items, and navigation between reports—rely on direct access (through a URL or a Web form postback) to the Report Server. So, if a summary report has been programmatically rendered and a user tries to click on a report item to "drill down" into a detailed report, the hyperlink will point to a URL that is inaccessible to the user.
Using Web services for reporting has two other important drawbacks that I'll only mention here, but explain more in the main article:
- You can't know the end-user's identity during Report Execution.
- You can't leverage Reporting Services' built-in authorization model (Roles and Tasks).
Note that the Web services APIs and custom security aren't necessarily mutually exclusive. For example, you could decide to develop a custom security extension and within your application, you could call the Web services APIs to do things like return a list of reports that a user can view.
Using Web services for report rendering didn't meet the requirements of my customer in this case. Assuming your requirements also call for interactive reports and direct end-user connectivity to the Report Server, the solution I explain in the main article is an excellent and secure choice.
