Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

Securing Reporting Services Reports Expand / Collapse
Author
Message
Posted Tuesday, May 18, 2010 1:41 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, November 10, 2011 3:04 PM
Points: 4, Visits: 54
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.
Post #923877
Posted Tuesday, May 18, 2010 1:51 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, September 25, 2013 5:45 PM
Points: 5, Visits: 69
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 !
Post #923883
Posted Tuesday, May 18, 2010 2:04 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, November 10, 2011 3:04 PM
Points: 4, Visits: 54
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.
Post #923889
Posted Tuesday, May 18, 2010 2:11 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, September 25, 2013 5:45 PM
Points: 5, Visits: 69
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 ...
Post #923894
Posted Wednesday, May 19, 2010 3:22 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 4:03 AM
Points: 10, Visits: 158
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
Post #924140
Posted Wednesday, May 19, 2010 4:42 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, June 6, 2014 7:41 AM
Points: 41, Visits: 165
Hi thank you all for your comment.

I think it is available in standard edition too.
I am not sure for the express edition?

Post #924166
Posted Wednesday, May 19, 2010 11:11 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 8:43 AM
Points: 12, Visits: 71
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.
Post #924521
Posted Friday, May 21, 2010 7:16 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 9:43 PM
Points: 697, Visits: 155
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 .
Post #925928
Posted Friday, May 21, 2010 7:38 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 9:43 PM
Points: 697, Visits: 155
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.
Post #925946
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse