OAuth2 and OpenID Connect Scope Validation for OWIN/Katana

In OAuth2 or OpenID Connect you don’t necessarily always use the audience to partition your token space – the scope concept is also commonly used (see also Vittorio’s post from yesterday). A while ago I created a Web API authorize attribute to do the validation based on scopes (see here).

Since scope-based token validation can become so fundamental to your APIs – I moved the logic to an OWIN/Katana component so all frameworks can benefit from it, e.g.:

public class Startup

{

    public void Configuration(IAppBuilder app)

    {

        // read OR write

        app.RequireScopes(“read”, “write”);

 

        app.UseWebApi(WebApiConfig.Register());

    }

}

or…

public class Startup

{

    public void Configuration(IAppBuilder app)

    {

        // read AND write

        app.RequireScopes(“read”);

        app.RequireScopes(“write”);

 

        app.UseWebApi(WebApiConfig.Register());

    }

}

 

Source code here, sample here, nuget here.

Posted in IdentityModel, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 1 Comment

OpenID Connect and the IdentityServer Roadmap

Since OpenID Connect has been officially released now, I thought I’ll tell you a little bit more about our plans around our identity open source projects.

IdentityServer
IdSrv is a very popular identity provider with excellent support for WS-Federation and WS-Trust. It has decent support for OAuth2 and OpenID Connect (basic client profile) since quite some time – but these protocols were more like an afterthought than part of the initial design. IdSrv uses by default the pretty dated ASP.NET membership, but can be easily extended to use different data stores.

AuthorizationServer
We built AS because we wanted to implement OAuth2 “the right way” and we thought it is easier to start from scratch than retrofitting it into IdSrv. We deliberately didn’t add any authentication / user management pieces to AS because we wanted it to be freely combinable with existing infrastructure. For people without existing infrastructure, this was often a problem because setting up the IdP and AS at the same time was a steep learning curve.

While both projects solved very specific problems, there was room for improvement:

  • Combine identity management and a full featured OAuth2 implementation in a single component – still be able to use them independently if needed
  • Make it more lightweight so it can be hosted more flexibly
  • Incorporate OpenID Connect true cross platform client / relying party support (which was always a problem with WS-Federation)
  • Make authentication and acquisition of access tokens possible in a single round trip – which is a scenario that becomes more and more common.

So we actually decided to combine all those improvements and feature ideas into a new project currently codenamed “IdentityServer v3” :

  • Single codebase and server component to deploy
  • OpenID Connect and OAuth2 as the core protocols – but extensible to add support for e.g. WS-Federation
  • Built as an OWIN/Katana component with no dependencies on a specific host (e.g. IIS)
  • Completely customizable – think “STS toolkit”
  • Ability to incorporate arbitrary identity management systems – support for Brock’s MembershipReboot and ASP.NET Identity by default
  • Separation of core STS and user / configuration management for more flexibility
  • ..and more

We are not done yet – but will have more details soon – in the meantime – here’s a preview screenshot of a consent screen for a native client requesting identity claims (user id and email) as well as access tokens for an HTTP API backend.

image

Posted in AuthorizationServer, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 24 Comments

Test driving the WS-Federation Authentication Middleware for Katana

Microsoft just released an alpha version of the “most wanted” middleware for Katana: WS-Federation authentication!

I tested the bits against ADFS and of course – IdentityServer – and it is unspectacularly easy to get started (that’s a good thing).

1 The WS-Fed middleware itself
As with all other middlewares you wire it up in your Startup class:

app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions

{

    MetadataAddress = https://idsrv.local/…/metadata.xml,

    Wtrealm = “urn:owinrp”,

 

    TokenValidationParameters = new TokenValidationParameters

    {

        ValidAudience = “urn:owinrp”

    },

});

Remember the various configuration entries for the FAM and SAM in web.config – those have been essentially condensed down to the MetadataAddress property. Nice!

Of course you can still take control over validation yourself. But that’s for a future post.

2 Establishing the local authentication session
In WIF the FAM used the SAM to sign in locally (and that was hardwired). The equivalent of the SAM is now the Katana cookie middleware. It is not yet as feature rich as the SAM (e.g. chunking and reference mode missing) – but it is an alpha release.

app.UseCookieAuthentication(new CookieAuthenticationOptions

{

    AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType

});

Contrary to the normal Katana authentication middleware design pattern, where you specify which middleware to use to establish the local session (the SignInAsAuthenticationType property), the cookie middleware you want to use must “listen” to a pre-defined authentication type. I hope this will change in later versions.

3 Signing in
To initiate the WS-Fed handshake, you simply emit a 401:

app.Map(“/login”, map =>

{

    map.Run(async ctx =>

    {

        if (ctx.Authentication.User == null ||

            !ctx.Authentication.User.Identity.IsAuthenticated)

        {

            ctx.Response.StatusCode = 401;

        }

        else

        {

            ctx.Response.Redirect(“/”);

        }

    });

});

Again there are some open questions, e.g. will the Katana AuthenticationManager APIs like AuthenticateAsync or Challenge in active and passive mode scenarios behave as expected. We will find out in a future post!

4 Signing out
Signing out works like this:

app.Map(“/logout”, map =>

{

    map.Run(async ctx =>

    {

        ctx.Authentication.SignOut();

        ctx.Response.Redirect(“/”);

    });

 

});

This does a federated sign out.

5 Access the claims
…and finally we have access to the user’s claims in our application:

