Monday, September 9, 2013

Controlling the page access permission

For most of the website that requires user logon, there are three types: (1) the system administrators (2) system users and (3) the page that is accessible without logon to the website.

The website will show the functions base on the current user type. For example, system administrator will be able to create user account, updating system settings. For system user, they will be able to access the data entry screen, generate reports. Both user types requires to access different features in the system.

In the design option, we may implement with one of the following security strategy:
  • The features are turn on/off which depends on the permission that has been assigned to the user. With this strategy, the "user" has many "permissions" (i.e., one-to-many relationship).
  • The features are turn on/off which depends on the user falls in which user group. With this strategy, you can have one user in one group or multiple groups (i.e., many-to-many relationship).
  • The simplest way is to add a field in the "user" record to identify it's "user type" (either system administrator or system user). Plus either one of the above strategy. With this design, you will be able to come out with a complex security design that can cater most of the requirements.
In ASP.net, you can implement the first and second strategy easily with either the built-in ASP.net user/role framekwork or show/hide the menu options. I guess most of the websites were implemented in this way.

The most interesting strategy is the third option and the implementation is powerful yet simple. You need to develop three page classes which inherits from Page class. Namely "AdminPage",  "UserPage" and the third one is PublicPage (for public access such as "login" page and "contact us" page).

The detail implementation of the in the AdminPage is to ensure that the current user type is system administrator in OnInit event.

public class AdminPage : Page
{
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);

             // if the user has not logged on, jump to "access deny" page.           
             // if current user is not  "system admin", jump to "access deny" page.
  
        }
}

For the UserPage, we don't want the system administrator to access it (this depends on the requirments) :

public class UserPage : Page
{
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
           
             // if the user has not logged on, jump to "access deny" page.
             // if current user is not  "system user", jump to "access deny" page.
  
        }
}

Once the above page classes are ready, you just need to change your ".aspx.cs" parent class to one of the above. By using the Object Oriented Programming, your developer colleagues will be able to find out which page is for admininstrator, user and public (just right click on the AdminPage and choose Find All References). This also reduce the developer comments in the ".aspx.cs" and increase the maintainability.

By inheriting the web page from different parent page class, there is a "gray" area which you are not sure if it should be PublicPage or UserPage. In this case, you might need to declare a new hybrid page class for it and limit the contents between the "public" and "user". But, for me, I prefer to move the "contents" from the page to "user control" (i.e., ".ascx") and limit the contents base on current user type. Then, I create two pages: one inherits from PublicPage and the other from UserPage. By using user control, I'm able to have the page for single audience and I'm able to handle it easily.