Reading Katana Cookie Authentication Middleware’s Cookie from FormsAuthenticationModule

I saw a question in stackoverflow about using the cookie created by FormsAuthenticationModule (FAM) from the Katana Cookie Authentication Middleware. I thought it was a one-off question. But then, here is one more question, similar, but it is about reading the cookie created by CAM from FAM. Though we cannot change FAM’s behavior, it is technically possible to write an HTTP module to read the ticket. So, thought of writing some code to illustrate how to read the CAM cookie.
Continue reading

Using Thinktecture Hawk Katana Authentication Middleware with ASP.NET 5.0 (ASP.NET MVC 6)

In this post, I have covered Katana middleware versus ASP.NET 5.0 middleware. Calling a normal Katana middleware that accepts AppFunc from ASP.NET 5.0 pipeline is not that difficult. You can just use the UseOwin extension method on IApplicationBuilder, like so.

app.UseOwin(addToPipeline =>
{
    addToPipeline(next =>
    {
        return new MyNormalKatanaMiddleware(next).Invoke;
    });
});

Continue reading

Barebones ASP.NET MVC Google Signin through OWIN Middleware

If you use Visual Studio and want to add Google sign-in to your ASP.NET MVC app by using an out of box template, you get code that uses ASP.NET identity and three Katana authentication middleware: (1) the cookie authentication middleware running in active mode, (2) another instance of cookie authentication middleware but running in passive mode, and (3) Google authentication middleware. That will be like so.
Continue reading

Using tt.idm Hawk Authentication OWIN Middleware with IIS-Hosted ASP.NET Web API

Hawk Authentication in Thinktecture.IdentityModel can be hooked into your ASP.NET Web API through the message handler (HawkAuthenticationHandler) or the OWIN middleware (HawkAuthenticationMiddleware). The sample here is based on a self-hosted web API (WCF channel stack) using the message handler and another self-hosted web API (OWIN host adapter) using the OWIN middleware. It is possible to use the OWIN middleware and enable Hawk authentication for your ASP.NET Web API which is hosted in IIS. Of course, you can use the message handler, which is the simplest option but we will see how message handler measures up to OWIN middleware in the case of hosting in IIS.
Continue reading

Thinktecture.IdentityModel.Hawk NuGet Package

With Thinktecture.IdentityModel V.Next out, Hawk authentication implementation in Thinktecture IdentityModel gets its own NuGet package. It is currently in pre-release and here is the NuGet Gallery link. The OWIN middleware code that has been a part of the samples is now moved into Thinktecture.IdentityModel and is a part of this NuGet package.

Let’s now see how we can create a simple web API (ValuesController, of course) and OWIN-host it with hawk authentication plugged in using the OWIN middleware that is part of this NuGet package.
Continue reading

OWIN Authentication Middleware for Hawk in Thinktecture.IdentityModel.45

This is continuation of my previous post Basic Authentication with ASP.NET Web API Using OWIN Middleware, where I implemented HTTP basic authentication in a custom OWIN middleware class AuthenticationMiddleware that derives from the OwinMiddleware class. However, when it comes to implementing authentication in an OWIN middleware, the recommended approach is to use the authentication micro-framework that Katana has and derive from the out-of-box middleware class AuthenticationMiddleware<T>. Of course, this special authentication middleware also derives from OwinMiddleware, like so.
Continue reading

Basic Authentication with ASP.NET Web API Using OWIN Middleware

One of the decisions to be made while implementing authentication for ASP.NET Web API is where to implement the authentication logic – message handler, authorization filter or HTTP module. Authorization filter is a bad choice for the obvious reason that it is for authorization and not authentication. For message handler versus HTTP module, a good read is the ASP.NET site itself. A rule of thumb is to use an HTTP module if Web API is going to be exclusively web-hosted and to use a message handler otherwise. One of the greatest advantages of a message handler is that it is host-agnostic but the downside is that the principal set in the message handler reverts back to the previous principal when the response leaves the web API pipeline. If you use IIS logs, for example, it will know nothing about the principal you set in the message handler. HTTP module locks you into IIS but it has it’s own advantage. Notable one being the fact that IIS/ASP.NET does recognize the principal set from the HTTP module. For host-agnostic reasons, in the book that I have written Pro ASP.NET Web API Security, I have extensively used message handlers. Continue reading