app.Run(async ctx =>

    {

        var user = ctx.Authentication.User;

        var response = ctx.Response;

 

        response.ContentType = “text/html”;

 

        if (user.Identity.IsAuthenticated)

        {

            await response.WriteAsync(string.Format(“<h2>{0}</h2>”,

                user.Claims.First().Issuer));

 

            await response.WriteAsync(“<dl>”);

            foreach (var claim in user.Claims)

            {

                await response.WriteAsync(string.Format(

                    “<dt>{0}</dt> <dd>{1}</dd>”,

                    claim.Type,

                    claim.Value));

            }

            await response.WriteAsync(“</dl>”);

        }

        else

        {

            await ctx.Response.WriteAsync(“<h2>anonymous</h2>”);

        }

    });

 

This is an excellent start. More to come!

(full gist is here)

Posted in IdentityServer, Katana, OWIN | 5 Comments

Workshop: Identity & Access Control for modern Web Applications and APIs

Brock and I are currently working on a brand new two day workshop about all things security when building modern web applications and APIs.

You can either attend the full two day version at NDC Oslo (June) – or a stripped down one day version at SDD London (May). Both still have early bird offerings.

Hope to see you!

With ASP.NET MVC, Web API and SignalR tied together using the new OWIN and Katana framework, Microsoft provides a compelling server-side stack to write modern web applications and services. In this new world we typically want to connect client platforms like iOS, Windows or Android as well as JavaScript-based applications using frameworks like AngularJS.

This two day workshop is your chance to dive into all things security related to these new technologies. Learn how to securely connect native and browser-based applications to your back-ends and integrate them with enterprise identity management systems as well as social identity providers and services.

Tags: WS-Federation, SAML, OAuth2, OpenID Connect, OWIN, JSON Web Tokens, Single Sign-on and off, Federation, Delegation, Home Realm Discovery, CORS

Day 1: Web Applications

  • Authentication & Authorization on .NET 4.5 and beyond
  • Introduction to OWIN and the Katana Project
  • Katana Security Framework
    • Cookie-based Authentication
    • Enterprise Authentication with WS-Federation
    • Social Logins (e.g. Google, Facebook, Twitter, etc.)
    • OpenID Connect
  • Web Application Patterns
    • Single Sign On / Single Sign Off
    • Federation Gateway
    • Account & Identity Linking
    • Delegation
    • Home Realm Discovery

Day 2: Web APIs

  • ASP.NET Web API Security
    • Architecture
    • Authentication & Authorization
    • CORS
    • Katana Integration
  • Web API Patterns
    • Token-based Authentication
    • Delegated Authorization
  • OAuth2
    • Flows
    • Scopes
    • OAuth2 Middleware
    • Federation
  • OpenID Connect (revisited)
  • Bringing it all together

 

Posted in AuthorizationServer, Conferences & Training, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 14 Comments

Thinktecture.IdentityModel.Owin.*

To be more in-line with the OWIN / middleware mindset (and because Damian said so) – I broke up our OWIN security assembly into smaller components:

http://www.nuget.org/packages?q=Thinktecture.IdentityModel.Owin.*

Currently there are four packages:

  • Basic Authentication
  • X.509 client certificate authentication
  • Claims transformation
  • Requiring SSL and client certs

…plus a base package with various helpers…

A sample showing all four main packages together can be found here.

More to come…

Posted in IdentityModel, Katana, OWIN, WebAPI | Leave a comment

Using AuthorizationServer with Nancy (updated)

Since I am currently in the process of updating AuthorizationServer and its samples – I thought it would be the right time to throw away my custom Nancy extensions and use Damian Hickey’s nice Nancy.MSOwinSecurity package instead. The outcome is quite pleasing.

The Startup class now looks exactly like the Web API one (OWIN FTW yay):

public class Startup

{

    public void Configuration(IAppBuilder app)

    {

        // no mapping of incoming claims to Microsoft types

        JwtSecurityTokenHandler.InboundClaimTypeMap = ClaimMappings.None;

           

        // validate JWT tokens from AuthorizationServer

        app.UseJsonWebToken(

            issuer: Constants.AS.IssuerName,

            audience: Constants.Audience,

            signingKey: Constants.AS.SigningKey);

 

        // claims transformation

        app.UseClaimsTransformation(new ClaimsTransformer().Transform);

 

        app.UseNancy();

    }

}

…and the controller *cough* module looks like this:

public class IdentityModule : NancyModule

{

    public IdentityModule() : base(“/api/identity”)

    {

        this.RequiresMSOwinAuthentication();

 

 

        Get["/"] = _ =>

            {

                var user = Context.GetMSOwinUser();

                 

                var claims = from c in user.Claims

                                select new ViewClaim

                                {

                                    Type = c.Type,

                                    Value = c.Value

                                };

 

                return Response.AsJson<IEnumerable<ViewClaim>>(claims);

            };

    }

}

 

Full sample here.

Posted in AuthorizationServer, Katana, OAuth, OWIN | 5 Comments

AuthorizationServer v1.2

I just uploaded version 1.2 of AuthorizationServer.

The big change is that AS is now using MVC and Web API v5.1.1 – additionally there are some bug fixes and a new configuration switch – set the following appSetting to false if you want to pass through all incoming IdP claims (default is true):

<add key=”authz:FilterIncomingClaims” value=”true”/>

 

Posted in AuthorizationServer, OAuth, WebAPI | 3 Comments