SSRS Web Service Security

Question

I have an ASP.NET web application that uses calls to the SSRS web services ReportService2005.asmx and ReportExecution2005.asmx.

The technology used is ASP.NET 3.5, Visual Studio 2008 and SQL Server 2008 R2 (I'm using ReportService2005 as I'm utilising a code library that uses this rather than ReportService2010)

A user logs onto the system using Forms Authentication. The user then navigates to a reporting page. The user can belong to any number of report groups (each group can contain any number of reports). The report groups, their associated reports and the users assigned to the report groups are controlled by a page within the web application and stored in a series of tables in the web application database (NOT the SSRS database).

Currently access to the ReportService2005.asmx and ReportExecution2005.asmx is achieved by using the default credentials of the server. Is this secure? All of the reports on the server would be accessible via this one default credential. The only restriction on the reports a user can see would be enforced by the frontend application which could presumably be hacked using e.g. Javascript?

What I would like is a method where I can do away with the series of report/user/group tables in the web application database and use the SSRS schema. For example:

User A (employee of company A) belongs to the Finance report group and the Marketing report group. The Finance group contains Finance Report 1 and Finance Report 2. The Marketing group contains Marketing Report 1.

The above reports would be placed in Finance and Marketing folders on the report server (using the Report Manager).

I could then create a Windows User (let's call it MarketingFinance) on the report server and give that user the appropriate permissions on the Marketing and Finance folders. User A would then have to have some sort of flag in his/her .net membershipprovider profile to link to the MarketingFinance user.

The problem with this though is that I envisage a new Windows User having to be created on the report server every time a custom report group is created/modified. Using the above example say a Sales report group is created and User B is added to it. Now there has to be a Windows User (Sales) on the report server with the appropriate permissions set to access the Sales folder. Also multiple clients of the web application will want their own versions of the Sales/Marketing etc. groups potentially multiplying the number of Windows Users into the many thousands!

I'm a newbie to SSRS so may be looking at this the wrong way - can I use roles to simplify this problem?

Also the reports are likely to be mostly the same across companies (by company I mean a client of the application) but each company might want the reports setup in different folders. i.e. Company A Finance folder has Report A, Report B and Report C in it but Company B Finance folder only has Report A in it. Presumably report links will prevent me having to have 2 physical copies of Report A in both folders?

Answer 1

You've got a few different questions rolled into one, but I'll try to address the fundamental question of "Will setting up SSRS access with multiple distinct accounts increase my security?"

... Is this secure?

Secure isn't a binary thing: The question should be rephrased as "Is this secure enough?" And the answer to that depends on the data you are holding, the exposure of the application and other considerations. (Sales figures on an internal company app should get a different answer than large firm's R&D findings published to the internet.)

The only restriction on the reports a user can see would be enforced by the frontend application which could presumably be hacked using e.g. Javascript?

Seems like breaking out the Reporting Services users to different accounts doesn't do much to address this concern. If someone can get to another user's page currently, what would changing the SSRS credentials change? If you are relying on client-side Javascript to provide the SSRS report they need to access, then you should check this on the server side to make sure they aren't requesting something improper.

I would focus on making sure that the SSRS server isn't directly accessible from the internet, and then I would work on securing your application. If you have reason to believe your site is vulnerable via someone altering your Javascript, then address that problem.

Putting the user access to SSRS into silos like this doesn't make much sense to me as a security precaution unless your front end application has very separate silos itself. It might keep things manageable and avoid errors, but I don't see much additional security.

(Also, your proposed solution would add more passwords stored somewhere, and those usually deserve a little extra protection, so you might be setting up a larger problem.)

This is one geek's view; your mileage might vary; my two cents...