I am migrating an extensive set of reports from classic asp web application into Reporting Services, and I've hit an interesting design issue.
My planned architecture consists of an IIS application server running a Classic ASP application and a database server running SQL Server 2008 Reporting Services. The basic problem is maintaining security during the transition from the asp application to the reports in SSRS. The asp application collects information from the user and generates parameters which it will then post to the Report Server. This setup would require that the Report Server accept anonymous requests for Reports, essentially defeating the built in Active Directory security.
This means a malicious user could create his own html page with his own report parameters and post to my Report Server, allowing him complete access into the data in my database. As it stands this architecture would result in a pretty significant security breach.
My classic ASP already defines user accounts and roles, so I'd like to use those accounts to restrict access to the reports. My plan is to add a .NET application to my application server which load reports for the user using the Report Viewer control. The user session can be transferred securely from classic asp to asp.net in a number of ways. Then the Report Viewer can authenticate against the Report Server using the ASP.NET process account.
This design however, results in all of my users being routed to a single page for all of the reports in the system. Will this result in a performance hit to the website? It seems like the performance gain I get from moving all the reports into SSRS will be lost if I then serve them all up through the IIS app server. And I'm not sure what the effect will be if 90% of my web traffic gets routed down to one asp.net page.
Are these legitimate concerns? Am I going about this all wrong?
