Monday, February 5, 2018

Authorization

Authorization determines whether an identity should be granted access to a specific resource or not. This can be implemented/handled in different ways as below.

In ASP.NET: There are two ways to authorize access to a given resource:
  • File Authorization:

    This is performed by using FileAuthorizationModule which checks the access control list (ACL) of .aspx or .asmx handler file to determine whether user should have access to the resource. ACL permissions are verified for the user's Windows identity (if Windows Authentication is enabled) or for the Windows identity of the ASP.NET process

    FileAuthorizationModule verifies that the user has permission to access the requested file. This class cannot be inherited and below is the syntax of using this class

    public sealed class FileAuthorizationModule : System.Web.IHttpModule

    This module provides authorization services against file-system access-control lists (ACLs). When the mode attribute of the configuration element is set to windows then the WindowsAuthenticationModule is being used for the application. This modules ensures that the requesting user is allowed read or write access to the resource, depending on the request verb, before executing the request.

  • URL Authorization:

    This is performed using UrlAuthorizationModule which maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application for specific users or roles

    Wthe URL authorization, one can explicitly allow or deny access to a particular directory by user name or role. To do so, we need to create or have an authorization section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.

    Rules are applied as below:

    • Rules contained in application level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules at the head of the list
    • Given a set of merged rules for an application, ASP.NET starts at the head of the list and checks rules until the first match is found.

    Examples of configuring authorization(s):

    Syntax
    <authorization>
            < [allow][deny] users roles verbs />
    </authorization>

    Grant access to Kim and members of the Admins role, and denies access to the John identity and to all anonymous users:
    <authorization>
            < <allow users ="Kim" />
            < <allow roles ="Admins" />
            < <deny users ="John" />
            < <deny users ="?" />
    </authorization>

    Allow access to John identity and deny access to all other users:
    <authorization>
            < <allow users ="John" />
            < <deny users ="*" />
    </authorization>

    Can specify multiple entities for both the users and roles attributes by using comma-separated list:
    <authorization>
            < <allow users ="Jon, Kim, Contoso\Jane" />
    </authorization>

    Allow users to perform an HTTP GET for a resource, but allows only the Kim identify to perform a POST operation:
    <authorization>
            < <allow verbs ="GET" users="*" />
            < <allow verbs ="POST" users="Kim" />
            < <deny verbs ="POST" users="*" />
    </authorization>

In Web API: Authorization happens closer to the controller which lets one to make more granular choices while grating the access.
  • Authorization filters will run before running the controller actions. Based on the filter results user will be redirected either to a error response or to a action response
  • Using current principal from ApiController.User, one can work with current principal within controller's action
Below are the available Custom Authorization Filters:
  • AuthorizeAttribute: Extend this class to perform authorization logic based on the current user and the user's roles.
  • AuthorizationFilterAttribute: Extend this class to perform synchronous authorization logic that is not necessarily based on the current user or role
  • IAuthorizationFilter: Implement this to perform asynchronous authorization logic

In cases where you want to change the behavior based on the role, we can handle this using based on the principal. Within a controller method, you can get the current principal from the ApiController.User property. Below is an example:

public HttpResponseMessage Get()
{
          if (User.IsInRole("Administrators"))
          {
                // ...
          }
}

With this I am concluding the illustration. Feel free to share your feedback. Happy Programming !!!

No comments:

Post a Comment