Mixing UI and API Endpoints in ASP.NET Core 2.1 (aka Dynamic Scheme Selection)

Some people like to co-locate UI and API endpoints in the same application. I generally prefer to keep them separate, but I acknowledge that certain architecture styles make this conscious decision.

Server-side UIs typically use cookies for authentication (or a combination of cookies and OpenID Connect) and APIs should use access tokens – and you want to make sure that you are not accepting cookies in the API by accident.

Since authentication of incoming calls in ASP.NET.Core are abstracted by so called authentication handlers, and you can register as many of them as you want – you can support both authentication scenarios. That’s by design.

One way you could implement that is explicitly decorating every controller with an [Authorize] attribute and specify the name of the authentication scheme you want use. That’s a bit tedious, and also error prone. I prefer to have a global authorization policy that denies anonymous access and then rather opt-out of that with [AllowAnonymous] where needed.

This did not work prior to ASP.NET Core 2.1 because global policies rely on the default scheme configuration – but since we have two different schemes, there is no default. The effect would be e.g. that you would get a redirect to a login page for an anonymous API call where you would have expected a 401.

In ASP.NET Core 2.1 there is a new feature where you can dynamically select the authentication scheme based on the incoming HTTP request. Let’s say e.g. all your API endpoint are below /api – you could define a rule that for requests to that path you would use JWT tokens – and for all other, OpenID Connect with cookies. You do that by adding a forward selector to the authentication handler like this:

options.ForwardDefaultSelector = ctx =>
{
    if (ctx.Request.Path.StartsWithSegments("/api"))
    {
        return "jwt";
    }
    else
    {
        return "cookies";
    }
};

For a full sample – see here.

Posted in ASP.NET Core, OpenID Connect, Uncategorized, WebAPI | 14 Comments

Improvements in Claim Mapping in the ASP.NET Core 2.1 OpenID Connect Handler

Here I described the various layers of claim mappings going on when doing OpenID Connect with ASP.NET Core.

Based on our feedback, the ASP.NET team added another mapping option to reduce the amount of “magic” going on, and thus makes it less confusing to get the expected claims in your client applications.

The new mapping is called MapAllExcept which does exactly what you think it does – it maps all the claims except the ones you don’t care about, e.g.:

options.ClaimActions.MapAllExcept("iss""nbf""exp""aud""nonce""iat""c_hash");

This strips the protocol claims that you are not interested in, and all other claims get mapped forward (sample here). You still have to opt-out from the mapping to Microsoft proprietary claims – but well, we’ll get there eventually…

Posted in ASP.NET Core, OpenID Connect, Uncategorized | 2 Comments

The State of HttpClient and .NET Multi-Targeting

IdentityModel is a library that uses HttpClient internally – it should also run on all recent versions of the .NET Framework and .NET Core.

HttpClient is sometimes “built-in”, e.g. in the .NET Framework, and sometimes not, e.g. in .NET Core 1.x. So fundamentally there is a “GAC version” and a “Nuget version” of the same type.

We had lots of issues with this because it seemed regardless in which combination you are using the flavours of HttpClient, this will lead to a problem one way or another (github issues). The additional confusion was added by the fact that the .NET tooling had certain bugs in the past that needed workarounds that lead to other problems when those bugs were fixes in later tooling.

Long story short – every time I had to change the csproj file, it broke someone. The latest issue was related to Powershell and .NET 4.7.x (see here).

I once and for all wanted an official statement, how to deal with HttpClient – so I reached out to Immo (@terrajobst) over various channels. Turns out I was not alone with this problem.

Screenshot 2018-05-21 07.43.06

Despite him being on holidays during that time, he gave a really elaborate answer that contains both excellent background information and guidance.

I thought I should copy it here, so it becomes more search engine friendly and hopefully helps out other people that are in the same situation (original thread here).

“Alright, let me try to answer your question. It will probably have more detail than you need/asked for but I might be helpful to start with intention/goals and then the status quo. HttpClient started out as a NuGet package (out-of-band) and was added to the .NET Framework in 4.5 as well (in-box).

With .NET Core/.NET Standard we originally tried to model the .NET platform as a set of packages where being in-box vs. out-of-band no longer mattered. However, this was messier and more complicated than we anticipated.

As a result, we largely abandoned the idea of modeling the .NET platform as a NuGet graph with Core/Standard 2.0.

With .NET Core 2.0 and .NET Standard 2.0 you shouldn’t need to reference the SystemNetHttpClient NuGet package at all. It might get pulled from 1.x dependencies though.

Same goes for .NET Framework: if you target 4.5 and up, you should generally use the in-box version instead of the NuGet package. Again, you might end up pulling it in for .NET Standard 1.x and PCL dependencies, but code written directly against .NET Framework shouldn’t use it.

