Report Model Security

Hello
Is it possible to filter data within a report model (.smdl). We have a
generic report model that we wish to limit, based on user credentials?
Kind regards
Ricky
(SS2005)Ricky,
Yes that's possible. Have a look at the documentation under "Security
Filters".
Also a good summary can be found here:
http://blogs.msdn.com/bobmeyers/articles/Implementing_Data_Security_in_a_Report_Model.aspx
You'll use the GetUserId() function in the model to tie to your data.
-Krip|||Thanks Krip.
Incidentally, did you manage to get your issues resolved?
"Krip" <anonymous@.anonymous.com> wrote in message
news:C71CBA81-089F-4091-9C6D-21F71FAA7AAB@.microsoft.com...
> Ricky,
> Yes that's possible. Have a look at the documentation under "Security
> Filters".
> Also a good summary can be found here:
> http://blogs.msdn.com/bobmeyers/articles/Implementing_Data_Security_in_a_Report_Model.aspx
> You'll use the GetUserId() function in the model to tie to your data.
> -Krip
>

Report Model Data Security

Hello
I have designed a report model, but now have a requirement to limit data
access to certain people. I have tried researching about Role based
security, but nothing seems to make sense. I have to design a suite of
reports 16 in total. However,I have 8 users, all looking at data from
difference business departments. It has been requested that each department
cannot look at another department's data. The thought of cloning these 16
reports, 8 times over, does not seem like a viable option.
Is there an alternative?
Kind regards
Ricky
(SS2005)If you are saying that each report needs to be viewed by each dept and that
the data should be different on the report depending on who is viewing it
then:
On your reports you can have a hidden extra parameter that defaults to the
user id.
Then pass this id into your stored procedures that generate the data.
The stored procedures will do the filtering based on your own internal logic.
"RickyP" wrote:
> Hello
> I have designed a report model, but now have a requirement to limit data
> access to certain people. I have tried researching about Role based
> security, but nothing seems to make sense. I have to design a suite of
> reports 16 in total. However,I have 8 users, all looking at data from
> difference business departments. It has been requested that each department
> cannot look at another department's data. The thought of cloning these 16
> reports, 8 times over, does not seem like a viable option.
> Is there an alternative?
> Kind regards
> Ricky
> (SS2005)
>|||Hi Jimbo
Thanks for your post, but the model cannot not based on an SP, it is created
from a View.
Kind regards
Ricky
"Jimbo" <Jimbo@.discussions.microsoft.com> wrote in message
news:B3DF6CA7-175E-42E7-A432-C023612E582D@.microsoft.com...
> If you are saying that each report needs to be viewed by each dept and
> that
> the data should be different on the report depending on who is viewing it
> then:
> On your reports you can have a hidden extra parameter that defaults to the
> user id.
> Then pass this id into your stored procedures that generate the data.
> The stored procedures will do the filtering based on your own internal
> logic.
>
>
>
> "RickyP" wrote:
>> Hello
>> I have designed a report model, but now have a requirement to limit data
>> access to certain people. I have tried researching about Role based
>> security, but nothing seems to make sense. I have to design a suite of
>> reports 16 in total. However,I have 8 users, all looking at data from
>> difference business departments. It has been requested that each
>> department
>> cannot look at another department's data. The thought of cloning these
>> 16
>> reports, 8 times over, does not seem like a viable option.
>> Is there an alternative?
>> Kind regards
>> Ricky
>> (SS2005)|||Your sp can read from the view :)
"RickyP" wrote:
> Hi Jimbo
> Thanks for your post, but the model cannot not based on an SP, it is created
> from a View.
> Kind regards
> Ricky
> "Jimbo" <Jimbo@.discussions.microsoft.com> wrote in message
> news:B3DF6CA7-175E-42E7-A432-C023612E582D@.microsoft.com...
> > If you are saying that each report needs to be viewed by each dept and
> > that
> > the data should be different on the report depending on who is viewing it
> > then:
> >
> > On your reports you can have a hidden extra parameter that defaults to the
> > user id.
> >
> > Then pass this id into your stored procedures that generate the data.
> >
> > The stored procedures will do the filtering based on your own internal
> > logic.
> >
> >
> >
> >
> >
> >
> >
> > "RickyP" wrote:
> >
> >> Hello
> >>
> >> I have designed a report model, but now have a requirement to limit data
> >> access to certain people. I have tried researching about Role based
> >> security, but nothing seems to make sense. I have to design a suite of
> >> reports 16 in total. However,I have 8 users, all looking at data from
> >> difference business departments. It has been requested that each
> >> department
> >> cannot look at another department's data. The thought of cloning these
> >> 16
> >> reports, 8 times over, does not seem like a viable option.
> >>
> >> Is there an alternative?
> >>
> >> Kind regards
> >>
> >> Ricky
> >> (SS2005)
> >>
>|||Hi Jimbo
Thanks, but I think you must be confused, or maybe I have not stated my
scenario clearly. I have built a Report Model, to be used in Report
Builder, there is no facility to use SP's, maybe I have misunderstood what
you mean?
Kind regards
~Ricky
"Jimbo" <Jimbo@.discussions.microsoft.com> wrote in message
news:2CB0DA49-ED42-4E2F-8326-93322C0F429A@.microsoft.com...
> Your sp can read from the view :)
>
>
> "RickyP" wrote:
>> Hi Jimbo
>> Thanks for your post, but the model cannot not based on an SP, it is
>> created
>> from a View.
>> Kind regards
>> Ricky
>> "Jimbo" <Jimbo@.discussions.microsoft.com> wrote in message
>> news:B3DF6CA7-175E-42E7-A432-C023612E582D@.microsoft.com...
>> > If you are saying that each report needs to be viewed by each dept and
>> > that
>> > the data should be different on the report depending on who is viewing
>> > it
>> > then:
>> >
>> > On your reports you can have a hidden extra parameter that defaults to
>> > the
>> > user id.
>> >
>> > Then pass this id into your stored procedures that generate the data.
>> >
>> > The stored procedures will do the filtering based on your own internal
>> > logic.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > "RickyP" wrote:
>> >
>> >> Hello
>> >>
>> >> I have designed a report model, but now have a requirement to limit
>> >> data
>> >> access to certain people. I have tried researching about Role based
>> >> security, but nothing seems to make sense. I have to design a suite
>> >> of
>> >> reports 16 in total. However,I have 8 users, all looking at data from
>> >> difference business departments. It has been requested that each
>> >> department
>> >> cannot look at another department's data. The thought of cloning
>> >> these
>> >> 16
>> >> reports, 8 times over, does not seem like a viable option.
>> >>
>> >> Is there an alternative?
>> >>
>> >> Kind regards
>> >>
>> >> Ricky
>> >> (SS2005)
>> >>
>>|||Hello!
Im in the same situation as you. What we have done is that we have used the
feature "Default Security Filter" which allows
you to filter data using an entity which you base upon your view containing
DepartmentID/userID. The entity should also include
an attribute which contains the calculated "GETUSERID()".
You then specify a reliation between your entities to be filtered and this
filter-entity and you also set the "Default Security Attribute"
to be this filter-entity.
Thing is that this causes RS to produce even worse-looking SQL and makes it
hard to debug so Im currently trying to
figure out some other way, because it is almost impossible to debug 300
lines of SQL (most of it rs-schmuck).
Anyway - you can try it out, but try and read up on it on the web somewhere
first...
David|||Hi David
Thanks for your post, it seems like there isn't much in the way of security
on the net at the moment, I can't believe we're the only ones trying to
achieve this? I look in to this further - thanks Daivd.
Kind regards
Ricky
"David" <david_sundstrom_sandegard.nospam@.hotmail.com> wrote in message
news:2C9C703C-BA30-4EAA-ABEA-79F0DE457287@.microsoft.com...
> Hello!
> Im in the same situation as you. What we have done is that we have used
> the feature "Default Security Filter" which allows
> you to filter data using an entity which you base upon your view
> containing DepartmentID/userID. The entity should also include
> an attribute which contains the calculated "GETUSERID()".
> You then specify a reliation between your entities to be filtered and this
> filter-entity and you also set the "Default Security Attribute"
> to be this filter-entity.
> Thing is that this causes RS to produce even worse-looking SQL and makes
> it hard to debug so Im currently trying to
> figure out some other way, because it is almost impossible to debug 300
> lines of SQL (most of it rs-schmuck).
> Anyway - you can try it out, but try and read up on it on the web
> somewhere first...
> David

REPORT MANAGER - Hiding Tabs/Links ***

Is there a way to hide Tabs and Links on the REPORT MANAGER interface to
limit user access? If you can provide and example that would be highly
appreciated.Yes, you want to limit access using security. On the properties tab of any
item there should be a security sub-tab which will allow you to set what
users can and can't do with that object. Depending on a users rights only
tabs that a user can use will show up.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mike Collins" <MikeCollins@.discussions.microsoft.com> wrote in message
news:7F502733-69FE-4C4A-A16B-02E6A3192933@.microsoft.com...
> I'm not an expert on this, but you can limit user access through IIS. Make
> sure anonymous access is not checked in your security in IIS. Then through
> the Report Manager, you can add users (or groups) and give them certain
> access rights.
> "doug" wrote:
> > Is there a way to hide Tabs and Links on the REPORT MANAGER interface to
> > limit user access? If you can provide and example that would be highly
> > appreciated.