Intranet applications are deployed and used in an isolated and secured intranet environment. Access to this type of application is restricted to a limited group of authorized users, such as employees who belong to a domain. Figure 4
depicts a typical intranet-based deployment that uses the Web ReportViewer for report delivery.
|Figure 4. Intranet-based Deployment: Intranet reporting favors Integrated Windows authentication.|
From a security standpoint, intranet applications should leverage the Windows Active Directory whenever possible where users are authenticated and authorized by the Report Server based on their domain accounts. For example, in Figure 4
, Terri is logged to the AW domain as AW/Terri. Terri then uses the Web Reporter Viewer application to request a report. The Web Report Viewer passes Terri's credentials to the Report Server. The report administrator can enforce restricted access to the report catalog by assigning the Terri's Windows account (or Windows groups Terri belongs) to predefined or custom security roles.
Table 1. Configuration Settings: The table shows the configuration settings used for Integrated Windows Authentication.
|Application virtual root (vroot)
|Integrated Windows Authentication
||<authentication mode="Windows"/><identity impersonate="true"/>
||DefaultCredentials (default configuration)
||Windows security (default configuration)
Table 1 outlines the configuration settings to set up intranet security. The ASP.NET application virtual root in IIS is configured for Integrated Windows Authentication. This causes the IIS to initiate a challenge/response during the initial handshake with the browser to authenticate the user using NTLM.
The ASP.NET application must impersonate the user to flow the user credentials to the Report Server. If the Report Server and the ASP.NET application are on the same machine, this could be as easy as changing the application Web.config
). You don't need to do anything special to set up the ReportViewer because it will pass the user identity with the Web service call by default (DefaultCredentials=True
Unfortunately, impersonating the user won't work if the Report Server and the application are installed on different servers. Besides impersonation, this scenario requires delegation because of the double hop between the application server and report server. To enable cross-machine Kerberos delegation, you need to take additional (not so simple) steps (see Resources). If Kerberos delegation is not an option, the Report Server can be configured for Basic or custom security.
In general, Windows Integrated security is not an option for Internet-facing application. An Intranet Web application is typically configured for anonymous access and the user is required to log in with user name and password. Upon login, the application verifies the credentials against the user profile store (e.g. a SQL Server database).
As noted before, if the Web ReportViewer is used for report delivery, the reports are generated on the server side of the application and the browser never accesses the Report Server directly. Therefore, the Report Server doesn't have to be configured for Internet access (it can remain on the private subnet). As a result, you can consider various security strategies for securing an Internet-facing Web application, including trusted subsystem or custom security.
|Author's Note: No matter the security model chosen, if your reports contain sensitive information, you should secure the data transfer by using the Secure Sockets Layer (SSL) protocol.
With the trusted subsystem approach, the Report Viewer submits all requests to the Report Server under a single "trusted" Windows account (see Figure 5
|Figure 5. Trusted Subsystem: With the trusted subsystem, the Report Server cannot differentiate the Web users.|
The application authenticates and authorizes the users as it deems necessary (e.g. using Forms Authentication). When the user requests a report, the ReportViewer submits the request under the same trusted account.
Table 2: Configuration settings for trusted subsystem.
||<authentication mode="Forms"/>or custom application security
||DefaultCredentials (default configuration)
||Windows security(default configuration)
The advantage of the trusted subsystem approach is that it is fairly easy to set up. By default, the application will pass the Windows identity it runs under to the Report Server. This will be the ASP.NET process identity (IIS 5.0) or the application pool identity (IIS 6.0).
If the application runs under IIS 6 (Windows Server 2003), you can change the identity of the application pool, e.g. to use a domain account. As a prerequisite, make sure to add the Windows account that will be used for the pool identity to the Windows 2003 IIS_WPG group. With IIS 5.0 (Windows XP or Windows 2000) you can change the ASP.NET process identity in machine.config
, as explained in more detail here
. Alternatively, with IIS 5.0, you can change the IIS application protection mode to High and use Component Services to set the identity of the COM+ Application.
When trusted subsystem is used, the Report Server sees all requests coming under the same account as though they come from the same user. In other words, the Report Server won't be able to differentiate the users. As a result, the users cannot use the My Reports feature. In addition, the report author controls security by using User!UserID property, for example, to pass the user identity to the report data source to restrict the data shown on the report per user. If you need the user identity in your reports, you need to use custom security.