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


Harden MS Reporting Services Using Custom Extensions : Page 2

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.

Internet Reporting
Spend some time carefully weighing both access options against your reporting requirements to find the best match. Generally, I recommend URL addressability whenever possible because of its easier implementation and interactive feature support.

The two access options are not mutually exclusive. For example, while a Web application may render most of its reports via URL, some reports may need to be generated on the server-side by calling down to the RS Web service.

Security Considerations
Many Web developers will opt for URL access to provide the best user experience to their users and minimize the RS integration effort. However, URL addressability presents a unique challenge for Internet-based reporting; by default RS is configured to use Windows security, so the user is authenticated and authorized based on its Windows identity. This fine for intranet applications where the Report Server and the end users are usually on the same domain and it’s possible to take advantage of the Active Directory infrastructure already in place. However, Windows-based security is almost always not a good option for Internet-facing applications. First, maintaining creating and maintaining thousands of Windows user accounts can overwhelm the network administrator. Second, the users will be confronted with the standard Windows logon dialog which pops up when a Web site configured for Windows security is requested and the user belongs to a different domain than the Web server.

For many Web applications, custom application security models provide the practical means to authenticate and authorize users. For example, ASP.NET developers are well familiar with the ASP.NET forms authentication mechanism.

The administrator configures the entire site or only a portion as protected. If the end-user requests a protected resource and has not been previously authenticated, s/he is re-directed to a logon page that the developer has created beforehand. Once the logon page collects the user credentials, it verifies them against a user profile store, typically located in a database. Upon successful user authentication, a ticket is issued in a form of a session cookie. The ASP.NET forms authentication framework verifies this authentication ticket with each subsequent request.

RS Custom Security From a security perspective, when you're report-enabling your Internet applications, you should ideally be able to plug in RS seamlessly into the custom security model that your Web application uses. Can you integrate RS with Web applications that leverage custom security and require URL addressability? You bet. To accomplish this, you need to replace the default RS Windows-based security with a custom security extension.

By definition, a custom security extension is nothing more than a .NET assembly that implements some required security-related interfaces. These interfaces are defined in the Microsoft.ReportingServices.Interfaces assembly found in the C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\bin\ folder, as shown in Table 1.

Table 1. Required interfaces for custom security extensions.







GetUserInfo (System.Security.Principal.IIdentity userIdentity , System.IntPtr userId)


The Report Server calls the GetUserInfo method for each request to retrieve the current user identity. A typical implementation is to return the identity from the current context.


LogonUser(System.String userName , System.String password , System.String authority)

The Report Server calls LogonUser in response to a call to the LogonUser SOAP API. This method is responsible for the user authentication.


IsValidPrincipalName(System.String principalName)

Invoked when the Report Server sets a report item role-based policy, e.g. when you assign a user to a role. The purpose of this method is to validate that the user name is correct, not to authenticate the user.



Various CheckAccess method overloads


The Report Server calls the appropriate CheckAccess overload depending on the attempted action.


CreateSecurityDescriptor (AceCollection acl , SecurityItemType itemType , System.String stringSecDesc )

Returns a security descriptor that is stored with an individual item in the report server database.

GetPermissions ( System.String userName , System.IntPtr userToken, SecurityItemType itemType , byte[] secDesc )

Returns the permissions that the principal has as defined in the report catalog. This provides underlying support for the Web service  method GetPermissions(), e .g. when an management action is performed using the Report Manager.

In addition, since both IAuthenticaionExtension and IAuthorizationExtension interfaces inherit from the IExtension interface, you need to implement the IExtension methods so your custom security extension can be successfully registered with the report server. The IExtension interface specifies only two methods:

  • SetConfiguration: The report server calls SetConfiguration to pass the extension configuration section as specified in the configuration file. For example, the sample custom security implementation uses a configuration section in the RSReportServer.config file (<Authentication> element) to specify the administrator credentials and connection string to the user profile store. Before the report server calls the IAuthenticationExtension methods, it gives the extension a chance to configure itself by passing the configuration section as a XML fragment. In this case, the authentication extension loads the section in XML DOM and sets the appropriate class-level members.
  • LocalizedName: This returns the name of the extension based on the thread culture. Neither the report author nor the administrator are meant to see the names of the authentication and authorization extensions. Therefore, the implementation of LocalizedName returns null. However, if you were to develop a custom data extension, you'd implement LocalizedName to return a descriptive and even more localized name of the extension, which would be shown both in VS.NET (when configuring the report data source) and the report manager.

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