Checking authorization through roles

In ASP.NET application or any application, is common to verify if the user has permission for a resource, like page, button, command, etc. In last days, I received an e-mail where a guy had performance problems.

In his page, there is a delete button in each line of GridView control. So, in RowDataBound event, he checks if the current user is in a specific role or not. But the problem is that he calls the IsUserInRole method for each line/record. In hundreds of lines/records in GridView, this method will always be called and, for each call, all code in this method will be performed. The example is showed below:

[ The old RowDataBound event ]

if(e.Row.RowType == DataControlRowType.DataRow) {
     e.Row.FindControl(“btnDelete”).Visible = Roles.IsUserInRole(“Administrator”);
}

[ The new RowDataBound event ]

private bool _isInAdministratorRole;
//….
this._isInAdministratorRole = Roles.IsUserInRole(“Administrator”);
//….
if(e.Row.RowType == DataControlRowType.DataRow) {
     e.Row.FindControl(“btnDelete”).Visible = this._isInAdministratorRole;
}

Small techniques like this can improve the application performance. “Caching code” is explained in Code Complete Book - Second Edition, at Chapter 26, pages 628 and 629.

There are other techniques related with roles in ASP.NET WebApplication. These techniques allow role caching in client cookies through cacheRolesInCookie attribute. It prevents in each request, to make a new query in database (or other repository), to find specific roles for current logged user and attach in HttpContext object.

Caching roles in client-side cookies can improve the performance if your application has a slow data access or a large number of roles. But this technique has security problems and you need to be careful:

  1. Persistent authorization cookies will be stored in a user's profile and can be stolen if an attacker gets physical access to the machine. This will also help prevent problems for users who access your application from public or shared machines and forget to log out.
  2. Sending cookies out exclusively over SSL makes it much harder for an attacker to sniff the cookie values off the wire.  If an attacker can get a copy of an authorization cookie, they can potentially emulate that role, allowing them to elevate their privilege in the system.

If caching of roles in client-side is necessary, so enable the cookieRequireSSL attribute in roleManager element for security reasons. But, SSL requires a certificate (if you don’t have, it’s necessary to buy it) and performance can be harmed. It’s very important to analyze the scenario and adopt the better strategy.

Published Tuesday, October 31, 2006 8:22 AM by israel aece
Filed under:

Comments

# re: Checking authorization through roles

Tuesday, October 31, 2006 12:51 PM by Francois

Hmm...I may be wrong, but for this particular example, I don't think there's a query to the database everytime, is there?

When you make a custom authentication scheme, the first thing you do is create a GenericPrincipal, and in its constructor, as the second parameter, it takes an array of roles, and then the principal is attached to the current thread. No database connection involved.

I was under the impression that Membership worked like that, too. Thus, while putting the result in a variable of the IsUserInRole method does at least prevent having to access the Principal's array of role repeatedly, and thus is still good practice, I do not think there's a query done to the server at every row...

I never actualy looked at how the Membership providers were implemented, so I could be wrong, but that is how all other ways of authenticating with a Principal work...

# re: Checking authorization through roles

Tuesday, October 31, 2006 2:28 PM by Andrey Skvortsov

He means "every request",I suppose-every request must be authentificated,so array of roles retrieved to construct GenericPrincipal.

Regards.

# re: Checking authorization through roles

Tuesday, October 31, 2006 2:56 PM by Israel Aece

OK, when you call the IsUserInRole the ASP.NET runtime get roles from GenericPrincipal but, for each request, it's necessary to bind a Principal because the HTTP is stateless.

So, if you don't caching roles in client-side (cookies), each request the stored procedure aspnet_UsersInRoles_GetRolesForUser is performed for retrieve the current roles for user.

Thanks!