sql server reporting services: Custom reporting services extension needs expert clarification -- sql server reporting services

You're in the

sql server reporting services

group:

Custom reporting services extension needs expert clarification

nickpup
3/23/2006 9:40:32 AM

sql server reporting services:

Two of the seminal concepts of IT security are authentication and
authorization. They underly our ability to control access to our systems.
In simple terms, authentication is the who, and authorization is the what.
We build security to control who, can do what. I reiterate because it
pertains to my question, as I will explain.
We have developed custom membership and role providers in our ASP.NET 2.0
application. They are up and running. Our application is a reporting front
end at heart. We are integrating SSRS (SQL Server Reporting Services 2005).
We need to extend our custom security into SSRS. So we are working on a
custom security extension.
Once a custom security extension is implemeted, will the SSRS report manager
retrieve a list of our (custom) roles so as to support assigning permissions?
Once I thought about this, I realized I might be a bit confused, which is
not at all uncommon.

I think the use of the word roles is confusing here. Under SSRS default
security, roles refer to groupings of permissions, or capabilities, ie,
things principals (people) can do. But we also have a custom role provider,
in our ASP.NET application. In this case, role refers to the groups of
users, ie, who they are, not what they can do.

The nomenclature notwithstanding, implementing custom security extensions in
SSRS allows the system to recognize our custom set of users. Does it
however, allow the SSRS roles (groups of capabilities) to also be replaced?
I think this latter function can be done in report manager. Am I on the
right track here or am I still experiencing confusion between authorization
and authentication. Can anyone clarify?
nospam-Nickpup@yahoo.com

Re: Custom reporting services extension needs expert clarification

Chris Taylor
3/24/2006 1:28:43 PM

Hi Nick,

I understand how this can get confusing, I had a hard time understanding it
as well.

When talking about "roles" in SSRS we are talking about nothing more than
strings being compared. SSRS itself doesn't do any role management persay,
it just verifies with the authuroziation extension that the name in an ACE
(Access Control Entry) matches the name of the user/group being queried.

On OdeToCode there is an article about how you integrate roles into SSRS.

Now, Once you get that completed here comes the next step un understanding
it.

When the auth provider fires up on a request it will pull the user/role
information from your custom membership provder and (with the help of the
odetocode article) load that data into memory or something of the like.

Report server allows you to assign users/roles to various report items
(which then creates an ACE). Al you have do is put in the rolename in the
ACE and SSRS does the rest.

So lets say you havea folder called /ClientReports on your root drive, and
in your membership provider you have a group called "Report Viewers"

Under the security tab of the /Clientreports folder you would assign the
role "Report Viewers". Once you click ok the authorization/authentication
system calls the implementation for VerifyUser which vefies against the
provider that that user/group exists (it doesn't really care how you do it,
just as long as it gets a true/false back).

Ok, so now you have your group/role assigned, the OdeToCode article shows
you how to check for both user and group assignment and how to do it
quickly.

Here is another intersting article that seems to show it with the
MebershipProviderModel

http://blogs.msdn.com/bimusings/archive/2005/12/05/500195.aspx

hth,
Chris
[quoted text, click to view]

Re: Custom reporting services extension needs expert clarification

nickpup
3/26/2006 2:53:48 PM

Chris:

Thats very helpful - thanks.

But, will SSRS pull up my custom roles (which are different from the SSRS
notion of roles)?

I would expect authorization to use the Role provider which we have already
developed, rather than *(or in addition to) our membership provider. Our
Membership provider knows only about our individual users, not the groups of
users (which we call roles). Our role provider knows about those. Does that
make sense?

Thanks again,
Nick

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the sql server reporting services group.

home · blog · groups

Questions? Comments? Contact the dn