So why does the package still exist/why do we still update it? Simply because we want to make existing code work that took a dependency on it. However, as you discovered that isn’t smooth sailing on .NET Framework.

The intended model for the legacy package is: if you consume the package from .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+ the package only forwards to the platform provided implementation as opposed to bring it’s own version.

That’s not what actually happens in all cases though: the HTTP Client package will (partially) replace in-box components on .NET Framework which happen to work for some customers and fails for others. Thus, we cannot easily fix the issue now.

On top of that we have the usual binding issues with the .NET Framework so this only really works well if you add binding redirects. Yay!

So, as a library author my recommendation is to avoid taking a dependency on this package and prefer the in-box versions in .NET Framework 4.5, .NET Core 2.0 and .NET Standard 2.0.

Thanks Immo!

Posted in IdentityModel, Uncategorized, WebAPI | 1 Comment

NDC London 2018 Artefacts

“IdentityServer v2 on ASP.NET Core v2: An update” video

“Authorization is hard! (aka the PolicyServer announcement) video

DotNetRocks interview audio

 

Posted in ASP.NET Core, IdentityServer, PolicyServer, Uncategorized, WebAPI | Leave a comment

Native OIDC client sample for Windows that uses custom URI scheme handler

brockallen

Since the release of our IdentityModel.OidcClient client library we have had iOS and Android samples for using the system browser to allow a user to authenticate with the token server. Receiving the results from the system browser is interesting since the native client application is in a different process than the system browser. Fortunately those platforms provide an easy way to map a custom URI scheme (used in the client’s redirect_uri) to the native client application. This allows the response parameters from the authorize endpoint to be passed from the system browser into the native client so it can complete the protocol workflow.

Windows also has such a facility, but we never had a sample for it… until now. I just created a sample that does this.

There are two main aspects that are specific to Windows clients. First, the application needs to add certain registry keys to enable…

View original post 93 more words

Posted in Uncategorized | 1 Comment

Announcing PolicyServer

Over the course of the last years Brock, Michele and I have all been actively designing and implementing identity solutions for customers of all sizes and industries. Solutions range from simple to complex – and almost always involve both identity (authentication) and access management (authorization).

It turns out that, for authentication there is pretty much always only one right way to do it, once you know all the facts and requirements. Once you are done with the “who is the user” (aka authentication) part, you will inevitably need to solve the “and what is this user allowed to do” (aka authorization) problem next.

So, many people asked us to provide the same turnkey solution for authorization as we do for authentication with IdentityServer.

One very tempting fallacy is that you can use your new and shiny identity system to also distribute authorization data to your applications. This will not work! Despite what some vendors try to tell you when selling their “Identity and Access Management” solution. Identity is universal – authorization is application specific. Blurring those lines will get you in trouble. Back in 2016 I wrote a pretty popular blog post about that – and last year Brock and I did a talk about our ideas at NDC. I don’t want to repeat all that again here.

Since we never really had a good answer, we decided to dedicate some time to think about the problem. We started by observing how our customers implemented their authorization in the past. The results were quite interesting – from highly specialized application logic to “standard” concepts like access control lists (ACLs) or (the failed) XACML, we found that the most prevalent general concept that people use is roles and permissions.

While this doesn’t sound like rocket science – almost no-one took the time to build a general solution for that. They rather re-implemented one or the other aspect of this pattern over and over again for each application they were building.

This was our starting point for what we now call PolicyServer (watch the above NDC video to see an early prototype). We had the following key tenets in mind.

Built from the ground-up for modern applications

With that we mean the modern multi-client, multi-platform, API-driven systems that companies implement today. It must be compatible with all current prevalent architecture styles like cloud, microservices, multi-tenancy (you name it) and of course, uses claims-based identity at its core.

Identity != Permissions

There will be a strict separation of authentication and authorization. This way you can keep your architecture clean and ready for growth. Everything else will become a problem when your software becomes more complex than initially planned.

Identity + Permissions == Authorization

Identity will be the input to the authorization system. A user will most likely have different permissions in different applications – the combination of identity and context produces the actual authorization policy.

Enter PolicyServer

So simply said – PolicyServer allows you to model applications roles, membership and permissions for your applications. But of course, there is much more to it.

Policy design

We want to be able to model arbitrary applications styles – from simple, single applications to application systems and multi-tenanted applications. In PolicyServer, policies are containers for application roles and their associated permissions, but policies can be hierarchical and support inheritance.

Role membership

Membership to application roles can be defined statically (and drawn from the separate identity system) or based on rules and claims-transformation.

Permissions

Permissions belong to application roles. In your applications, you can use the application roles for coarse grained authorization, and permissions for fine-grained authorization.

