All this Microsoft Membership Identity stuff — what’s it about?

I originally started blogging because I was answering the same questions over and over on stackoverflow. I decided to write it up once and then point to the post for future questions.

Hence this post — I get tons of questions about all the Identity functionality that Microsoft provides and how the components differ and when should you use what.

A number of these questions are around the Membership providers.

This post is from the PoV of Membership and hopefully shows how it can integrate with the rest of the stack.

Imagine you are asked to create a web site for a lot of users and they all need to authenticate with a logon and password and have some kind of role handling for authorisation. The credentials are stored in a repository — typically a SQL database.

Membership

Now you could write all the authentication yourself but since this was such a common use case, Microsoft provided the ASP.NET Membership feature. This provided all the required functionality OOTB and all you had to do was hook into it.

It included an ASP.NET Role provider.

“ ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. You can use ASP.NET membership with ASP.NET Forms authentication or with the ASP.NET login controls to create a complete system for authenticating users.”

If you didn’t like the OOTB features, you could write a custom membership provider e.g. using some other database.

There’s a good summary here and it also covers ASP.NET simple membership and ASP.NET Universal Providers.

There were some issues with Membership and this resulted in an open-source implementation called MembershipReboot.

“ MembershipReboot is a user identity management and authentication library. It has nothing to do with the ASP.NET Membership Provider, but was inspired by it due to frustrations with the built-in ASP.NET Membership system. The goals are to improve upon and provide missing features from ASP.NET Membership. It is designed to encapsulate the important security logic while leaving most of the other aspects of account management either configurable or extensible for application developers to customize as needed.”

(Note: “As of 2017 MembershipReboot will no longer be maintained. It has served its purpose, and ASP.NET Identity has finally caught up (and surpassed) this library in terms of security and functionality”).

Microsoft took all the feedback on-board and this resulted in ASP.NET Identity.

Among its advantages are:

• ASP.NET Identity can be used with all of the ASP.NET frameworks, such as ASP.NET MVC, Web Forms, Web Pages, Web API, and SignalR
• ASP.NET Identity can be used when you are building web, phone, store, or hybrid applications
• ASP.NET Identity supports claims-based authentication, where the user’s identity is represented as a set of claims
• ASP.NET authentication is now based on OWIN middleware that can be used on any OWIN-based host

So now you have a web site and you can use the above to handle all the credentials and roles securely for you.

And then your boss comes along and asks:

“We are partnering with another company and they need access to our application”.

Which means that their credentials need to be in your database. And that’s non-optimal because their credentials are already in their own company database. Why can’t we just use those?

With the above membership providers, you can’t authenticate with external providers.

But you can do this if you add an Identity Provider (IDP).

An Identity Provider has its own credential repository and supports a set of Identity protocols:

• OpenID Connect / OAuth 2.0
• WS-Federation
• SAML 2.0

Using these protocols, different IDP can talk to each other using federation.

IDP

In the Microsoft world, these include:

• Azure Active Directory (AAD)
• Azure Active Directory Business to Consumer (AAD B2C)
• Active Directory Federation Services (ADFS)

I compared these products in a previous post.

Very basically:

AAD is Identity as a service for corporates so typically domain joined accounts e.g. joe@company.co.nz. It’s cloud based. The repository is accessed via a Graph API.

AAD B2C is Identity as a service for a corporate’s customers so typically not domain joined accounts e.g. joe@hotmail.com. It’s cloud based. The repository is accessed via a Graph API.

ADFS is on-premises for corporates so typically domain joined accounts. The repository is AD and is accessed via LDAP.

With that overview, back to the bosses question.

IdentityServer

The IDP product for ASP.NET Identity that is referenced in the Microsoft documentation is IdentityServer.

If you are using ASP.NET Identity, you can use IdentityServer 3.

If you are using ASP.NET Core Identity, you can use IdentityServer 4.

“ IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.

It has support for a federation gateway. This provides support for external identity providers like Azure Active Directory, Google, Facebook etc.”.

IdentityServer handles the federation protocol aspect. It does not have support for user provisioning i.e. user CRUD. That’s why the IdentityServer 4 template for ASP.NET Core Identity has a seed option to add some test users to the database.

ASP.NET Core Identity provides CRUD support. It can be augmented via the scaffolding option.

Scaffolding adds:

The email confirmation and password reset functionality requires you to complete the email code.

Notice you also get multi-factor authentication (2FA) with a code or you can add a QR code.

By using IdentityServer 4 and ASP.NET Core Identity together, you get the best of both worlds.

If you are looking for a commercial product to do provisioning for IdentityServer, have a look at AdminUI.

And IdentityServer can federate with other IDP including the Microsoft ones mentioned above.

You need to modify the existing application to talk to IdentityServer 4. As it still talks to the ASP.NET Identity database, the users and credentials are still the same.

Microsoft Identity Platform

As an aside, the documentation also refers to the “Microsoft identity platform. This is:

• “An evolution of the Azure Active Directory (Azure AD) developer platform
• Unrelated to ASP.NET Core Identity”

Essentially, it’s a collection of client side libraries used to communicate to the Microsoft IDP above via the protocols above.

It comprises:

• Azure Active Directory Authentication Library (ADAL) v1.0
• Microsoft Authentication Library (MSAL) v2.0

As you’ve probably already figured out, the reason that the platform is unrelated to ASP.NET Core Identity is because ASP.NET Core Identity has no support for the Identity protocols. This support is what IdentityServer provides.

Social providers

I didn’t mention this above because it would just muddy the waters.

Some of the Membership providers also allow you to integrate with social logins e.g. Google, Facebook, Twitter etc.

If you need social provider integration and you have added IdentityServer, rather use IdentityServer to provide this so that all the authentication is in one place and you then get SSO.

Hope this helps.

All good!