The State of Security in ASP.NET 5 and MVC 6: Claims & Authentication

Disclaimer: Microsoft announced the roadmap for ASP.NET 5 yesterday – the current release date of the final version is Q1 2016. Some details of the features and APIs I mention will change between now and then. This post is about beta 5.

I started talking about claims-based identity back in 2005. That was the time when Microsoft introduced a new assembly to the .NET Framework called System.IdentityModel. This assembly contained the first attempt of introducing claims to .NET, but it was only used by WCF and was a bit over-engineered (go figure). The claims model was subsequently re-worked by the WIF guys a couple of years later (kudos!) and then re-integrated into .NET with version 4.5.

Starting with .NET 4.5, every built-in identity/principal implementation was based on claims, essentially replacing the 12+ years old antiquated IIdentity/IPrincipal interfaces. Katana – but more importantly ASP.NET 5 is the first framework that now uses ClaimsPrincipal and ClaimsIdentity as first class citizens – identities are now always based on claims – and finally – no more down-casting!

HttpContext.User and Controller.User are now ClaimsPrincipals – and writing the following code feels as natural as it should be:

var email = User.FindFirst(“email”);

This might not seem like a big deal – but given that it took almost ten years to get there, shows just how slow things are moving sometimes. I also had to take part in a number of discussions with people at Microsoft over the years to convince them that this is actually the right thing to do…

Authentication API
Another thing that ASP.NET was missing is a uniform authentication API – this was fixed in Katana via the IAuthenticationManager and was pretty much identically brought over to ASP.NET 5.

AuthenticationManager hangs off the HttpContext and is a uniform APIs over the various authentication middleware that do the actual grunt work. The major APIs are:

  • SignIn/SignOut
    Instructs a middleware to do a signin/signout gesture
  • Challenge
    Instructs a middleware to trigger some external authentication handshake (this is further abstracted by the new ChallengeResult in MVC 6)
  • Authenticate
    Triggers validation of an incoming credential and conversion to claims
  • GetAuthenticationSchemes
    Enumerates the registered authentication middleware, e.g. for populating a login UI dynamically

Authentication Middleware
The actual authentication mechanisms and protocols are implemented as middleware. If you are coming from Katana then this is a no brainer. If your background is ASP.NET.OLD think of middleware as HTTP modules – just more flexible and lightweight.

For web UIs the following middleware is included:

  • Cookie-based authentication (as a replacement for good old forms authentication or the session authentication module from WIF times)
  • Google, Twitter, Facebook and Microsoft Account
  • OpenID Connect

WS-Federation is missing right now. It is also worth mentioning that there is now a generic middleware for OAuth2-style authentication (sigh). This will make it easier to write middleware for the various OAuth2 dialects without having to duplicate all the boilerplate code and will make the life of these guys much easier.

Wiring up the cookie middleware looks like this:

app.UseCookieAuthentication(options =>
    options.LoginPath = new PathString(“/account/login”);
    options.AutomaticAuthentication = true;
    options.AuthenticationScheme = “Cookies”;               

The coding style is a little different – instead of passing in an options instance, you now use an Action<Option>. AuthenticationType has been renamed to AuthenticationScheme (and the weird re-purposing of IIdentity.AuthenticationType is gone for good). All authentication middleware is now passive – setting them to active means setting AutomaticAuthentication to true.

For signing in a user, you create the necessary claims and wrap them in a ClaimsPrincipal. Then you call SignIn to instruct the cookie middleware to set the cookie.

var claims = new List<Claim>
    new Claim(“sub”, model.UserName),
    new Claim(“name”, “bob”),
    new Claim(“email”, “”)

var id = new ClaimsIdentity(claims, “local”, “name”, “role”);
Context.Authentication.SignIn(“Cookies”, new ClaimsPrincipal(id));

Google authentication as an example looks like this:

app.UseGoogleAuthentication(options =>
    options.ClientId = “xxx”;
    options.ClientSecret = “yyy”;

    options.AuthenticationScheme = “Google”;
    options.SignInScheme = “Cookies”;

The external authentication middleware implements the authentication protocol only – and when done – hands over to the middleware that does the local sign-in. That’s typically the cookie middleware. For this purpose you set the SignInScheme to the name of the middleware that should take over (this has been renamed from SignInAsAuthenticationType – again clearly an improvement).

Also the pattern of having more than one cookie middleware to be able to inspect claims from external authentication systems before turning them into a trusted cookie still exists. That’s probably a separate post.

For web APIs there is only one relevant middleware – consuming bearer tokens. This middleware has support for JWTs out of the box and is extensible to use different token types and different strategies to convert the tokens to claims. One notable new feature is support for OpenID Connect metadata. That means if your OAuth2 authorization server also happens to be an OpenID Connect provider with support for a discovery document (e.g. IdentityServer or Azure Active Directory) the middleware can auto-configure the issuer name and signing keys.

One thing that is “missing” when coming from Katana, is the OAuth2 authorization server middleware. There are currently no plans to bring that forward. IdentityServer can be a replacement for that. I will dedicate a separate blog post to that topic.

If you are coming from Katana, this all does not look terribly new to you. AuthenticationManager and authentication middleware works almost identical. Learning that, was no waste of time.

If you are coming from plain ASP.NET (and maybe even WIF or DotNetOpenAuth) this all works radically different under the covers and is really only “conceptually compatible”. In that case you have quite a lot of new tech to learn to make the jump to ASP.NET 5.

Unfortunately (as always) the ASP.NET templates are not very helpful in learning the new features. You either get an empty one, or the full-blown-all-bells-and-whistles-complexity-hidden-by-extensions-method-over-more-abstractions version of that. Therefore I created the (almost) simplest possible cookie-based starter template here. More to follow.

Posted in .NET Security, ASP.NET, IdentityServer, OAuth, OpenID Connect, WebAPI | 7 Comments

The State of Security in ASP.NET 5 and MVC 6

We’ve been closely following ASP.NET 5 and MVC 6 since the days it was presented behind closed doors, through the “vNext” and “Project K” phase up to recent beta builds.

I personally monitored all developments in the security space in particular and was even involved in one or the other decision making process – particularly around authorization which makes me also a little bit proud.

In preparation for the planned ASP.NET and MVC 6 security course for PluralSight, I always maintained a (more or less structured) list of changes and new features.

Tomorrow will be the release of Visual Studio 2015, which does NOT include the final release of ASP.NET 5. Instead we are between Beta 5 and 6 right now and the rough feature set has more or less been decided on. That’s why I think that now is a good time to do a couple of overview posts on what’s new.

Many details are still very much in flux and the best way to keep up with that is to subscribe to the various security related repos on github. Many things are not set in stone yet, so this is also an opportunity to take part in the discussion which I would encourage you to do.

The planned feature posts are:

Since training is very much about the details, we are holding off right now with recording any content until the code has been locked down for “v1”. So stay tuned.

The first public appearance of our updated “identity & access control” training for ASP.NET will be at NDC in London in January 2016.

Update: The final release of ASP.NET 5 is currently scheduled for Q1 2016 (

Posted in .NET Security, ASP.NET, Conferences & Training, IdentityServer, WebAPI | Leave a comment

Federated Logout with the Katana WS-Federation Middleware

For some reason the Katana WS-Fed middleware does not seem to implement signout cleanup.

This means that your application will ignore federated signout callbacks from the STS which will result in resources like logon cookies not being cleaned up properly.

Here’s a quick fix for your pipeline:

app.Use(async (ctx, next) =>
qs = ctx.Request.Query;
var wa = qs.Get("wa"

if (wa != null
if (wa == "wsignoutcleanup1.0"
// clean up resources, e.g. the logon cookie


await next();


Posted in .NET Security, ASP.NET, Katana, OWIN | Leave a comment

Security at NDC Oslo

For a developer conference, NDC Oslo had a really strong security track this year. Also the audience appreciated that – from the five highest ranked talks – three were about security. Troy has the proof.

I even got to see Bruce Schneier for the first time. It is fair to say that his “Secrets & Lies” book changed my life and was one of the major reasons I got interested in security (besides Enno).

Brock and I did a two day workshop on securing modern web applications and APIs followed by a talk on Web API security patterns and how to implement authentication and authorization in JavaScript applications.

Other talks worth watching (I hope I haven’t missed anything):

Well done, NDC!

Posted in .NET Security, IdentityModel, IdentityServer, OAuth, OpenID Connect, WebAPI | Leave a comment

Give your WCF Security Architecture a Makeover with IdentityServer3

Not everybody has the luxury of being able to start over and build the new & modern version of their software from scratch. Many people I speak to have existing investments in WCF and their “old-school” desktop/intranet architecture.

Moving to an internet/mobile world while preserving the existing services is not easy because the technologies (and in my case the security technologies) are fundamentally incompatible. Your new mobile/modern clients will not be seamlessly able to request tokens from your existing WS-Trust STS and SOAP is not really compatible with OAuth2. So what to do?

You could try to teach your WS-Trust STS some basic HTTP based token service capabilities and continue using SAML tokens. You could provide some sort of SAML/JWT conversion mechanism and create Web APIs for your new clients that proxy / convert to the WCF world. Or you could provide to separate token services and establish trust between them. All approaches have their own advantages and disadvantages.

For a project I am currently working on I chose a different approach – get rid of the old WS-Trust STS altogether, replace it with an OAuth2 authorization server (IdentityServer3) and make your WCF services consume JWT tokens. This way both old and new clients can request tokens via OAuth2 and use them with either existing WCF services and the new Web APIs (which ultimately will be also used in the desktop version of the product). How does that work?

Requesting the token
The OAuth2 resource owner flow is what comes closest to WS-Trust and it is easy to replace the WCF WSTrustChannel code with that. Going forward the web view based flows actually give more features like external IdPs etc. but need a bit more restructuring of the existing clients. New clients can use them straight away.

Sending the token
This is the tricky part. WCF can not deal with JWTs directly since they are not XML based. You first need to wrap them in an XML data structure and the typical approach for that is to use a so called binary security token. This worked fine at some point but the latest version of WCF and the JWT token handler don’t seem to work together anymore (here’s a nice write up from Mickael describing the problem).

Since WCF is really done – I did not expect anyone to fix that bug anytime soon, so I needed a different solution.

Another XML container data structure that is well tested and does the job equally well is SAML – so I simply created a minimal SAML assertion to hold the JWT token.

static GenericXmlSecurityToken WrapJwt(string jwt)
var subject = new ClaimsIdentity("saml"
new Claim("jwt"
, jwt));

var descriptor = new SecurityTokenDescriptor
        TokenType =
        TokenIssuerName =
        Subject = subject

var handler = new Saml2SecurityTokenHandler
token = handler.CreateToken(descriptor);

var xmlToken = new GenericXmlSecurityToken

return xmlToken;

Since we are using SAML solely as a container, there is no signature, no audience URI and just a single attribute statement containing the JWT.

After that you can use the wrapped JWT with the CreateChannelWithIssuedToken method over a federation binding:

var binding = new WS2007FederationHttpBinding(
binding.Security.Message.EstablishSecurityContext = false;
binding.Security.Message.IssuedKeyType =
var factory = new ChannelFactory<IService
new EndpointAddress(https://localhost:44335/token

var channel = factory.CreateChannelWithIssuedToken(xmlToken);

Validating the token
On the service side I sub-classed the SAML2 security token handler to get the SAML deserialization. In the ValidateToken method I retrieve the JWT token from the assertion and validate it.

Since I have to do the validation manually anyways, I wanted feature parity with our token validation middleware for Web API which means that the token handler can auto-configure itself using the OpenID Connect discovery document as well as do the scope validation.

new IdentityServerWrappedJwtHandler("https://localhost:44333/core", "write"));

The end result is that both WCF and Web API can now consumes JWT tokens from IdentityServer and the customer can smoothly migrate and extend their architecture.

The POC can be found here. It is “sample quality” right now – feel free to make it more robust and send me a PR.

Posted in .NET Security, IdentityServer, OAuth, WCF, WebAPI | 29 Comments

Three days of Identity & Access Control Workshop at SDD Deep Dive – November 2015, London

As part of the SDD Deep Dive event in London – Brock and I will deliver an updated version of our “Identity & Access Control for modern Web Applications and APIs” workshop.

For the first time, this will be a three day version covering everything you need to know to implement authentication & authorization in your ASP.NET web applications and APIs.

The additional third day will focus on IdentityServer3 internals and customization as well as an outlook on how to migrate your security architecture to ASP.NET 5 and MVC6.

Come by and say hello! (also get some of our rare IdentityServer stickers)

Posted in .NET Security, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | Leave a comment

OpenID Connect Certification for IdentityServer3

I am extremely happy to announce that IdentityServer3 is now officially certified by the OpenID Foundation.


Version 1.6 and onwards is now fully compatible with the basic, implicit, hybrid and configuration profile of OpenID Connect.

Posted in .NET Security, ASP.NET, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 2 Comments