The first post in this series focused on creating some core validation logic to validate a user request. With the core validation completed the next step is to wire up all the pieces required by SQL Reporting Services. This includes implementation of the security extension interfaces and configuration files. The IAuthenticationExtension interface requires implementing the GetUserInfo, IsValidPrincipalName, LogonUser and SetConfiguration methods. Leveraging the ValidationManager logic from the previous post the logic for these methods becomes simple. A lot of the logic below is from the Forms Authentication sample. IsValidPrincipalName and LogonUser use the ValidationManager.
The other extension is the IAuthorizationExtension. The implementation here is the same as that from the Forms Authentication sample, so it won’t be repeated here. There is also an anonymous version of this extension that exists and was documented by James Wu in this blog post.
The last piece is configuration and changing the various configuration files in SSRS so that the custom security extension works. Most of this is documented in the forms authentication sample, but will be repeated here. The core configuration files are the Report Manager and Report Server web.config files and the rsreportserver.config file. Report Manager requires changes to how impersonation is handled and, in our scenario, some additions to the appSettings section. If you have also implemented an HTTPModule in order to validate the request and redirect to an authentication server that would have to be registered as well. The changes to the web.config file are shown below. This is located by default in the C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportManager directory.
Note that we set identity impersonate to false. The various <appSettings /> keys are used throughout the code modules for various things. The important ones here are the AuthKey, which is a key added to our header to ensure that the request is coming from a trusted source. Again, there are more secure methods to use than this, but has been placed unencrypted in the configuration file for this example. The ReportMainConnectionString is used to connect to the user database and validate the UserToken that is passed in the header.
Similar changes are made to the Report Server web.config file. By default this is located in the C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer directory. See the sections that change below.
Configuration changes also need to be made to the rsreportserver.config file. This is the core configuration file for reporting services. The changes for that file are shown below. There are two sections that may need additional explanation. In the UI/CustomAuthenticationUI/loginUrl element the page used to redirect an unauthenticated request is provided. In the example here the UILogon.aspx page from the previous post will handle taking an unauthenticated request, validating the data and issuing the authentication token.
The Extensions/Security section details the security extension developed for handling SSO security in the sample. The first section provides the authorization extension. The AdminConfiguration/UserName element contains the username that will be considered the System Administrator on the SQL Reporting Services instance. Review of the Authorization extension shows that the extension reads in this configuration element and then makes decisions based on the value. This provides a means for someone to enter other users that could be considered System Users or System Administrators. The Extensions/Authentication section defines the authentication extension to use for the SSRS instance.
The final piece is deployment. Deployment consists of deploying the assembly, deploying our custom page and changing additional configuration files. The page and assembly are easy. Deploy the assembly to the Report Manager\bin and Report Server\bin directories. Deploy the UILogon.aspx page to the Report Manager\Pages directory.
Code Access Security policy, CAS, also needs to be addressed. By default assemblies in the bin directory run with limited trust. To grant full trust to your assembly open the rssrvpolicy.config file. This file is located in the Report Server directory of the SSRS installation. In the file find the <CodeGroup /> element that has a Url membership of $CodeGen and add the following <CodeGroup /> element afterwards. This example uses a Url condition. Best practice would dictate using a strong name membership condition by using a public key blob. To extract the public key blob (not the public key token) use the Secutil.exe tool as follows:
secutil.exe -hex -s MyAssemblyName.dll.
The Report Manager policy file, rsmgrpolicy.config, also needs to be updated. This file is located in the Report Manager installation directory. In this file the MyComputer zone should be updated to have a FullTrust PermissionSetName.
That’s it. Your sample should now work. A full Visual Studio 2010 project is available for download and modification.