Browse DevX
Sign up for e-mail newsletters from DevX


Harden MS Reporting Services Using Custom Extensions, Part 2

In Part 1, you learned to create a custom security model for Microsoft Reporting Services. Now, tighten the screws by adding role membership authentication and stave off problems by troubleshooting and debugging your custom extensions ahead of time.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

n Part 1 of this series, you learned that, by default, the Report Server uses Windows-based security to authenticate and authorize incoming requests based on the Windows identity of the interactive user. While Windows-based security works well for intranet applications, it is usually impractical for Internet-facing applications. This leaves you with two implementation choices.

The first option is to generate reports on the server-side of the application by calling the RS Render SOAP API. The advantage of this approach is tighter security. The report request cannot be hijacked and exploited since the report is generated entirely on the server-side of the application. On the downside, reports generated by SOAP will have a reduced feature set since most of the RS interactive features—including the report toolbar—rely on URL addressability.

The second option is to replace the RS Windows-based security model with a custom security extension in order to request reports by URL. The user authentication and authorization is then handled by a custom security extension which can be integrated with the application security model (the example in Part 1 used ASP.NET Forms authentication).

As useful as it is, this example custom security implementation has one caveat. It requires you to set up individual security polices for each user, which isn't very practical for Web applications that may support thousands of users. Thankfully, application roles provide a practical means for you to group users with identical permissions—in the same manner that Windows groups simplifies maintaining Windows-based security.

Understanding Role-based Membership
Your application may already support assigning users to application-defined roles. For example, if your organization is doing business with several companies, you need to allow employees of these companies to request reports without compromising security. In this case, you can simplify security maintenance by assigning permissions on a per company basis—as opposed to by individual employees. In this example, your application roles will be scoped at the company level.

To bring a touch of reality to this code sample, assume that Adventure Works has introduced several levels of customer membership based on the customer order volume, e.g. Platinum, Gold, Silver, and Regular. Please note that it is entirely up to developer to determine the actual implementation and semantics of the application roles. The business rules behind the role membership are of no importance to the role-based implementation.

Adding another level of flexibility, this role-based membership implementation supports assigning users to multiple roles. The granted permissions are additive as well, which means that the user receives a superset of the permissions assigned to all the roles the user belongs to, plus the individual permissions assigned explicitly to the user.

Here are the high-level implementation goals for this custom role-based authentication:

  • Support for assigning users to multiple roles.
  • Allow the report administrator to set up both individual- and role-based security policies.
  • Authorize the user by granting a superset of individual- and role-based permissions assigned to the user.
  • Improve performance by caching the user role in the ASP.NET cache object.

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