Hello,

I would need to discuss the details with our developer teams since I have not received any updates from them. If I am not mistaken, we only provide the viewer. The security is already handled by Microsoft (API).

Regards,
Handy

Let me give you a little more detail on how our current reporting works with an Asp.Net application and SSRS Report Server.  Please note, I'm only concerned with Security for public facing Silverlight applications.  (No Intranet).  I'm also interesting in Remote report processing from the SSRS Report Server.

Current Method:

1. Our Asp.Net application is configured with Forms Authentication (it is a public facing web application)
2. It uses the Asp.Net version of Microsoft's ReportViewer control
3. SSRS is configured with Windows Security only.  Users in Asp.Net application can only run reports using the ReportViewer through the Asp.Net application.  They don't login to Report Server directly. 
4. Report Server sits behind firewall and Reporting Web Service is not public facing.
5. When a report is run from a web form in Asp.Net app, the ReportViewer.ServerReport.ReportServerCredentials are set once in page load to the user ID of application pool used by the Asp.Net application.  So even though web application uses forms authentication for end users the ReportViewer authenticates to ReportServer Web Service using Windows Authentication.  So we basically use an Windows "Application User ID" between asp.net and SSRS Reporting Server via the asp.net ReportViewer control...similar to how you would configure a db connection for a web app to leverage the connection pool.
6. We limit access to the reports by locking down access in the Asp.Net web application.

Obviously, your new Silverlight ReportViewer runs on the client (versus server using Asp.Net ReportViewer).  So I realize we will need to make some changes, but what? 

1. I assume we will have to publish the SSRS Web Service through our firewall for public access?
2. Will we have to change the SSRS Report Server Security to Forms Authentication?  If so, that will be a pain. 
3. Or Will your Report Viewer call some kind of Http handler that will allow us to set the ReportServerCredentials using a Windows Identity and call the SSRS Web Service?  Authentication to the hander would use forms authetication.  This would be more similar to how the Asp.Net ReportViewer works. (which is much better since we won't have to change SSRS server security). This way Silverlight can pass the forms auth cookie to http handler for user authenciation and http handler talks to SSRS serve using Windows credential.  Possibly?
4. If not, how will one be able to set ReportServerCredentials from your ReportViewer?

That's about it for now.  Any help much appreciated!

Handy? Anybody?  You there?

Hello,

Thanks for your patience. We've discussed your questions with our development team. Here the result goes.

First of all, our SqlReportViewer will not require you to change the topology of your existing SSRS deployment. That's made possible because we will ship a server-side handler for the SqlReportViewer which processes the communication between the client and server. This also means that you can continue to use your existing security settings, whether it is Windows Authentication or Forms.

Secondly, the server component of our SqlReportViewer will use default windows credential when communicating with the actual SSRS web services. You can override both the credentials and the impersonation level by deriving the handler class and overriding the provided virtual properties.

Finally, you can use Forms authenthication to handle the security between the client and the server that hosts the SqlReportViewer's HTTP handler. This allows you to have granular control over how your applications should behave based on user's roles.

I hope you've now got clearer picture on our upcoming SqlReportViewer. Please feel free to let me know if you have any questions.

Thanks,
Jimmy

That's great news!  You guys are awesome!  I can't wait to check it out! 

Reporting is the one area that has forced us to hold off on our ASP.Net migtration to Silverlight.  The fact that we won't have to re-write all our SSRS Server reports by leveraging your SQLReportViewer control is a huge benefit.  Thank you! Thank you! Thank you!