CODEWITHSUNDEEP
web-servicessecurityreporting-servicesreport
JoeBrockhaus
JoeBrockhaus

Reputation: 2793

ssrs web service: basic permissions required for web service access?

I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.

The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles. 

 Web Role   | SSRS User

Admin       | AdminUser
Supervisor  | SuperUser
User        | BasicUser
Guest       | GuestUser

The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.

More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.

Everything works OK when the user is the AdminUser.

However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)

This is problematic for a couple reasons:

  1. If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
  2. If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.

It seems this leaves me with 2 less than ideal options:

  1. Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
  2. Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.

#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.

Is there a better way? Have I missed something obvious?

[edit]

A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.

As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.

Upvotes: 1

Views: 1641

Answers (1)

JoeBrockhaus
JoeBrockhaus

Reputation: 2793

The best solution would have been to query the ReportServer database directly.

However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!

Upvotes: 0

Related Questions