Browse DevX
Sign up for e-mail newsletters from DevX


Harden MS Reporting Services Using Custom Extensions, Part 2 : Page 3

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

Implementing Role Authorization
When the Report Server receives a request for a given action against the report catalog, it asks the security extension to authorize the request by calling one or more CheckAccess methods in the custom authorization extension. Which CheckAccess overload(s) are called depends on the type of the action requested.

The Report Server passes the principal name (the customer identifier in this case) and the security policy descriptor associated with the given report catalog item to IAuthorizationExtension.CheckAccess so the custom extension can evaluate the security policy and take a stand. The Report Server doesn't know or care if the security policy is an individual- or role-based policy. For this reason, the security descriptor may contain both individual- and role-based polices.

Enhancing CheckAccess
Implementing role-based authorization means checking not only if the user has been assigned explicit rights to the report catalog item, but also if the user belongs to roles that are permitted to perform the requested action. Fortunately, this enhancement to the CheckOperations helper function is trivial:

private bool CheckOperations(string principalName, AceCollection acl, object requiredOperation) { // check if the individual login has been // granted rights to perform the operation if (IsUserAuthorized(principalName, acl, requiredOperation)) return true; // No individual policy established. // Next, check user role membership. string[] roles=HttpContext.Current.Cache[principalName] as string[]; if (roles!=null){ foreach (string role in roles){ if (IsUserAuthorized (role, acl, requiredOperation)) return true; } } return false; }

First, the code checks whether the user has an individual security policy assigned. For example, glancing back to Figure 2, if customer 11003 requests a report, then IsUserAuthorized returns true because this user has explicit rights assigned to browse reports. This wouldn't be the case for customer 14501 because this customer doesn't have an explicit security policy defined. However, 14501 may have been assigned to a role with the required permissions. To verify customer role membership permissions, the code retrieves the roles associated with the customer from the ASP.NET cache object (remember we cached the roles in LogonUser). Next, the code iterates through the roles in an attempt to find a role permitted to perform the action.

Enhancing GetPermissions
The Report Server also calls IAuthorizationExtension.GetPermissions when the GetPermission SOAP API is invoked. For example, the Report Manager needs to know if the user has the rights to browse a given folder so it can hide or show that folder. The Report Manager calls GetPermission in order to update the user interface based on the user’s security policy. Use the following code to make IAuthorizationExtension.GetPermissions role-aware:

string[] roles = HttpContext.Current.Cache[userName] as string[]; if (roles!=null) { foreach (string role in roles) { GetPermissions(role, acl, permissions); } }

This is almost identical to the CheckAccess enhancement. The only difference is that, instead of calling IsUserAuthorized, it calls the GetPermissions helper method. GetPermissions checks the security descriptor for the given principal (user or role) and returns a superset of all permissions associated with the principal.

Comment and Contribute






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



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