Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Securing Reporting Services Reports


Securing Reporting Services Reports

Author
Message
Jim Barnes
Jim Barnes
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
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.
rbarbati
rbarbati
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
Points: 9 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 !
Jim Barnes
Jim Barnes
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
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.
rbarbati
rbarbati
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
Points: 9 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 ...
rama.mathanmohan
rama.mathanmohan
Grasshopper
Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)

Group: General Forum Members
Points: 14 Visits: 164
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
Mohamed I.
Mohamed I.
SSC-Enthusiastic
SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)SSC-Enthusiastic (156 reputation)

Group: General Forum Members
Points: 156 Visits: 348
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
JP-470
JP-470
Grasshopper
Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)

Group: General Forum Members
Points: 12 Visits: 76
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.
amit_adarsh
amit_adarsh
Say Hey Kid
Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)

Group: General Forum Members
Points: 702 Visits: 169
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 .
amit_adarsh
amit_adarsh
Say Hey Kid
Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)Say Hey Kid (702 reputation)

Group: General Forum Members
Points: 702 Visits: 169
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search