Report Management and Execution
RS stores reports in a hierarchical, file-system type of structure. The structure entry point contains one or more folders. Each folder can contain reports, shared data sources, and other sub folders as well. Using the Web Service API, you can integrate report management and execution within an application. Listing 1
shows how to run a report and save the results on hard disk as PDF files.
You can cache and schedule RS reports. A Windows Service triggers the execution of scheduled reports by calling into the report processor. The report outcome is passed to a Delivery extension, which forwards the report to its destination recipient.
You don't have to code against the RS API to manage RS and run reports, however. The Report Manager component is a set of ASP.NET pages that provide UI access to Report Management (reports and data sources, roles, scheduling, subscriptions, report caches, etc.). The Report Manager's home page is located at http://<servername>/Reports.
You don't even have to do any coding to run reports. As an alternative to Web service access, RS offers URL-based access to reports, which uses the URL query string to convey execution parameters. The default location for URL-based report execution is http://<servername>/reportserver?<reportpath>.
|Figure 2. Protect Reports Using Role-based Security: You can secure each report or folder within the hierarchical structure by assigning execution and management permissions through roles.|
The security architecture of RS is proof that Microsoft has started to take security seriously. During installation, RS asks for the Windows identity it will use to run the Web service and the Windows service. Additionally, it asks whoever is performing the install to specify the credentials that it must use to connect to the SQL Server Repository. The report server, however, will never connect to a remote server using its default credentials. While configuring each report, you must specify how credentials will be provided to the remote data source. The available options are:
- Prompted credentials
- Windows NT integrated security
- Stored credentials
- No credentials
RS uses encryption keys to secure data such as stored credentials (which are compulsory when running scheduled reports), connection information to the repository database, etc. Sensitive content on the report server is encrypted with a symmetric key. The symmetric key is itself encrypted with an asymmetric public key (created by the Report Server Windows service when it first runs) that corresponds to the computer and the user account under which the Report Server Windows service runs.
The RS security infrastructure uses a role-based security model to protect access to general configuration settings, report management, and report execution. Currently, RS does not offer any built-in authentication mechanism. It relies upon Windows Security. In other words, you currently can assign role ownership using Windows identities only. This doesn't mean you cannot develop solutions based on custom authentication schemas such as ASP.NET Forms Authentication. However, you'd have to develop all the plumbing yourself (calling the LogonUser and stuff like that).
RS provides a distinction between system-wide and item-level tasks and, as a consequence, provides separate management for them. System-level tasks include operations such as managing roles, modifying shared schedules and site-level configuration settings, etc. Item-level roles protect access to specific items within the hierarchical report structure. Item-level roles (and their mapping to Windows identities and groups) are defined globally, but you need to navigate to a specific folder or report to assign a role to that resource. When a role assignment is specified at the folder level, all the reports and sub folders the folder contains inherit the parent's settings (see Figure 2).