Security Configuration Setup and Model suggestions

Question

Post reply

Security Configuration Setup and Model suggestions

hawkeyeboy

Old Hand

Points: 340
More actions
April 17, 2007 at 11:26 am

#173082

Hello everyone,

I'm interested in tapping into the expertise of the group and open a discussion on how you have set up your security model for RS.

As I'm sure in the case with many of you, my company has both users inside (intranet) and outside accessing reporting services. I'm comfortable handling the internal security thru the use of roles such as Admin, Mgr and Browser. Where I'm interested in hearing your experiences and best practice suggestions is for those users outside the corporate structure.

For instance I'll have numerous clients coming in to get reports but each client should only have access to view and run only their reports. How should this be handled? Anonymous logging into the site? Should each client have one log in name or multiple users from each? The later would seem to make the administrative tasks of setting up and managing security more difficult.

Here's a small example of an issue: I find it awkward that users can show or hide details. So they can see objects but, if security is configured properly, can't interact with the object. Is there a way to customized RS to not have the ability to show/hide? I would prefer the interface be set up to show those users what I want them to see. Not let them see it but not have the authority to interact with it.Have any of you completed some customized programming to address this issue or other security issues within RS?

I realize this is a large topic for discussion but I'm very interested in hearing the voice of experience from those of you who have already crossed this bridge and deployed your RS site(s).

Thank you in advance - Eric aka hawkeyeboy

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

David McFarland SSChampion Points: 11815 More actions · Answer 1

Is a wrapper around the ReportViewer control an option? We use such a beast, and it makes things a bit easier to handle, although getting up to speed can be a struggle at first. The users log into the wrapper, and then the wrapper decides what reports they can and can't see, and we even pass some hidden parameters behind the scenes. This allows us to not only limit what reports they can see, but even what values are available in dropdowns, how much of the data they can see, etc. The wrapper itself has no hardcoding of report paths, as it looks in a given folder based on what app the wrapper runs under, and then gets the children that the given user is allowed to see. This allows us to make report changes, add new reports, etc., without having to deploy a new wrapper.

Lynn Pettis SSC Guru Points: 442447 More actions · Answer 2

Lynn Pettis

SSC Guru

Points: 442447

April 17, 2007 at 12:02 pm

#700988

David,

I'd be interested in learning more about this wrapper you use. What, where, how much, are the basic questions, plus where can I learn more.

hawkeyeboy Old Hand Points: 340 More actions · Answer 3

Hi David,

Thanks for the reply. Yes, we are considering a Sharepoint site deployment using the report viewer and browser web parts. It seems this maybe the most straight forward way of "separating" one client from another client's reports without going into any extra programming gymnastics.

I'm currently finding the RS security model a bit clumsy and not as rich in flexibility as the network admin. guys would like. What are your thoughts?

-Eric

David McFarland SSChampion Points: 11815 More actions · Answer 4

What? A custom (several actually, for our different web applications) C# web app.

Where? In-house.

How much? Can't sell it, but can help you build your own.

We basically started with the ReportingServices webservice and played around, alternatively making progress and fumbling over weird issues (almost always firewall/permissions related). When we began there weren't a lot of people doing it, so googling wasn't really an option. I'll give you the nutshell version for now, but will happily elaborate more in any area that you'd like.

We already had an in-house role-based security model for our apps, so when someone logged in, we had both a user identifier as well as a role. Note that the role was app based and didn't correlate with NT or SQL roles in any way. We decided to leverage that. We create local accounts on the RS server for each of those roles, and therefore can limit what reports a user sees, as the app logs in as that "user" when they are checking what reports are available to them. We then use userids as hidden parameters which are passed to the stored procs that build dropdowns, as well as return data, so that we can limit what they can work with at that level. We have a few special things we do, such as context menu based reports, and we handle that sort of thing by using special prefixes in report names (which the app then strips off), as well as passing the context data via hidden parameters. The nicest thing is that the reports are independent of the app iterations.

The basics of the RS webservice are actually pretty easy, once you've done them. I could outline them here, but I recently found something that I wish I had had back when we started, the RSExplorer sample app from MS. I'd download these samples from MS, and take a look at RSExplorer. It shows you most of what you'll need to know about the methods, properties, events, etc. Since we've now done it four times, I'll happily fill in the blanks.

hawkeyeboy Old Hand Points: 340 More actions · Answer 5

Thanks for the information David. I'll check out the RSExplorer samples you suggested.

I also tested out the Report Explorer web part in conjunction with Sharepoint and it worked very nicely in limiting the scope of what each client could/couldn't view. There are a few things I would like to tweak regarding the viewer...hopefully the samples include some customization tips/code to start with.

-Eric