The big advantage of claims based identity is that the burden of authenticating users is moved from the application to an identity server or identity provider. It’s important to understand the difference between authentication and authorization.
The Analogy
Here is an analogy, let's say that you want to get into a nightclub.
First, you need to be authenticated. By issuing a driver's license from the department of Motor Vehicles (analogous to the Identity Server), the state confirms your identity and generates a license, which includes data about you. The data includes information such as your name, your birth-date, your picture and so on. The token that you have been issued proves your identity.
Next, you make your way to the club, with the license in hand. Once you arrive, the bouncer obtains your name from your license and makes an authorization decision. “Is your name on the guest list?” The guest list acts as an approved claim in the system you want to access, which simply lists the people who are authorized to enter. If your name appears, then you are allowed access into the club.
In this rather simplified analogy, there is a clear separation between the entity that performs authentication (the state government), and the entity that performs authorized (the club bouncer).
Different protocols
Today the most common authentication protocols are OpenID Connect, WS-Federation and SAML2P. Where SAML2P are probably the most common protocol.
Microsoft Corporation has invested heavily into incorporating WS-Federation into its products. The most popular claim type for WS-Federation, ironically, is a SAML 1.1 Assertion. This leads people to think that WS-Federation and SAML can talk to each other. So when people talk about supporting SAML they really talking about support SAML claims inside WS-Federation.
OpenID Connect is only a couple years old, but is considered to be the future, since it provides the most possibilities for modern applications. It was also designed to be more usable by native and mobile applications, and to be WebAPI friendly.
Architecture scenario
IdentityServer3
In this scenario, one of the key components is the use of IdentityServer3 to replace the authentication in Episerver or any website. The IdentityServer3 is a popular open source security token service framework written in .NET, that implements the OpenID Connect and OAuth2 protocols. It is used to authenticate users via single-sign-on and to secure WebAPIs. It can be used stand-alone or in conjunction with other identity providers, such as Google, Facebook, Azure AD, ADFS and others.
IdentityServer3 supports different OpenId Connect flows that can be used in to communication between different types of clients.
If you are going to have some form of communication between two systems that doesn’t involve human, e.g. web API’s, then you should look into using "client credentials" flow.
Another one is the "Hybrid" flow. To avoid the users to reauthenticate every time they want to access a restricted area on the website you can use this flow, which contains the refresh token that’s used to obtain and renewed the identity token. I have written another blog post on how to connect Episerver and IdentityServer3 based on the OpenID Connect/OAuth2.0 protocol using the “Hybrid” flow. You can check that here:
http://sveinaandahl.blogspot.no/2016/04/how-to-setup-oauth20-integration.html
In some cases, where you will need to handle login with legacy systems it’s also possible to handle login screen on the website with the Resource Owner Flow, but this is usually not the recommended way. Depends on the goal and what kind of constrains you have.
For User Repository, IdentityServer3 supports both ASP.NET Identity 2.0 and MembershipReboot from Brock Allan. By using MembershipReboot you also have the ability to use nosql databases, like RavenDb and MongoDb.
I have done migration for users from Membership provider, which is the default authentication system in Episerver, to ASP.NET Identity 2.0 and had no problems to validate old passwords afterwards. You can read about that here:
http://sveinaandahl.blogspot.no/2016/03/how-to-validate-old-passwords-when.html
My experience is that ASP.NET Identity 2.0 need some “love” to perform just as good as the MembershipReboot do. And that ASP.NET Identity 2.0 got less features then MembershipReboot. But both choices are reasonable.
If a company has several brands, each with its own website, they might wish to customize the login screen for each brand. This is possible to do, to some degree with Identity Server. The screen dump below shows the login screen looks like default, customized with Norwegian language.
Extensibility and customization
In some cases, you e.g. want to be able to override the login process to validate other username than email, but also use phone number, member number and so on. Or maybe you want to validate if users exist and then populate claims from the CRM system during login process. Could also happened you want to be able verify that the user exists in the CRM system, before the user are allowed to register.
Since IdentityServer3 is designed for extensibility and customization and allows applications to satisfy their custom security requirements you will be able to do that. But you should always be very careful how your stitching this together to avoid security breach in your system.
Scalability
The IdentityServer3 is very scalable. The application is built in a way that setting it up in a load balanced environment is quite easy. Performance challenges is usually depended on what choices you have made when it comes to user repository and if you have extended and customized the login process in good way.
Links
For those who use Xamarin to build mobile applications on iOS or Android. Here is an example how to integrate Xamarin with Identity Server:
In some cases, you e.g. want to be able to override the login process to validate other username than email, but also use phone number, member number and so on. Or maybe you want to validate if users exist and then populate claims from the CRM system during login process. Could also happened you want to be able verify that the user exists in the CRM system, before the user are allowed to register.
Since IdentityServer3 is designed for extensibility and customization and allows applications to satisfy their custom security requirements you will be able to do that. But you should always be very careful how your stitching this together to avoid security breach in your system.
Scalability
The IdentityServer3 is very scalable. The application is built in a way that setting it up in a load balanced environment is quite easy. Performance challenges is usually depended on what choices you have made when it comes to user repository and if you have extended and customized the login process in good way.
Links
For those who use Xamarin to build mobile applications on iOS or Android. Here is an example how to integrate Xamarin with Identity Server:
If you are interested in finding out more about IdentityServer3 it’s a good start to begin here:
For those who are interested, then Identity Server will also be supported for ASP.NET 5 when it’s launched.
Hi there Svein! Love your post. Do you think you can add a link to auth0.com when you mention it to give more context about the solution?
ReplyDeleteCheers!