Management API and UI

Every management aspect of PolicyServer is API first. There is a full-featured web-based UI for managing policies – but you can also automate everything, or drive policy creation and permission management from your own application.

Auditing and compliance

Permission usage and policy evaluation can be fully audited and the resulting audit trail can be tailored to meet common compliance criteria.

Client libraries

So far we have focused mainly on .NET – this includes a base client library, but also support and deep integration into the new ASP.NET Core policy-based authorization system. This has also been back-ported to MVC5/Web API 2. In the future we will support more common application platforms – but given the API nature of our runtime engine, integration is trivial.

 

The three of us all have implemented authorization products and solutions for customers in the past, and so PolicyServer is the result of us collaborating – as we all shared a passion for the problem space.

While implementing more and more pieces, it became pretty clear, that this is a lot of work. Given our engagement with our existing open source projects like IdentityServer and IdentityModel, we couldn’t afford to start another OSS project. That’s why we decided to create two versions of PolicyServer.

One version is a free OSS version that includes all the necessary bits and pieces to implement the separation of concerns between authentication and authorization. But it will be for a single application only and not include the management pieces or the advanced modeling capabilities.

The other version is a commercial product that has all the above-mentioned features –  and if you think that would be a good fit for your application – let’s have a chat!

Posted in PolicyServer | 20 Comments

NDC London 2018: IdentityServer Update

We are at NDC in London right now and are about to start our session “IdentityServer4 v2 on ASP.NET Core v2 – an Update”.

For those who can’t be here – you can find my slides on Speakerdeck. There will be also a video recording in a couple of weeks.

Here’s a quick summary.

New web site

Just in time before NDC we managed to release our new web site at https://identityserver.io. This also finally includes a selection of reference customers that we can publicly talk about.

The new ASP.NET Core v2 authentication system

This is the main part of our talk. For the last couple of year Microsoft had a hard time finding the right balance between flexibility and ease of use when it comes to authentication in ASP.NET. That’s why they had to re-write authentication from ASP.NET to Katana to ASP.NET Core v1 to ASP.NET Core v2.

It’s fair to say that that the current version is pretty good – still not exactly the way we like to have it – but it mostly gets the job done. This is also the starting point of our demo.

We gonna show how IdentityServer4 makes use of the new authentication handler system, the new authentication middleware and its DefaultXXX configuration. We show how to use a custom cookie handler instead of ours, how to add support for social logins like Google, how to add WS-Federation support (aka legacy ADFS support – because why else would you care about WS-Federation). We’ll show the brand new SAML authentication handler from Anders Abel and we’ll show how to utilize the new authentication system to add additional API endpoints to your IdentityServer host which are in turn protected by IdentityServer itself – inception!

Speaking of SAML2p – our partner Rock Solid Knowledge has a brand new plugin for IdentityServer4 v2 that adds SAML2p IdP capabilities and allows SSO over OpenID Connect, SAML and WS-Federation.

Logout is hard!

In the information age, data is the new pollution. And it is much harder to get rid of data than to accumulate it. That’s why OpenID Connect has three specs for logout. We always had support for JavaScript-based session management and front-channel notifications. We also added support for back-channel notifications which are generally speaking more reliable then the good old browser iframe “trick” (aka hack). We have a sample for that here.

Admin UI Community Edition

Rock Solid Knowledge created a community edition of their AdminUI product. This gives you a web-based UI to manage users, clients, claims, resources etc. The community edition is limited to 10 users and 2 clients, which is enough to get started.

Best thing is, the AdminUI is available via a dotnet new template. IOW – you’ll have a functional IdentityServer with user and configuration management up and running literally in a couple of seconds. See our templates repo here.

Supporting us

Running an open source project like IdentityServer takes time and effort. We could use your help!

To make that easier for you, we try to be better with up for grabs issues in the future. If you want to get started with contributing to IdentityServer – look for the help wanted label on our issue tracker, and start a conversation. We are happy to help out.

We also see quite some traffic on StackOverflow – if you want to help out other users (and earn some reputation while you go), that would be very appreciated.

And last but not least – if you are working for a company that uses IdentityServer4, you should encourage your boss to sponsor us. This will allow us to expand our efforts – and btw – we also have some interesting marketing options if you company wants to position itself as modern and thus OSS friendly/supporting. Go check out our Patreon page for more info.

Supporting you

Brock and I are still doing on-site/remote training and consulting. Let us know if we can help you with anything in the identity & access control space!

We also have an infrastructure to offer production support.

OK – that’s it for IdentityServer4. We have more exciting news here at NDC – stay tuned.

Posted in .NET Security, ASP.NET Core, IdentityServer, Uncategorized | Leave a comment