May 18, 2010 at 9:56 am
Interesting solution to security for SSRS. I think I would weigh heavily the comments made in this discussion when looking to secure reports in SSRS.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 18, 2010 at 10:26 am
Nice article. We have hundreds of reports with tens of agencies accessing those reports restricted to only their data. My solution to this was creating a stored procedure which looked up their user id from this parameter and returned their coresponding agency. There was an agency table with a listing of agencies and users and their user ids.
Then in the dataset that returned the report data, only the data for agency to which the user belong was returned.
This allows many users from different agencies to view the same report, but with only their data.
(58.30115757480578, -134.4143772125244)
May 18, 2010 at 11:16 am
Seems like a good way to hide protions of a report from specific people, but i dont' understand why you would hide an entire report when you can just hide it using SSRS's security.
May 18, 2010 at 11:22 am
We implemented a solution that combines the features mentioned here, along with a table sub-struture and temporary login tokens.
The user is detected, we drill into the transactional data itself to determine if they should have access (as our security model is quite complex with multiple user roles and such), we enter a token along with userID into a table and that is the validation key.
It is all sproc driven and adds little overhead to the reports themselves once established.
The URL backtracking mentioned above is a key factor and is why we introduced the tokens.
If not the same user, and not within a 30 min period, the URL itself actually expires. (but easily regenerated in the background for any valid user on return - if needed)
There is some setup and coding, but it's a nice combination of the different topics mentioned in this article.
Good reading - thanks !
May 18, 2010 at 11:23 am
This method is good for a small and stable pool of users and reports. However, we find it more practical to control access through AD groups. We are too short handed to administer additions and deletions of individual access for a couple thousand users against several hundred reports.
May 18, 2010 at 1:41 pm
We use AD lookups to authenticate users. As opposed to authorization to view/not view, which is handled in an assembly. Given that security is a fairly common piece of functionality for all of our reports it's easier to maintain 1 dll than N code blocks. We do keep a local user table that the assembly calls to figure out who can see what that's populated from a daily SSIS job that runs against our HR database which is maintained daily.
May 18, 2010 at 1:51 pm
Never one to shoot down an opportunity to learn, I'd be curious how AD has been implemented to address the granularity of securables needed in a large enterprise ?
Just as examples, lets say:
You have a regional sales rep, a regional sales manager, a corporate sales director, and a president.
(to keep it limited - but feel free to expand that realistically about 20 fold)
The Rep can see just his/her data, the regional mgr only data for their region, the sales director all "sales" data for all regions, the president any and all data.
Now add complexity.
The regional mgr is now a member of a specialized task team which expands visibility beyond that of other regional mgrs.
The sales rep now works dual roles and part time supports another region or another division .
Note that I mention both reports AND data.
We secure data, not just the reports used to view it.
One report , based on automated security will expose differing levels of data.
Not 10 reports with different filters, one report with dynamic data level security.
How does AD address this ?
Is there a slick solution we might be exploring ?
It is something I'd be very keen on :o)
(and to address the other comments, yes, thousands of users and hundreds of reports...)
Thanks all !
May 18, 2010 at 2:04 pm
like i said, we just use AD to authenticate users, not authorize view access. Authorization is handled locally via an ACL (access control list) table that's refreshed nightly from HR app data. Our requirements were to show/not show reports and sections of reports based on a business unit hierarchy and who could see what part of that tree (hence the need for an ACL table). Our ACL maps nodes in the tree to users. If you have an entry for a node you see that node and all siblings. No node = no see. We built a ui to mantain that list and mapping. I work in a huge enterprise.
May 18, 2010 at 2:11 pm
Groovy, I'm following you.
"ACL" is actually how we name tagged our implementation as well (although it's a custom hybrid of sorts, in a very dynamic and ever changing environement)
Transactional data in the end, along with control lists, dictates the rendered dataset
And this actually negates the need for any additional security.
reports access is granted to everyone, but if you are not who you are supposed to be, your report runs for 1 second and returns nothing.
Thanks for the posts..tapering off here ...
May 19, 2010 at 3:22 am
Hi It is a greate article. Am I correct in saying this fearure (ability to capture the user) is only avilable in Enterprise Edition ? Can somebody help me on this
May 19, 2010 at 4:42 am
Hi thank you all for your comment.:-)
I think it is available in standard edition too.
I am not sure for the express edition?
:w00t: !!!GOOGLE IS YOUR BEST FRIEND!!! :w00t:
May 19, 2010 at 11:11 am
We also have an "ACL", but it provides access control through the main application rather than Report Manager. These users see an interface which captures their location and ID to assess their authorization to access portions of the application and limit the data viewed in standard reports : facility; region; all; facility and region cross-over; HR; admissions; billings; add; edit; view; etc.
However we have a group of non-IT users who are empowered to write their own adhoc and standard reports that may or may not be made accessible through the applications and may have a different audience than the application users. This group has use of development tools, deploy their own reports and access Report Manager directly. This group is sub-divided into various organizational units as they see fit, which correspond to AD groups: each group then is granted control over their leg of the Report Manager tree, their tables and their views (SELECT only). It is the user responsibility to control access via security requests implemented by the I.T. department.
As an aside: this has been a boon for us as it satisfies the psyche of the user who always complained that I.T. was not on the ball; now they can complain among themselves when a report is late.
May 21, 2010 at 7:16 am
HI
Hust try these steps
1) Double click on data source
2) select credentials and then fill the required user info
like windows authonication or other way
if its ok then you have to check previlages on the system where you want to deploy your reports .
May 21, 2010 at 7:38 am
By this way you are not able to hide this report by user Because when user log he will be able to see all the reports name(menu) and when he click on the report it will show your customized message or error .
But Best we to deal with these types of issue is "Hide this report from menu" because he has no permission to see this report .you can do it by using report manager.
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply