Owin and Katana offers a flexible pipeline for external authentication with existing providers for authentication by Google, Facebook, Twitter and more. It is also possible to write your own custom authentication provider and get full integration with the Owin external authentication pipeline and ASP.NET Identity.
Anatomy of an Owin Authentication Middleware
For this post I’ve created a dummy authentication middleware that interacts properly with the authentication pipeline, but always returns the same user name. From now on I will use the names from that dummy for the different classes.
A typical Katana middleware is made up of 5 classes.
- The main
- The internal
DummyAuthenticationHandler class doing the actual work.
DummyAuthenticationOptions class for handling settings.
- An extension method in
DummyAuthenticationExtensions for easy setup of the middleware by the client application.
- An simple internal
Constants class holding constants for the middleware.
Owin makes it easy to inject new middleware into the processing pipeline. This can be leveraged to inject breakpoints in the pipeline, to inspect the state of the Owin context during authentication.
When creating a new MVC 5.1 project a
Startup.Auth.cs file is added to the project that configures the Owin pipeline with authentication middleware. Two middleware for authentication are enabled through calls to
app.UseExternalSignInCookie. There are also commented out sections for Microsoft, Twitter, Facebook and Google authentication. This post will use Google Authentication as an example and also add some “dummy” middleware that makes it possible to set breakpoints and inspect the authentication pipeline.
Inserting Breakpoint Middleware
The middleware is executed in the order they are listed in the file, so by inserting a simple middleware between the existing, it is possible to inspect how each middleware interact with the authentication pipeline.
The injected middleware is just a few lines of code, but it allows two breakpoints to be set: on the opening and closing braces, which enables inspection before and after the call to the next middleware.
app.Use(async (context, next) =>
Last week, I was in beautiful Oslo in Norway most of the week for NDC 2014. It was a great conference and I’d like to point out a few highlights.
For the first time, I was a speaker at a major conference. I’ve done quite a few internal talks before and a few externals too, but never at such a high profile event as NDC. Looking at the speaker list I’m really honoured to have been part of it. I think it was challenging and fun – but I also found myself much more nervous than I had anticipated.
There were so many great people at the conference (both speakers and participants), but there are some that I think stand out with exceptionally good talks.
- Troy Hunt’s How I hacked my way to Norway. Troy is entertaining and educating on the same time. A talk that is both fun to listen to and that actually gives some concrete advice on how to (not) do security. I’m a bit disappointed though that he never used the IKEA allen key when hacking sites ;-).
- Uncle Bob Martin’s Advanced TDD: The Transformation Priority Premise. I’m a huge fan of TDD, but Uncle Bob brings it to another level, talking about 10 second oscillations between writing test and production code. Despite the title, I think it’s worth listening too even if you have limited previous experience on TDD.
- Luke Wroblewski’s It’s a Write/Read (Mobile) Web. The keynote, which was an eye opener to me that mobile and touch devices are not only for passive consumption of material. I especially liked the count of the number of clicks required to book a hotel on the major sites (well over 100) compared to FOUR on the best one.
- Scott Meyer’s Effective Modern C++. An introduction to some of the “new” features of C++11. The talk makes sense to a C# developer too – C++ developers are often far ahead of us in being aware of the details of how the language works and what the pitfalls are. Although there are more pitfalls in C++, a lot of the things Scott talked about applies to C# as well.
ASP.NET Identity is the reworked, flexible replacement for the old membership system that has been around since ASP.NET 2.0. ASP.NET Identity is more well designed and flexible than the old membership system and uses Owin middleware components for external logins such as Facebook, Google and Twitter.
Compared to the membership system, the architecture of ASP.NET Identity is very much improved and decoupled. Actually, ASP.NET identity doesn’t know (nearly) anything about Owin at all. ASP.NET Identity is working on an application ignorant level, taking care of user and role storage. Then there are the Owin authentication modules that takes care of the actual interaction with the external providers and keeping the user session. The plumping code required is built into the
AccountController created by the new project wizard for ASP.NET projects.
For a typical application there will be a number of different application layers cooperating to provide the authentication functionality.
- The ASP.NET Identity module sits at the very bottom of the chain, far, far away from the incoming HTTP Request. In fact, it knows nothing about Http at all.
- The MVC AccountController provides all the plumbing to make the different modules interact with each other.
- The Google Authentication Middleware interacts with Google to provide Google signon. In this example I only show Google, but if more social networks such as Facebook or Twitter were offered, they would be next to the Google middleware in the stack.
- The MVC Acount Controller is the generated MVC controller that ties all of the layers together.
- The ASP.NET Identity module handles user and secure password storage, role mapping etc.
Owin is the next hot thing that everyone (or at least those following the bleeding edge of .NET development) is talking about. When creating a new ASP.NET project it references Owin for the ASP.NET Identity authentication system so it’s obviously not only a hype but actively used. But what is it really and why should I care?
What is this Owin thing?
Owin is the under the hood interface between web servers and web applications. If you only write web applications in a single framework (such as ASP.NET MVC) an only run on one server platform (Windows with IIS) you can ignore Owin. But it will change the development and deployment landscape for ASP.NET so total ignorance can be risky.
The Complete Story
Owin is a new standardised interface between web servers and web applications. It is meant as a away to break up the tight coupling between ASP.NET and IIS. With IIS supporting Owin it is possible to run other Owin-enabled frameworks such as Nancy on IIS. With Microsoft’s web frameworks depending on Owin and not IIS it is possible to run those in other environments, such as self hosting within a process or on a web server on linux running Mono. SignalR and Web API already uses Owin which means that they can be self hosted and other cool stuff. ASP.NET MVC6 which is part of ASP.NET vNext will be completely based on Owin.