Testing Custom Security
If you've followed the setup instructions in the readme.htm
file, all you have to do is open the Visual Studio.NET solution file (FormsAuthentication.sln
) and compile the AdventureWorks.Extensibility
project. For your convenience, there is a post-build event in the AdventureWorks.Extensibility
project setting (Build Events) to copy the binary to the correct Report Server and Report Manager folders.
Next, open the Report Manager Web application and log in as an administrator (user name: 'admin,' password: 'admin'). Navigate to the FormsAuthentication folder and set up a role-based policy by assigning browser rights to a given role. If you want grant this user permission to use the Report Manager as a report rendering tool, grant the role Browser rights to the Home folder as well. Without this, the user cannot navigate to the FormsAuthentication folder since Home is the root folder.
|Figure 3. Debugging the Security Extension: Attach to the ASP.NET process to debug the custom security extension under the Report Manager.|
To debug the security extension from the Report Manager follow these steps:
- Run the Report Manager.
- In Visual Studio.NET, open the Processes window (found under the Debug menu). Select the Show System Processes checkbox. Locate the ASP.NET process (aspnet_wp for Windows 2000 or Windows XP). You may have several instances of the ASP.NET process running. Select the one which hosts the Reports application, as shown in Figure 3.
- Set breakpoints in the security extension, e.g. in LogonUser.
- Log on in the Report Manager using the credentials of the user you want to test. At this point, your breakpoint in the LogonUser should be hit.
Debugging the custom security extension when running the sample Web application is even easier. Open the FormsAuthentication.sln
solution. Set the Web application as a startup project and default.aspx
as a start page. Hit F5 to debug the solution. The application Forms Authentication security mode will redirect you to the Login.aspx
page. Once you enter the user credentials, Login.aspx
calls the LogonUser SOAP API, which in turn calls IAuthenticationExtension.LogonUser
in our custom security extension. At this point your breakpoint in LogonUser should be hit.
Troubleshooting Custom Security
Judging by the feedback I get from the RS public forum, custom security is one of least understood features of Reporting Services. So here are some tips which may save you hours of debugging and head scratching when troubleshooting custom security.
To start with, I can't emphasize this fact enough: Just like ASP.NET Forms Authentication, RS custom security is cookie-based. If the browser doesn't pass the cookie back to the Report Server, the user will be redirected to the Logon page. What follows is a list of the most common reasons the browser fails to pass the cookie back and how to avoid or workaround them.
- Using localhost
Using localhost to launch the client tricks the browser into believing that the Report Server and your Web applications are on different domains. Instead, when testing custom security locally, specify the machine name, e.g. http://<mymachinename>/adventureworks/default.aspx as opposed to http://localhost/adventureworks/default.aspx.
- Restrictive Browser Policies
Sometimes, the authentication cookie is not transmitted back because the browser privacy settings are configured to block cookies. This may sound like a no-brainer, but you will be surprised how often folks forget to glance at the browser status bar to see if the authentication cookie simply can't "get through." If this is the case, assign the Report Server Web site to the Trusted Sites zone.
- Script Synchronization Issues
- Cross-domain Security Issues
Suppose you have installed the Report Server and the Web application on two different domainslike, the Report Server machine belongs to the www.abc.com domain, while the Web application is on the www.xyz.com domain. For security reasons, Internet Explorer doesn't permit cross-domain cookies, so the authentication cookie won't be sent to the Report Server.
The most obvious solution to this problem is to move the applications to belong to the same domain You'll also need to change the TranslateCookie method in the overloaded proxy class and set the cookie Domain property to your domain (.xyz.com in this example). Please note that both applications can be physically located on two separate servers as long as both machines belong to the same domain.
If hosting both computers under one domain is not an option, another workaround is to invoke the LogonUser SOAP API on the Report Server machine. For example, once the custom application authenticates the user, it redirects to an ASP.NET page residing on the Report Server, which in turn calls LogonUser. As a result, the authentication cookie is be scoped at the domain to which the Report Server belongs. Of course, you need decide how the Web application will communicate to the Report Server that the user has successfully authenticated. This may present a security risk, so take extra steps to ensure that security is not compromised. For example, you could use IP address filtering and restrict access to the ASP.NET page that contains IP address of the Web application server.
- Cookie Configuration
RS Forms Authentication uses the same syntax to set the authentication cookie as ASP.NET Forms Authentication. For example, if you find out that the authentication cookie expires too soon, you may want to increase the cookie timeout. See the "Configuring ASP.NET Forms Authentication" link in the Resources section.
If the Report Server is deployed to a Web farm environment, the cookie configuration settings of the cluster machines may not match. Check all instances of the RS web.config configuration files and make sure that you use identical cookie settings. Please see the "Forms Authentication Across Applications" link in the Resources section.
- Issues with Non-browser Clients
While the browser automatically sends the cookie to the Report Server, you are on your own when integrating other types of applications, such as WinForm clients, with a Report Server configured for Forms Authentication. Basically, you need to store the authentication cookie after the LogonUser call and send it back with each subsequent request (see "Using Forms Authentication from WinForm Applications").
If you find out that the Report Manager doesn't pass back other application-defined cookies, apply RS Service Pack 1. It supports a special PassThroughCookies element to support transmitting cookies other than RS-related cookies.
When you're through troubleshooting custom security, it's time to verify that the cookie is successfully sent by the client application.