Bob's SQL Reporting Services Blog : Model Security

Considerations for a large report model

bobmeyers — Mon, 27 Apr 2009 23:58:00 GMT

Customer report models that vary in size from a few to a few hundred entities. Little Northwind with its 10 or so entities comes in around 200K, but we've seen models a hundred times that size (over 20 MB). One of the key drivers of model size is the constraint that you cannot build a query across multiple models, so the tendency is to pull more and more data into the "main" model.

Given that, I thought I’d share a few tips that may help if you want to build, deploy, and use a large report model.

1. Configure the report server allow upload of large files. By default ASP.NET limits the file upload size to 4 MB. You will need to modify this setting if your model exceeds the limit.

2. Consider removing the diagrams from the DSV. Typically the diagrams in a DSV account for ~20% of the uploaded model size. This information is only used by Model Designer, however, so removing it will not affect either the report server or a client like Report Builder. The DSV editor will not allow you to remove the default “<All Tables>” diagram, and if you do remove it, the editor will recreate it with a default layout the next time you open the file, so you will need to remove this diagram from the XML manually before publishing.

3. Define perspectives in the model. Perspectives allow users to self-select a convenient subset of the model at the time they design the report. This reduces download time (only the subset is retrieved by Report Builder) as well as clutter during the design experience. In extreme cases, you may want to require users to choose a perspective. Note that perspectives are not a security feature. Also note that it is possible, though not particularly easy, to change the perspective used in a query after the query has been created.

4. Use model item security. This reduces the subset of the model available to specific users and groups, which in turn reduces the download time and visual clutter for those users. Note that as of SQL 2008 report subscriptions are not supported when using model item security.

If you are using a large report model and have additional tips or questions, please contact me. We'd love to get your feedback.

How to create a 'company' security filter for a hosted application

bobmeyers — Sat, 25 Mar 2006 04:02:00 GMT

Several customers have asked how to restrict data visibility in a report model for a hosted application, where every table has a "CompanyID" column, and every user that accesses the system is associated (via some other table) with exactly one company. The straightforward solution is to create a security filter on each corresponding entity; the filter should check whether any rows exist in the user table entity where Users.CompanyID=This.CompanyID and UserTable.UserID=GETUSERID(). This will work, but the SQL that is generated for this filter may not be optimal.

~~An alternative is to modify the DSV for the report model such that each table containing a CompanyID is really a named query of the form:~~

~~SELECT t.*, u.UserID FROM MyTable t, UserTable u WHERE t.CompanyID = u.CompanyID~~

Note that this derived table contains n rows for each row in MyTable, where n is the number of users associated with that row's company. To effectively fool the model, you will need to lie in the DSV and claim that the primary key of your derived table is composed of only the key columns for MyTable.

You must then create a security filter on the corresponding model entity for MyTable, which simply states UserID = GETUSERID(). If you create any other security filters for that entity, they MUST contain the same filter condition, in addition to any other conditions. No user should be given access to all the rows of that entity.

~~This approach, while a bit of a hack, should result in much better SQL at runtime.~~

~~Credits to my illustrious colleague~~ ~~Chris Hays~~ ~~for coming up with this.~~

UPDATE: The alternative proposed above does not work correctly in all cases because of an optimization we do in the SQL translation layer. Best practice is to stick with the "straightforward solution" described at the beginning of the post.

Article: Implementing Data Security in a Report Model

bobmeyers — Sat, 18 Mar 2006 21:03:00 GMT

I just posted the first article on my blog. Here's the abstract:

The report models introduced in SQL Server 2005 feature a number of ways to customize the data visible to different users and groups: perspectives, model item security, security filters, and opaque expressions. This article describes when and how to use each of these features.

Comments and feedback welcome!