RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Harden MS Reporting Services Using Custom Extensions : Page 3

An incredibly flexible extensibility model is included with Microsoft Reporting Services and hammering down a custom security model is one smart way to take advantage. Shore up your implementation with forms authentication and role membership.

Understanding RS Forms Authentication
Just like the RS Windows-based authentication or other popular security models, your RS Forms Authentication security extension should provide the necessary infrastructure for:
  • User authentication: During the authentication stage, the custom security extension determines the user's identity by obtaining it from a trusted authority—by querying the user profile store. A successful outcome of this phase is an authentication ticket in a form of a session cookie sent to the client.
  • User authorization: Authorization occurs after authentication and determines what the user can do. For example, if the user has submitted a report request, during the authorization phase your custom security extension must verify if the user has indeed rights to do so. Typically, to simplify the security maintenance effort, the report administrator will use the Report Manager to create role-based security policies just as s/he would if Windows-based authentication is used.
Figure 1 depicts an overview of how the RS custom security extension works.

Figure 1. The RS Custom Security Extension: This sequence flow is responsible for authenticating and authorizing all requests going out to the Report Server.

.NET developers familiar with the ASP.NET forms authentication will probably find the RS custom security model similar. Figure 1 shows sequence flow between the client and the report server, configured to use a custom security extension.

User Authentication

  1. The client application displays a logon form to prompt the user for credentials, (user name and password). In the case of ASP.NET applications, ASP.NET forms authentication can be used to redirect the user to the login form automatically if the user has not been authenticated.
  2. Once the user credentials are collected, the application invokes the LogonUser RS Web method to log the user to reporting services.
  3. Next, the report server asks the custom security extension to authenticate the user by calling its implementation of IAuthenticationExtension.LogonUser. How the custom security extension does this is of no concern to the report server. Typically, with a large number of users, a database store will be used to store the user profile data and credentials.
  4. If the user is successfully authenticated, the LogonUser SOAP API call returns a ticket in the form of a session cookie which the report server expects to find in subsequent calls from the client. When a browser is used as a client, the session cookie will be automatically passed back with all subsequent requests. When other types of clients are used, you will need to take an extra step to pass the cookie explicitly with the call to the report server.
User Authorization
  1. The client submits a report request either by URL or SOAP.
  2. The report server asks the custom security extension to authorize the user request by calling the appropriate IAuthorizationExtension.CheckAccess overload method.
  3. If the request is successfully authorized, the report server generates the report and sends it back to the client.
Although the scenario depicted in Figure 1 specifically refers to requesting reports, any type of action against the report catalog will be subject to custom authorization checks. For example, if the client is the report manager, each time the user initiates a new action from the portal, the report server will call down to the custom extension to authorize the request.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date