Microsoft offer a sample application to alter SQL Reporting Services from Windows Authentication to Forms Authentication. The sample is not bad, but essentially a bit of a hack. We have had several problems installing it, which I thought I would document. Other developers seem to be having similar problems.
The majority of organisations will probably desire to you SRS in a manner outside the basic install. This usually means that you need a custom interface to the reports, which replaces the standard Report Manager.
Microsoft offers two samples which are useful to a point. They are as follows:
Other samples and useful Microsoft information can be found here:
Examples externally from Microsoft which I found useful can be found here:
Finding Good Examples
However, even with this wealth of information, it is still pretty difficult to find good examples of what most of us want. The example Forms Authentication in Reporting Services is useful, but I think seriously flawed. It tries to address a problem, that is actually inherent in Reporting Services 2000, which is that is relies on Windows Authentication and expects most users to be happy with URL access to reports.
URL access to reports is a security risk. You can’t pass hidden parameters to it, as all you need to do to compromise the integrity of the system is to right click -> Properties -> URL. Obvious to most people will be the parameters slung off the end. UserID=x, can pretty easily be changed.
This leaves you with the web service, which in my opinion should have been the only way to access SQL Reporting Services. With this focus, Microsoft would have built a much superior product. Focusing on Windows Authentication ties the product in with their server business, and essentially becomes a nightmare for anyone to administrate. We as an organisation don’t want to maintain a multitude of domain accounts so that people can access reports. We don’t have the time, or inclination to do so. We already have a application which follows the fundamental principles of Microsoft tiered development and a security and user model that fits with that using Forms Authentication. We want to tie them together. If you are reading this, I’m guessing you do too!
So what is the solution? We think that for the moment we will put up with the example Microsoft has put together and use the custom security extension within SQL Reporting Services itself. It isn’t really exactly what we want, but we can’t see a way around it.
Key Problems with the MSDN Custom Security Sample
We had several problems installing this sample. They are as follows:
- The documentation for config file changes is disjointed. It is easy to get lost switching back and fore between the ReportServer and ReportManager directories. It would have been better to have just go through all the changes in one section, and then focus on the other. We missed out one of the files (you’ll get a nicely presented Report server is not running error in ReportManager), due to this documentation misdemeanour.
- Forget localhost! For development, localhost is something that an ASP.NET programmer seems to be attached to at the hip. For the web service you need to remove it from your consciousness. If you are having the problem where everything seems to work with the Report Manager, you are able to see the new web form login page, and register a user, but you just can’t seem to login, as it bounces you back to the login every time? When you put in an invalid user it works as you expect? When you enter the wrong password it tells you so? Change localhost to your_machine_name, and hey presto. Took me a long time following the cookie in debug to figure out that little nasty!
The Standard Edition of SQL Reporting Services will not support “Security extensions, including support for custom or forms-based authentication”, hence this sample will NOT WORK! For more information check out the various Editions of Reporting Services.
- Verify your config files have been changes correctly. It is very easy to get lost or miss one out.
If you change the name of the DLL from Microsoft.Samples…., then make sure you make the appropriate changes across all the config requirements.
Where to go from here
We now have the sample working on the Development Edition, but since Standard Edition doesn’t work a decision needs to be made about continuing on. To work with the web service is fairly easy, and we are able to retrieve the list of reports, gain report parameters and open reports. However, this still is outside what we really need, which is a way to embed these reports into a viewer style, but without the URL access.
So how do you get the content from the web service .Render into a separate frame. You can’t just dump it into the same page, since a PDF file won’t render like this unless you clear the buffer, and a HTML page comes back complete with HTML, HEAD and BODY tags. The HTML standard goes right out of the window on that one.
I think the solution might be to encrypt the URL access, or use some kind of proxy system, that does a System.Web.HttpRequest to the report you wanted, without revealing the URL parameters, which essentially most people wouldn’t really want to display obviously to their users.
Ideas are welcome.