Katana

Basic Authentication is considered a bit of an anti-pattern these days, but it can still be useful in a pinch when you have limited options for integrating with APIs, third party applications or the dreaded legacy applications.

Basic Authentication should never be a recommended solution, however I have met many clients who are still running services that use it and third party applications who only support basic authentication. Some security is better than none, right? I guess that's debatable.

If you want a modern identity solution, check out Identity Server. Identity Server is a one time configuration that will allow you to create your own OAuth, OpenID Connect or WS-Federation Authentication Server (aka Identity Provider, Security Token Service, etc), that can reliably service all of your applications.

This article will cover the theory behind basic authentication, including why we shouldn't really be using it, and then look at how we can integrate it into our OWIN pipeline.

When using the WS-Federation protocol, you usually (or at least should) use certificates to sign your token, allowing the receiver to verify the contents have not been altered in transit, and for Transport Layer Security (TLS, think SSL) in order to provide privacy for network communications.

What is less common but also useful is SAML assertion encryption. This token encryption is useful when your SAML token includes claims/assertions that contain private data which might be held for a long period of time or passed around through untrusted intermediaries.

This certificate has its public key held by the Security Token Service (STS) in order to encrypt the token, and its private key held by the Relying Party in order to decrypt it.

This process is relatively well documented if you are dealing with Windows Identity Foundation (WIF) 1.0 and slightly less so with WIF 4.5, however there are currently little to no resources on how to achieve this with the latest OWIN/Katana components.

If you’ve newed up an ASP.NET project template you’re most probably using the OWIN pipeline and are familiar with middleware such as Use, Map, Run or UseCookieAuthentication. These are all extension methods for IAppBuilder, found in your OWIN Startup class, calling logic that will manipulate the current OWIN context or environment.

Using the OwinMiddleware abstract class found in Microsoft.Owin we can start to create our own OWIN Middleware components that we can then integrate with our existing pipeline or distribute as a package.

OwinMiddleware

The abstract OwinMiddleware class looks like this:

In the .NET world there hasn't been much choice in web server technology aside from IIS and all the caveats that come with it.IIS has been around for a long time now, longer than ASP.NET itself, and for a junior programmer, tackling it and its years worth of libraries can be quite a daunting task.Another barrier is System.Web, a monolithic assembly that contains everything under the sun all tightly coupled into one namespace, often being coupled into IIS.

With more and more processing moving onto the client, servers have stopped processing and returning html and are instead just returning data for the client to parse and present.Modern approaches such as node.js require minimal effort to act as a web server, containing only what is needed to build the application and nothing else.

OWIN

The Open Web Interface for .NET (OWIN) specification aims to provide a similar experience for .NET.This open standard provides a simple API for web servers and frameworks to interact with.

The mission statement from the guys themselves: