Thursday, September 10, 2015

Security in ASP.Net Web API

While exploring security options in web api, found many options on the web including the official ASP.Net Web API website. So explored it further and things became more clear. Finally decided to compile the understanding about this concept and hope it will help you also:

To start with we have to basic things/aspects about the security implementation. These are:

  • Authentication: Authentication is whether a user has proved his authenticity to access the web-api.The client request proves authenticity usually in the form of some kind of username and password. 
        For ex. an office may only allow people to enter, who is having any access card, to               enter office premises. If he is not, the system will not allow him to enter the office.
  • Authorization: Authorization on the other hand means, although being authenticated to access the web-api, should a user be allowed access a particular method of the web-api. 
         For ex. although a person may be allowed to enter the office he may still not have                  access to certain areas of the office, due to different department.This is the concept of          authorization. If you are not authorized, you will not be allowed to access the                          resource. 

Further, in order to implement the security we have two different points/level where we can implement the security. These are :

  1. Host Level:  Host is basically which is used to host the web-api. Host level options include the to use the Http Modules and OWIN middle-ware componentsHttp modules restrict to use IIS as the host option i.e. you can use the Http modules to implement security only if you are using IIS for hosting the web- api. On the other hand, to use OWIN middle-ware components we must use OWIN based hosting of the web api.

  2. ASP.Net Web API pipeline: This allows implementation within the web-api pipeline, rather then dependency on the hosting option used for it.This means they are host agnostic i.e. there implementation does not rely on the underlying hosting option. We may have IIS or OWIN based hosting and use any of the options available in this category. Some of the options available in this category include:
    • Use of Message Handlers
    • Use of Action Filters
    • Use of Authorization Filters
    • Use of Authentication Filters
So if we talk about what we discussed above, we can represent the different options in hierarchy as :

Host level options are executed before the request reaches the web-api. So when implemented, they get called earlier in the request cycle and may get called, even if the request is not aimed at the web-api resource. On the other hand, web-api level options are executed after the host and are more specific to the requests which are intended for the api.

For ex. when Http modules are used as an option to implement the authentication, it will be called for any type of incoming request to the web-server, even if it's not related to the web-api. On the other hand, option like Message handler (at web-api level), executes only for the requests which are aimed at the web-api.

Host level options are less preferable as they restrict the type of host used. Options at the web-api level provide more granular level of permissions which means they can be applied at the Controller level or the Method level in api. 

For ex. Authentication filters are a new feature in ASP.Net Web-API 2. This option is available at the web-api level and provides more granular control over the security, as it allows the filters to be applied at the controller and the individual method levels as well.

So this is about the basic concepts about security implementation in web-api. I hope you enjoyed reading it. Any feedback is welcome. Happy coding...!!!

No comments:

Post a Comment