I'm integrating SSRS 2008 Reporting Server (remote mode) into an ASP.NET application that implements Forms Based Authencication. The ASP.NET application runs on Server 2008 R2 / IIS 7.5 under it's own decicated application pool The user identity on the app pool uses a custom Idenity called "AppUser" On the Reporting Server, We created a "root" folder for App1 that holds all the reports for the application We added the "AppUser" to the folder with Browser role. We publish all our reports. In the ASP.NET application, we create a new webform and add the ReportViewer control. We set processing mode to "remote" and specify a report name under ServerReport. We DO NOT set any credentials on the ReportViewer control. And the report runs fine. ---- Now my question --- Even though the ASP.NET application uses Forms Authencation for users, it appears the ReportViewer control runs under the Identity of the Application Pool. This is great because the ASP.Net application is public facing and we have 1000's of users logging in each day (yes, we have per processor license) and we don't want to be forced to authenticate them under their own user id on the reporting server. Is this a valid security implementation for SSRS and ASP.NET applications? Are there scalability issues or connection limits using only 1 identity for many users? Any feedback would be much appreciated!

I expect this is a workable approach (not one that I would take), but it should work. Consider that in an ASP application the Connection Pool plays a critical role in scalability. The report Processor will be opening connections for each Data Source referenced in the report and if the ConnectionString is the same for each instance, it can leverage previously opened connections (thus avoiding having to reopen the connection). I don't recommend SSPI-authentication for production reports because of the dangers of Trojan attacks that leverage the rights affored to elevated users. Consider as well that with SSPI authentication, the DC has to be requeried on each use to re-authenticate. I suggest using fixed-credential Data Sources that use SQLServer authentication instead. hth__________________________________________________________________ William Vaughn Author, Mentor, Trainer, MVP Beta V Corporation William Vaughn's blog Hitchhikers Guide to Visual Studio and SQL Server (7th Edition) The Owl Wrangler a fantasy fiction novel Please click the Mark as Answer button if a post solves your problem!

Thanks for the quick feedback William. But I'm not sure i follow your concerns...or i might not be explaining the setup correctly. One thing i didn't mention is that we are using the ReportViewer control ONLY to run all the reports within the ASP.NET application. Users will NOT be connecting and running reports from the report manager directly. Therefore, the ReportServer is configured to use Windows Security (no custom forms authentication). Here's how a report is run: client logs into web app (App1.web) using forms authentication. client opens web form in App1.web to run a report. web form uses ASP.Net ReportViewer Control. During Page load event on webform.aspx, ReportViewer.ServerReport.ReportServerCredentials is set using DefaultCredentials (which is Identity on app pool used by App1.web). So the ReportViewer authenticates to ReportServer using integrated security using a single App pool Identity. (kind of like an application user ID). All datasource connections on the ReportServer for App1.web use the same connection. Therefore, leveraging the db connection pool when querying database and running reports. In terms of who can access what reports, we lock this down in App1.web using asp.net roles. Does that make sense?

Thanks for the quick feedback William. But I'm not sure i follow your concerns...or i might not be explaining the setup correctly. One thing i didn't mention is that we are using the ReportViewer control ONLY to run all the reports within the ASP.NET application. Users will NOT be connecting and running reports from the report manager directly. Therefore, the ReportServer is configured to use Windows Security (no custom forms authentication). Here's how a report is run: client logs into web app (App1.web) using forms authentication. client opens web form in App1.web to run a report. web form uses ASP.Net ReportViewer Control. During Page load event on webform.aspx, ReportViewer.ServerReport.ReportServerCredentials is set using DefaultCredentials (which is Identity on app pool used by App1.web). So the ReportViewer authenticates to ReportServer using integrated security using a single App pool Identity. (kind of like an application user ID). All datasource connections on the ReportServer for App1.web use the same connection. Therefore, leveraging the db connection pool when querying database and running reports. In terms of who can access what reports, we lock this down in App1.web using asp.net roles. Does that make sense?

any body else? comments? thanks in advance!

Hi bap3, Please refer to the following links, Specifying Connections and Credentials for the ReportViewer Web Server Control: http://msdn.microsoft.com/en-us/library/aa983458%28v=VS.90%29.aspx Custom Credentials in the Report Viewer: http://blogs.msdn.com/b/brianhartman/archive/2008/11/21/custom-credentials-in-the-report-viewer.aspx Hope it helps. Thanks, Eileen Forum Support Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.