Posted on

Authentication in Module vs MessageHandler

We are often confused about where to put our authentication code in the Asp.Net life cycle’s pipeline. I believe the below discussion can come to help in that regard.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.

Posted on

Authentication basics in ASP.Net

Authentication: Is the process that makes it known about the identity of the user. When a user logs in with his username, password, the server identifies the user based on that.

Creating the principal:

  • Authentication happens in the host. EX: IIS. IIS uses HTTP modules for authentication.
  • Modules can be built in or custom.
  • The host authenticates the user by creating a Principal, It is an IPrincipal object. It represents the security context under which the code is running.
  • Host attaches this newly created principal to the current thread. As we know whenever a request comes to the web server it creates a separate thread for that request to be handled. (Huge discussion). It does so by setting the Thread.CurrentPrincipal.
  • Each principal contains an object called Identity that contains information about the user.
  • If the user is authenticated the identity.isAuthenticated property returns true. For anonymous requests, it returns false.

Setting the principal:

  • For custom authentication: We need to set the principal in two places.
    • Thread.CurrentPrincipal
    • HttpContext.Current.User

Code:

[sourcecode language=”csharp”]

Private void SetPrincipal(IPrincipal Principal)

{

       Thread.CurrentPrincipal = principal;

       if(HttpContext.Current.User != null)

        {

            HttpContext.Current.User = principal;

        }

}

[/sourcecode]

  • For web hosting we need to set these both. For self hosting the HttpContext.Current.User is null.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.