Dimension Security in SSAS & SSRS

Question

I am stuck with a problem of implementing security at dimension level in SSAS. Here is what I did - 1. Defined a role in SSAS and applied security at dimension level (Unchecking cube dimensions that I don't want this role to access and setting Allowed & denied Sets). 2. Tested using Cube Browser, it worked fine. 3. Tested using SSRS, no change, I was still able to query the dimensions & get results that I don't want.

Question - Is it possible to propagate the security I define at Cube level to SSRS? I would like to believe yes it is.

If yes then here is what I need -

1. Users will logon to the Report Manager using Windows Identity (Integrated Authentication on IIS turned on -done)
2. Capture this identity to find out SSAS role that they belong to - I guess this would be through a query, does not seem to work automatically (How to do this?)
3. User works within the restrictions of this role in SSRS (role based security applied at SSAS level) i.e. if dimension X is not available to user, he/she should not be able to query it. (How to do this?)

I have referred quite a few blogs on this and even found one - http://www.sqlmag.com/Article/ArticleID/96763/sql_server_96763.html

but this one seems to have more information on how to set it up within SSAS, rather than how to use this in SSRS.

Anyone who has worked on this approach OR have an understanding of this please let me know.

Answer 1

I think you need to look at your datasource in SSRS on the report server, and make sure it is set to use the logged in users windows cred's once authenticated, it might be what you are looking for.

Answer 2

All you need to do is:

In the data source in SSRS report, specify the Role Name created in SSAS database like this:

Data Source=LOCALHOST;Initial Catalog=XXXXX;Roles=RoleName

Thanks Sameer

Answer 3

I haven't done this in SSAS, but I've done it in the engine. Jeremiah Peschka has a blog about row-based security setup, and if you're going to do this with integrated Windows security, then you can use the user_name() function to grab the current login's name. You'll be using a lookup table for each dimension, with a row for each dimension row plus the user's name. When querying, join to the dimension security table like this:

FROM dbo.Customers cs
INNER JOIN dbo.CustomersSecurity css ON cs.CustomerId = css.CustomerId AND css.UserName = User_Name()

That way, your join will only return records for customers that the user can see.

The drawback is that if you're using partitioning, the engine won't build a good execution plan to only pluck the right records from the right partitions based on what your user can see. For example, if you log in as a user that can only see records in Florida, and your data is partitioned by state, it won't matter - the engine will still scan all partitions, because it won't be able to predict the user's info when the plan is built.