RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Harden MS Reporting Services Using Custom Extensions : Page 6

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.

User Authentication
To request a report, the end user has to navigate to the default.aspx page. The actual customer orders report is rendered with the help of the report viewer control, included with the RS samples. The report viewer control renders the report in an IFRAME by submitting an URL request to the report server.

The Adventure Works Web portal is configured for forms authentication. If the user has not been already authenticated, the user is redirected to the Logon.aspx page, which looks similar to the report manager login page shown in Figure 3. The user credentials consist of the customer identifier (the same as the one you use in the report manager) and password (this example uses the PasswordSalt column in the Individual table for the password value).

Once the user submits the page, the application needs to authenticate the user. Typically, you would perform the same authentication check as you would in the custom security extension. True, this will result in duplication of code but currently RS doesn't have any provisions to share the application authentication mechanism, not even ASP.NET forms authentication. To make things simpler, this example doesn't verify the user credentials at the application level.

To log in the user to the report server, the application must invoke the LogonUser SOAP API. The Login.aspx page does this:

ReportServerProxy server = new ReportServerProxy();
server.LogonUser(customerID, TxtPwd.Text, null);
First, the code initiates the report server proxy. Next, it calls LogonUser API. It is an open-ended argument you can use to pass an additional info that you need to authenticate the users. For example, suppose the customer identifier is not unique across all customers and you have to use an additional identifier, such as the company name, to identify the customer uniquely. In this case, you can pass the company name under the third argument.

As you can see, the signature of the LogonUser API matches exactly the signature of the IAuthenticationExtension.LogonUser method. This should come to no surprise considering the fact that in response to the LogonUser SOAP API, the report server calls your implementation of IAuthenticationExtension.LogonUser to allow the custom security extension authenticate the user. As a result, all arguments that you pass to the LogonUser SOAP API are be passed to IAuthenticationExtension.LogonUser.

This implementation of IAuthenticationExtension.LogonUser is straightforward. It executes the uspValidateUser stored procedure in an attempt to find a customer match for the given customer identifier and password and returns a Boolean result to the report server. If IAuthenticationExtension.LogonUser returns true, the report server is proceed by issuing an authentication ticket in the form of a cookie. To relay the cookie to the browser after the call to LogonUser, overwrite the RS Web service proxy as shown in the Microsoft Forms authentication sample.

As with ASP.NET forms authentication, you can set the cookie properties using the familiar declarative syntax in the report server web.config configuration file. For example, the following configuration sets the name of the cookie to sqlAuthCookie, its timeout to 60 minutes, and tells the report server to renew the cookie lifetime with each report request (slidingExpiration="true").

    <authentication mode="Forms">
   	<forms loginUrl="logon.aspx" name="sqlAuthCookie" 
			timeout="60" slidingExpiration="true" path="/">
Because the RS forms authentication relies on cookies, you need to first verify whether the browser passes the cookie to the report server when troubleshooting authentication errors. When a subsequent request is submitted to RS, the report server checks for the existence of the cookie. If the cookie is not present, the report server redirects the user to the page specified in the <forms> element. For example, if the cookie has expired the browser won't send it with the report request and the user will need to log in again.

When the report server fails to find the cookie, it redirects the user to the Logon.aspx page. Having to deal with so many authentication-related login pages may be confusing. Table 2 clarifies their purpose.

Table 2. Login pages and their purpose in forms authentication.






Application-level ASP.NET Forms Authentication



To log in to the Report Manager web application.



The Report Server redirects the user to the Logon.aspx page when the authentication cookie is missing.

The Logon.aspx page simply informs the user that the cookie session may have expired and provides a link to the application login page (Login.aspx). Of course, the page and give the user an option to log in to RS just like s/he would do by using the application login page. This could be useful if there is no application front-end to take care of authenticating the user or where you have static HTML pages with report hyperlinks.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date