Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Harden MS Reporting Services Using Custom Extensions : Page 7

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.


advertisement
User Authorization
Upon inspecting the incoming request, if the report server validates the authentication cookie successfully, it proceeds by asking your extension to authorize the user request by calling one or several of the CheckAccess overloads. The type of CheckAccess overload called depends on the type of the attempted action against the RS report catalog. For example, if the user requests a report, the report server calls the following CheckAccess overload:

public bool CheckAccess(string userName, IntPtr userToken, byte[] secDesc, ReportOperation requiredOperation)

All CheckAccess overload methods have the same signature except the last enumeration argument, which specifies the type of the action attempted. For this reason, it makes sense to re-factor the authorization logicin the helper function CheckOperations.

First, the code in this function determines whether the user name matches the administrator name. If it does, access is granted to the user regardless of the requested operation. If not, the CheckOperations proceeds by inspecting the role-based security policy defined for this user.



The user password is not passed to CheckAccess because the report server has already asked your extension to authenticate the user when the request was first submitted. Once the user is authenticated, the report server inspects the authentication cookie to find out if the user has been authenticated or not. This eliminates the need of authenticating the user with each request.

The report server may decide to call a single CheckAccess overload several times. In the previous example, when the user requests a report, the report server first calls the CheckAccess overload to determine whether the user has permission to the given report (requiredOperation is ReadProperties). The report server then calls the same overload to determine whether the user has rights to execute the report (requiredOperation is ExecuteAndView). The authorization extension tells the report server if the user is permitted to perform the requested action. If the user is not authorized, an error "Not authorized" message is sent to the client.

The authorization extension determines whether the user is authorized to perform a given action by inspecting the role-based policy set up for this user. When the report server calls CheckAccess, it also passes the role-based security policy (as a byte array under the secDesc argument) defined for the catalog item. For example, suppose the user has requested the customer orders report. Under the role-based policy shown in Figure 4, the security descriptor is deserialized, after which the access control list collection contains four elements, one for each user defined. Each user element has additional collections that contain the permissions defined for all supported operations, e.g. FolderOperation, ReportOperation, and so on. The report server simply tells you "Here is the item security policy that you have defined in the report manager (or programmatically) for user A. Now please tell me, is this user really authorized to perform action B?"

Developers will probably appreciate the flexibility that the RS custom security framework provides. At its simplest implementation, authorization logic just needs to enumerate through the access control list in an attempt to find a match for the logged on user. At the same time, it supports more involved authorization scenarios. Part II of this series will demonstrate how to modify the authorization extension to support role membership.

The last authorization detail that deserves more attention is the IAuthorizationExtension.GetPermissions method. The report server calls this method when the GetPermissions SOAP API is invoked. For example, if the user opens the report manager and navigates through the folder structure, the report manager calls the GetPermissions SOAP API to find out if the user has the required permissions to view or change catalog items. When custom security is used, the report server redirects the call to your implementation of IAuthorizationExtension.GetPermissions. Again, the report server passes the role-based security policy as defined in the report catalog. In its simplest form, the GetPermissions implementation filters out the permissions defined for the given user and returns them to the report server. More complicated authorization requirements may call for validating additional business rules to determine if the role-based security policy set up for this user should be honored or not.

Custom Security Implementations
Often, internet reporting requirements will call for URL report addressability without compromising security. Thanks to the RS extensibility architecture, developers can replace the default RS Windows-based security with custom security implementations in the form of security extensions.

Part II of this series will discuss how to reduce the management effort for maintaining hundreds of Web users by assigning them to application-defined roles.



Teo Lachev works as a technical architect for a leading financial institution where he designs and implements .NET-centric Business Intelligence solutions. He is a Microsoft Most Valuable Professional (MVP) for SQL Server. Teo is the author of the books Applied Microsoft Analysis Services 2005 and Microsoft Reporting Services in Action.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

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