Quantcast
Channel: IdentityModel – leastprivilege.com
Viewing all 204 articles
Browse latest View live

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

$
0
0

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

 


Filed under: AuthorizationServer, Conferences & Training, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI

OpenID Connect and the IdentityServer Roadmap

$
0
0

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


Filed under: AuthorizationServer, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI

OAuth2 and OpenID Connect Scope Validation for OWIN/Katana

$
0
0

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.


Filed under: IdentityModel, Katana, OAuth, OpenID Connect, OWIN, WebAPI

Announcing Thinktecture IdentityServer v3 – Preview 1

$
0
0

The last months we’ve been heads down re-writing IdentityServer from scratch (see here for background) – and we are now at a point where we think we have enough up and running to show it to you!

What we’ve done so far

  • Started with File –> New
  • Implemented OpenID Connect basic and implicit client profile (including support for form post response mode)
  • Implemented support for OpenID Connect discovery documents and session logout
  • Implemented OAuth2 code, client credentials, password and assertion grants
  • Created a general purpose login page and consent screen for local and external accounts
    • created out of the box support for MembershipReboot and ASP.NET Identity
    • integrated existing Katana authentication middleware for social providers
      • and made that all pluggable
  • Defined an authorization enforcement policy around clients, flows, redirect URIs and scopes
  • Designed everything to run on minimal data access interfaces so you can seamlessly scale from in-memory objects to simple config files up to relational or document databases for configuration and state management
  • Designed everything to be API-first
  • Defined several extensibility points that allow customization of request validation, token creation, claims acquisition and transformation and more
    • and yes, we don’t use MEF anymore …
  • Split up IdSrv into composable components like core token engine and authentication, configuration APIs, configuration UIs and user management
    • These components use OWIN/Katana and Web API as abstractions which means we have quite a bit of flexibility when it comes to logical hosting – embeddable in an existing application or standalone
    • When it comes to physical hosting, we have no dependency on IIS and System.Web which means you can use a command line, OWIN host, an NT Service, of course IIS or any other OWIN/Katana compatible server

Minimal startup code:

public void Configuration(IAppBuilder app)

{

    app.Map(“/core”, coreApp =>

        {

            var factory = TestOptionsFactory.Create(

                issuerUri:         https://idsrv3.com,

                siteName:          “Thinktecture IdentityServer v3″,

                certificateName:   “CN=idsrv3test”,

                publicHostAddress: http://localhost:3333);

                   

            var opts = new IdentityServerCoreOptions

            {

                Factory = factory,

            };

 

            coreApp.UseIdentityServerCore(opts);

        });

}

What’s missing?

  • quite a bit, e.g.
  • a persistence layer for configuration and state – everything is in-memory right now which is good enough for testing
  • Refresh tokens
  • Admin UI and APIs
  • OpenID Connect session management and cleanup
  • Support for WS-Federation and OpenID Connect based identity providers for federation
  • A lot more testing
  • Your feedback!

What’s next?

  • We’ve defined several milestones over the next months for implementing the next rounds of features. We currently plan to be done with v1 around end of summer.
  • Participate in OpenID Connect compatibility and interop testing (see here).

Where to get it?

The github repo is here, the issue tracker here and the wiki here. We also recorded videos on Overview, Samples Walkthrough and Extensibility Check them out…

Oh – and I should mention – while designing IdentityServer v3 we realized that we really also need a good solution for managing users, identity, claims etc – and that this should be ideally a separate project – so I’d also like to announce Thinktecture IdentityManager – head over to Brock’s blog to find out more!!!

Looking forward to your feedback!


Filed under: ASP.NET, AuthorizationServer, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI

100k Downloads of Thinktecture IdentityModel

Resource/Action based Authorization for OWIN (and MVC and Web API)

$
0
0

Authorization is hard – much harder than authentication because it is so application specific. Microsoft went through several iterations of authorization plumbing in .NET, e.g. PrincipalPermission, IsInRole, Authorization configuration element and AuthorizeAttribute. All of the above are horrible approaches and bad style since they encourage you to mix business and authorization logic (aka role names inside your business code).

WIF’s ClaimsPrincipalPermission and ClaimsAuthorizationManager tried to provide better separation of concerns – while this was a step in the right direction, the implementation was “sub-optimal” – based on a CLR permission attribute, exception based, no async, bad for unit testing etc…

In the past Brock and me worked on more modern versions that integrate nicer with frameworks like Web API and MVC, but with the advent of OWIN/Katana there was a chance to start over…

Resource Authorization Manager & Context
We are mimicking the WIF resource/action based authorization approach – which proved to be general enough to build your own logic on top. We removed the dependency on System.IdentityModel and made the interface async (since you probably will need to do I/O at some point). This is the place where you will centralize your authorization policy:

public interface IResourceAuthorizationManager

{

    Task<bool> CheckAccessAsync(ResourceAuthorizationContext context);

}

 

(there is also a ResourceAuthorizationManager base class with some easy to use helpers for returning true/false and evaluations)

The context allows you to describe the actions and resources as lists of claims:

public class ResourceAuthorizationContext
{
    public IEnumerable<Claim> Action { get; set; }
    public IEnumerable<Claim> Resource { get; set; }
    public ClaimsPrincipal Principal { get; set; }
}

 

Middleware
The corresponding middleware makes the authorization manager available in the OWIN enviroment:

public void Configuration(IAppBuilder app)
{
    var cookie = new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookie",
        ExpireTimeSpan = TimeSpan.FromMinutes(20),
        LoginPath = new PathString("/Login"),
    };
    app.UseCookieAuthentication(cookie);
 
    app.UseResourceAuthorization(new ChinookAuthorization());
}

 

Usage
Since the authorization manager is now available from the environment (key: idm:resourceAuthorizationManager) you can get ahold of it from anywhere in the pipeline, construct the context and call the CheckAccessAsync method.

The Web API and MVC integration packages provide a ResourceAuthorize attribute for declarative checks:

[ResourceAuthorize(ChinookResources.AlbumActions.View, ChinookResources.Album)]

 

And several extension methods for HttpContextBase and HttpRequestMessage, e.g.:

if (!HttpContext.CheckAccess(
    ChinookResources.AlbumActions.Edit,
    ChinookResources.Album,
    id.ToString()))
{
    return new HttpUnauthorizedResult();
}

 

or..

var result = Request.CheckAccess(
    ChinookResources.AlbumActions.Edit,
    ChinookResources.Album,
    id.ToString());

 

Testing authorization policy
Separating authorization policy from controllers and business logic is a good thing, centralizing the policy into a single place also has the nice benefit that you can now write unit tests against your authorization rules, e.g.:

[TestMethod]
public void Authenticated_Admin_Can_Edit_Album()
{
    var ctx = new ResourceAuthorizationContext(User("test", "Admin"),
        ChinookResources.AlbumActions.Edit,
        ChinookResources.Album);
    Assert.IsTrue(subject.CheckAccessAsync(ctx).Result);
}

 

or…

[TestMethod]
public void Authenticated_Manager_Cannot_Edit_Track()
{
    var ctx = new ResourceAuthorizationContext(User("test", "Manager"),
        ChinookResources.TrackActions.Edit,
        ChinookResources.Track);
    Assert.IsFalse(subject.CheckAccessAsync(ctx).Result);
}

 

Code, Samples, Nuget
The authorization manager, context, middleware and integration packages are part of Thinktecture.IdentityModel – see here.

The corresponding Nuget packages are:

..and here’s a sample using MVC (if anyone wants to add a Web API to it – send me a PR).


Filed under: ASP.NET, IdentityModel, Katana, OWIN, WebAPI

NDC London: Identity and Access Control for modern Web Applications and APIs

Identity & Access Control at NDC London 2014

$
0
0

The NDC Agenda is out now – and Brock and me will do a number of identity & access control related sessions.

Brock will talk about identity management in ASP.NET – which is a huge topic – so he split up his talk into two sessions. I will cover OpenID Connect and OAuth2 – and especially the combination of the two protocols. Looking forward to that!

In addition we will do a 2-day workshop on monday/tuesday titled: “Identity & Access Control for modern Web Applications & APIs” – this will be deep dive in all the things you need to know to implement authentication and authorization into modern distributed applications. See the agenda here.

Early bird ends on 15th October – would be cool to meet you there and talk about security!


Filed under: .NET Security, ASP.NET, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI

.NET Foundation Advisory Council

Security at NDC Oslo

$
0
0

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!


Filed under: .NET Security, IdentityModel, IdentityServer, OAuth, OpenID Connect, WebAPI

IdentityModel 1.0.0 released

$
0
0

Part of the ongoing effort to modernize our libraries, I released IdentityModel today.

IdentityModel contains useful helpers, extension methods and constants when working with claims-based identity in general and OAuth 2.0 and OpenID Connect in particular.

See the overview here and nuget here.

Feedback and PRs welcome.


Filed under: .NET Security, IdentityModel, OAuth, OpenID Connect, WebAPI

Web API Security: JSON Web Token/OAuth2 with Thinktecture.IdentityModel AuthenticationHandler

$
0
0

