Custom authorization with forms authentication

We are currently implementing forms authentication in our RS deployment. The
MSDN sample helped get us started. We are now faced with the authorization
implementation.
How do I go about telling RS which user has access to which folder/report?
Telling RS which users will be administrators? Do I still get to use
role-based security and can create/edit my roles through the Report Manager
or do I need to assign indepentent permissions per user?Ray,
Yes, you would establish role-based security policies just like you would do
with Windows-based security. Your authorization extension will have the
final say if the user is authorized to perform a given action. For example,
if you need to implement role membership rules, you can change the
CheckAccess overloads to account for the addtional rights that the user will
get based on her role membership. Debugging the CheckAccess overloads should
help you clarify how this could be done.
--
Hope this helps.
----
Teo Lachev, MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
----
"RayG" <RayG@.discussions.microsoft.com> wrote in message
news:40831253-2400-44A3-8A2E-3FF9171C7510@.microsoft.com...
> We are currently implementing forms authentication in our RS deployment.
The
> MSDN sample helped get us started. We are now faced with the
authorization
> implementation.
> How do I go about telling RS which user has access to which folder/report?
> Telling RS which users will be administrators? Do I still get to use
> role-based security and can create/edit my roles through the Report
Manager
> or do I need to assign indepentent permissions per user?|||Ray,
Let me clarify. The default implementation of a custom authentication
extension as demonstrated in the MS sample relies on the role-based policies
the report administrator has established for a report item. This is very
much the same as the Windows-based role-based security the comes by default
with RS. So, for example if you have a web customer with an id of johndoe
and you want him to view a given report by URL, you can grant him Browser
permissions to that report using the Report Manager. This is pretty much all
you have to do to get John Doe set up for Forms Authentication assuming that
you "inherit" the MS sample code.
At the same time, the Forms Authentication model of RS is very flexible. For
example, it is typically impractical to create role-based security policies
for individual users, especially for Internet-facing applications. Then,
what you can do is to implement additional logic in your CheckAccess
overloads to take in consideration the application role membership your
users have.
The beauty of this model is that the authentication and authorization
implementation is totally outside the Report Server and responsibility of
your extension.
Does this all make sense now?
--
Hope this helps.
----
Teo Lachev, MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
----
"RayG" <RayG@.discussions.microsoft.com> wrote in message
news:B0C6D8D1-B26E-42FA-BB46-CF3918FB15EB@.microsoft.com...
> I think I was under the wrong impression, then.
> Instead of telling RS which user has which type of access to which
resource
> and then letting RS allow or deny access when it receives requests, seems
> like it's me who will decide whether to allow or deny, as I will be
servicing
> the security side of the requests.
> If I am correct and this is the case, how is this role-based security? I
am
> getting a resource and a user and simply responding with a "Yes" or a "No"
> based on my internal logic (security database).
> Please clarify.
> Thanks!
>
> "Teo Lachev" wrote:
> > Ray,
> >
> > Yes, you would establish role-based security policies just like you
would do
> > with Windows-based security. Your authorization extension will have the
> > final say if the user is authorized to perform a given action. For
example,
> > if you need to implement role membership rules, you can change the
> > CheckAccess overloads to account for the addtional rights that the user
will
> > get based on her role membership. Debugging the CheckAccess overloads
should
> > help you clarify how this could be done.
> >
> > --
> > Hope this helps.
> >
> > ----
> > Teo Lachev, MCSD, MCT
> > Author: "Microsoft Reporting Services in Action"
> > Publisher website: http://www.manning.com/lachev
> > Buy it from Amazon.com: http://shrinkster.com/eq
> > Home page and blog: http://www.prologika.com/
> > ----
> >
> > "RayG" <RayG@.discussions.microsoft.com> wrote in message
> > news:40831253-2400-44A3-8A2E-3FF9171C7510@.microsoft.com...
> > > We are currently implementing forms authentication in our RS
deployment.
> > The
> > > MSDN sample helped get us started. We are now faced with the
> > authorization
> > > implementation.
> > >
> > > How do I go about telling RS which user has access to which
folder/report?
> > > Telling RS which users will be administrators? Do I still get to use
> > > role-based security and can create/edit my roles through the Report
> > Manager
> > > or do I need to assign indepentent permissions per user?
>|||Hi Teo,
I am having a problem similar to RayG's, using the forms authentication
sample code. I put some debug statements into the
Microsoft.Samples.ReportingServices.CustomSecurity.Authorization class,
CheckAccess methods. I also commented out the logic in the
AuthenticationExtension and AuthenticationUtilities classes such that all
logon attempts are permitted without password checking (return true).
I found that when accessing report resources using an identity that is
defined in MSRS, that the Authorization.CheckAccess methods are invoked. I
set up security on the Home folder and one subfolder, and was able to use
combinations of groups to restrict access appropriately. I also found that
when you use a logon credential that is not defined in MSRS (that is, not
used in any object's ACL), that the Authorization.CheckAccess methods are not
invoked. For example, I set up a "Users" group, and granted it access to a
folder. Logging on as "Users" I could access this folder. Logging on as
"User" gave me an access denied message, as expected, however, none of the
Authorization.CheckAccess methods were invoked either...unexpected.
This presents a problem, as I am trying to set up groups in MSRS that map to
user groups in my application. It seems that because the
Authorization.CheckAccess methods are not invoked in this case, there is no
opportunity to extend them with custom authorization code which would take
advantage of a user's GenericPrincipal role affiliations (using a
GenericPrincipal object I attached to the HttpContext earlier) to facilitate
group-to-group mapping for confirming or denying access to a resource.
I don't know if this is a bug in MSRS, or if I have simply misconfigured
something. Any ideas? Thanks.
-Rob Hoffman
"Teo Lachev" wrote:
> Ray,
> Yes, you would establish role-based security policies just like you would do
> with Windows-based security. Your authorization extension will have the
> final say if the user is authorized to perform a given action. For example,
> if you need to implement role membership rules, you can change the
> CheckAccess overloads to account for the addtional rights that the user will
> get based on her role membership. Debugging the CheckAccess overloads should
> help you clarify how this could be done.
> --
> Hope this helps.
> ----
> Teo Lachev, MCSD, MCT
> Author: "Microsoft Reporting Services in Action"
> Publisher website: http://www.manning.com/lachev
> Buy it from Amazon.com: http://shrinkster.com/eq
> Home page and blog: http://www.prologika.com/
> ----
> "RayG" <RayG@.discussions.microsoft.com> wrote in message
> news:40831253-2400-44A3-8A2E-3FF9171C7510@.microsoft.com...
> > We are currently implementing forms authentication in our RS deployment.
> The
> > MSDN sample helped get us started. We are now faced with the
> authorization
> > implementation.
> >
> > How do I go about telling RS which user has access to which folder/report?
> > Telling RS which users will be administrators? Do I still get to use
> > role-based security and can create/edit my roles through the Report
> Manager
> > or do I need to assign indepentent permissions per user?
>
>|||Rob,
How did you test that CheckAccess overloads are not invoked? Please note
that they will be invoked only during runtime. If you use the Report Manager
they are not invoked. Instead, GetPermissions will be called. Therefore, you
need to duplicate the same permission checks in GetPermissions as you would
in CheckAccess. I suggest you refactor the common logic from CheckAccess
overloads in a helper function so can be easily reused.
So, just like with Windows authentication, your security authentication
extensions will authenticate the user based on the user identity. In other
words, if I am Bob and I belong to role Sales Reps, I will log in as Bob. In
my authorization extension I will authorize the user based on the user
identity and role membership. Once again, you need to do this in both
CheckAccess and GetPermissions, the later being used by the Report Manager
as a result to a call to the GetPermissions SOAP API.
--
Hope this helps.
----
Teo Lachev, MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
----
"Rob Hoffman" <RobHoffman@.discussions.microsoft.com> wrote in message
news:7BE3E0A3-95C0-46D3-B589-7AAB38A38B1D@.microsoft.com...
> Hi Teo,
> I am having a problem similar to RayG's, using the forms authentication
> sample code. I put some debug statements into the
> Microsoft.Samples.ReportingServices.CustomSecurity.Authorization class,
> CheckAccess methods. I also commented out the logic in the
> AuthenticationExtension and AuthenticationUtilities classes such that all
> logon attempts are permitted without password checking (return true).
> I found that when accessing report resources using an identity that is
> defined in MSRS, that the Authorization.CheckAccess methods are invoked.
I
> set up security on the Home folder and one subfolder, and was able to use
> combinations of groups to restrict access appropriately. I also found
that
> when you use a logon credential that is not defined in MSRS (that is, not
> used in any object's ACL), that the Authorization.CheckAccess methods are
not
> invoked. For example, I set up a "Users" group, and granted it access to
a
> folder. Logging on as "Users" I could access this folder. Logging on as
> "User" gave me an access denied message, as expected, however, none of the
> Authorization.CheckAccess methods were invoked either...unexpected.
> This presents a problem, as I am trying to set up groups in MSRS that map
to
> user groups in my application. It seems that because the
> Authorization.CheckAccess methods are not invoked in this case, there is
no
> opportunity to extend them with custom authorization code which would take
> advantage of a user's GenericPrincipal role affiliations (using a
> GenericPrincipal object I attached to the HttpContext earlier) to
facilitate
> group-to-group mapping for confirming or denying access to a resource.
> I don't know if this is a bug in MSRS, or if I have simply misconfigured
> something. Any ideas? Thanks.
> -Rob Hoffman
> "Teo Lachev" wrote:
> > Ray,
> >
> > Yes, you would establish role-based security policies just like you
would do
> > with Windows-based security. Your authorization extension will have the
> > final say if the user is authorized to perform a given action. For
example,
> > if you need to implement role membership rules, you can change the
> > CheckAccess overloads to account for the addtional rights that the user
will
> > get based on her role membership. Debugging the CheckAccess overloads
should
> > help you clarify how this could be done.
> >
> > --
> > Hope this helps.
> >
> > ----
> > Teo Lachev, MCSD, MCT
> > Author: "Microsoft Reporting Services in Action"
> > Publisher website: http://www.manning.com/lachev
> > Buy it from Amazon.com: http://shrinkster.com/eq
> > Home page and blog: http://www.prologika.com/
> > ----
> >
> > "RayG" <RayG@.discussions.microsoft.com> wrote in message
> > news:40831253-2400-44A3-8A2E-3FF9171C7510@.microsoft.com...
> > > We are currently implementing forms authentication in our RS
deployment.
> > The
> > > MSDN sample helped get us started. We are now faced with the
> > authorization
> > > implementation.
> > >
> > > How do I go about telling RS which user has access to which
folder/report?
> > > Telling RS which users will be administrators? Do I still get to use
> > > role-based security and can create/edit my roles through the Report
> > Manager
> > > or do I need to assign indepentent permissions per user?
> >
> >
> >|||Teo,
Thanks for turning me on to the GetPermissions method...adding a role check
there did the trick. To check the invocation of the CheckAccess overloads, I
just wrote some debug statements to a log file. Thanks again for your help.
-Rob Hoffman
"Teo Lachev" wrote:
> Rob,
> How did you test that CheckAccess overloads are not invoked? Please note
> that they will be invoked only during runtime. If you use the Report Manager
> they are not invoked. Instead, GetPermissions will be called. Therefore, you
> need to duplicate the same permission checks in GetPermissions as you would
> in CheckAccess. I suggest you refactor the common logic from CheckAccess
> overloads in a helper function so can be easily reused.
> So, just like with Windows authentication, your security authentication
> extensions will authenticate the user based on the user identity. In other
> words, if I am Bob and I belong to role Sales Reps, I will log in as Bob. In
> my authorization extension I will authorize the user based on the user
> identity and role membership. Once again, you need to do this in both
> CheckAccess and GetPermissions, the later being used by the Report Manager
> as a result to a call to the GetPermissions SOAP API.
> --
> Hope this helps.
> ----
> Teo Lachev, MCSD, MCT
> Author: "Microsoft Reporting Services in Action"
> Publisher website: http://www.manning.com/lachev
> Buy it from Amazon.com: http://shrinkster.com/eq
> Home page and blog: http://www.prologika.com/
> ----
[SNIPPED]