(OK – I only included OAuth2 in the title to get your attention – this applies to whatever framework or technology you use to work with JSON web tokens aka JWTs)

Following the pattern from my two previous posts, you can also validate JWTs with a simple extension method over the basic AddMapping functionality.

For validating a JWT you need to specify three items:

  • The name of the issuer that you expect the JWT to come from (an identity provider or authorization server)
  • The expected audience (a symbolic name of the service consuming the JWT)
  • The key material to validate the signature (either a symmetric key or a X.509 certificate)

The following method adds a mapping for an incoming Authorization header with a scheme of Bearer – the response will also contain the Bearer scheme. The key used is a symmetric key:

authentication.AddJsonWebToken(

    issuer: Constants.IdSrv.IssuerUri,

    audience: Constants.Audience,

    signingKey: Constants.IdSrv.SigningKey);

 

The current extension methods of IdentityModel uses my own JWT implementation – but in the sample (as well as in the latest IdentityServer version) I have already switched to Microsoft’s JWT handler. The signature of the extension methods stay the same.

Given the flexibility of the AuthenticationHandler, you can also fetch the JWT from other places like an alternative header or a query string. Another emerging pattern is to return the audience of the service and the URL of the token endpoint in the 401 response – again – easy to accomplish:

authentication.AddJsonWebToken(
    issuer: Constants.IdSrv.IssuerUri,
    audience: Constants.Audience,
    signingKey: Constants.IdSrv.SigningKey,
    options: AuthenticationOptions.ForAuthorizationHeader("Bearer"),
    scheme: AuthenticationScheme.SchemeAndChallenge(
        "urn:myapi", "url=https://idsrv.local/issue/token"));

 

HTH


Filed under: .NET Security, IdentityModel, IdentityServer, OAuth, WebAPI

Support for X.509 Client Certificates in Thinktecture.IdentityModel for Web API

$
0
0

An old post. But since I am writing about AuthenticationHandler..this is still relevant!

leastprivilege.com

Another RTM feature I was waiting for is (reasonable) SSL client certificate support in Web API.

Just like all the other authentication methods, you configure client certificate support on the AuthenticationConfiguration object. The following code configures the certificate to chain validation + check for a specific issuer subject name:

Validation modes are:

  • Chain validation only
  • Peer validation
  • Chain validation + issuer certificate thumbprint
  • Chain validation + issuer subject name
  • Thumbprint only

On the client side, this is the necessary code to include a client certificate with the call:

client.GetAsync(

 

The code + client sample is in the github repository. Nuget will be updated soon.

View original post


Filed under: ASP.NET, IdentityModel, Uncategorized, WebAPI

ASP.NET Web API Authentication: Using multiple (simultaneous) Authentication Methods with Thinktecture AuthenticationHandler

$
0
0

Since day one it was possible to support multiple authentication methods with AuthenticationHandler (see here, here and here for some background). I simply stopped searching for other credentials once I found one of the registered ones. Since one of my clients also needed a feature to support multiple simultaneous authentication methods, I finally found the time to add this feature.

AuthenticationHandler will now search for all registered credential mappings and add each resulting claims identity to a claims principal. This allows for scenarios where you want to support e.g. SSL client certificates in addition to Basic Authentication – or in delegation style scenarios where you need to transmit two sets of credentials – the direct caller as well as the original client credentials.

After all identities have been hydrated from the registered credentials, you can also optionally run a claims authentication manager to normalize the multiple identities into a unified single identity again.

The server configuration could e.g. look like this:

authentication.AddBasicAuthentication(UserCredentials.Validate);

authentication.AddClientCertificate(ClientCertificateMode.ChainValidation);

 

…and the corresponding client:

var handler = new WebRequestHandler();
handler.ClientCertificates.Add(
    X509.CurrentUser.My.SubjectDistinguishedName.Find("CN=Client").First());
 
var client = new HttpClient(handler) {
    BaseAddress = _baseAddress
};
 
client.SetBasicAuthentication("bob", "bob");

 

The resulting ClaimsPrincipal will then hold two identities, one containing claims for the Basic Authentication (name) and one containing claims for the client certificate (thumbprint, common name, serial number, public key, etc…)

The sample can be found here. Nuget will be updated soon.

HTH


Filed under: IdentityModel, Uncategorized, WebAPI

Two Weeks to go: NDC Identity & Access Control Workshop


Update on IdentityModel and IdentityServer

OAuth2 done right

$
0
0

I think I mentioned once or twice that OAuth2 is not for authentication. It is rather a set of patterns for doing delegated authorization for HTTP/Web APIs using access tokens. But most people don’t use it like that.

OAuth2 is far from perfect and regardless of what you might have heard about it (see here)– it has some concepts that are useful for the architecting “modern applications”.

Making the client a first class citizen
Unlike in enterprise development where everything is typically part of a big trusted subsystem, OAuth2 takes the software that the human is using to access services into account. Many of my customers are building applications that revolve around a set of Web APIs and a set of client applications that will access them. Sometimes these client applications will be built by themselves, sometimes by a trusted partner, sometimes by some (unknown) third party. Sometimes these apps are side-loaded, sometimes deployed via an app store (sometimes they are just normal old-school web applications). The user (aka the resource owner in OAuth speak) might even use multiple clients throughout the day to access the same backend services.

Clearly we need a way to deal with multiple clients and even multiple client types (server vs client vs devices apps). And even if OAuth2 out of the box has not a good answer for everything, it is important to make that fact a fundamental part of the security architecture.

The concept of consent
Again, this might not apply to every situation (and also might not be perfect), but giving users information about what permissions a client will get and – more importantly – giving them a choice is a nice feature.

Access tokens are so much better than usernames and passwords
Well we all know that. OAuth2 goes long ways trying to minimize the exposure of “master secrets” like passwords. Either by exchanging the password with an access token very early in the process, or by giving the client no access at all to the passwords. Access tokens can have limited access to a resource, they can be renewed, they can be revoked – and they are not passwords that might end up unprotected on some client device.

Cross-platform
That’s pretty much a requirement these days. OAuth2 uses HTTP primitives to make it work on arbitrary OSes and devices.

Modeling application resources
Scopes are a way to logically group functionality in your application, e.g ‘Read data’ or ‘Delete data’. Combined with the concept of a client, you can model applications quite nicely. Especially when your OAuth2 authorization server is feature rich enough to control which client can use which flow and can request which scope for which application etc. This makes for a nice abstraction layer and provides coarse-grained authorization.

The resulting access token can contain information about the audience (application), the scopes (permission), the subject (resource owner) and the client (the software used). The resource server can go from there and provide its part of the authorization story.

ASoverview

Works for me.


Filed under: IdentityModel, IdentityServer, OAuth, WebAPI

Announcing Thinktecture AuthorizationServer

$
0
0

Today at NDC I announced Brock’s and my new open source project – Thinktecture.AuthorizationServer.

AuthorizationServer (AS from now on) is an implementation of the OAuth2 patterns I described here.It has an implementation of the four OAuth2 flows and a nice UI that let’s you model your applications, clients and scopes. It also includes samples that you can go through to see what it does.

I am still at NDC and will publish all the slides and more information in the next days. Brock will give us more details on the administration side of things.

I am really glad the talks went so well and that the attendees liked our approach to API authorization. If you care, have a look at the repo and give us feedback – we are still in very early stages.

https://github.com/thinktecture/Thinktecture.AuthorizationServer


Filed under: Conferences & Training, IdentityModel, IdentityServer, OAuth, WebAPI

NDC Oslo 2013 Slides

IdentityModel v3 changes

$
0
0

I have updated all the projects (IdentityModel, IdentityServer and AuthorizationServer) and the corresponding samples to the GA version of the Microsoft JWT handler.

While doing that, I took the opportunity to clean up IdentityModel quite a bit. This resulted in breaking changes – but I also increased the version number to v3, which means that Nuget will not automatically update.

What has changed?
I removed all my JWT and SWT plumbing (the tokens, handlers and “helper” classes). JWT is completely replaced by Microsoft’s JWT handler…and SWT is gone. I also removed some of the older authorization bits that were never really used.

What does that mean for Web API and AuthenticationHandler?
Nothing! The configuration extension methods still have the same signatures, but use the MS JWT handler under the covers now. But you have more options now – in addition to symmetric signing keys, you can also use X.509 certificates and you can control how the handler maps JWT claims to .NET claims, e.g:

authentication.AddJsonWebToken(

    issuer: Constants.IdSrv.IssuerUri,

    audience: Constants.Audience,

    signingKey: Constants.IdSrv.SigningKey);

 

Wires up the JWT handler with a symmetric signing key and the standard MS claims mappings.

The next snippet turns claims mappings completely off:

authentication.AddJsonWebToken(
    issuer: Constants.AuthzSrv.IssuerName,
    audience: Constants.Audience,
    signingKey: Constants.AuthzSrv.SigningKey,
    claimMappings: ClaimMappings.None);

 

Instead of ClaimMappings.None you can also pass in a dictionary to define your own mappings.

The source code is on github, the Nuget is here.


Filed under: IdentityModel, WebAPI
Viewing all 204 articles
Browse latest View live