ASP.NET Identity is Microsoft’s user management library for ASP.NET. It includes functionality such as password hashing, password validation, user storage, and claims management. It usually also comes with some basic authentication, bringing its own cookies and multi-factor authentication to the party. In some configurations, it can even bring its own UI.
If you are using ASP.NET 4.x, you can use the ASP.NET Identity 2 library; otherwise, for ASP.NET Core, you can use ASP.NET Core Identity (sometimes historically known as ASP.NET Identity 3).
To learn more about ASP.NET Identity, I recommend checking out the following resources:
Modern HTML attributes such as “passwordrules” and “autocomplete” allow you to tell password generators where your set password fields are and how they should generate passwords.
While password complexity rules are not the best approach for security, ASP.NET Core Identity does use them by default. This includes requirements for uppercase and special characters.
In this article, you will learn how you can automatically implement the “perfect” set password field using your existing ASP.NET Identity password policy and a tag helper found in “ScottBrady.IdentityModel”.
ASP.NET Core Identity & password policies
ASP.NET Core Identity comes preconfigured to require uppercase, lowercase, digits, and non-alphanumeric characters, which can conflict with some password generators or the user’s particular password generation settings. If you are enforcing password rules server-side, then it is my opinion that they should be communicated client-side before the user submits an invalid one.
In that strange period between Christmas and New Years, I finally had a chance to finish off some long-running dev tasks for IdentityManager2. This means that IdentityManager2 now targets ASP.NET Core 3.1, has dropped the beta suffix, and is now contains less legacy code from v1.
It would be wrong not to thank ChaosEngine who’s pull requests and gentle nudging helped make this release happen.
IdentityManager is an open source project that offers a modern alternative to the ASP.NET WebSite Administration tool that used to come bundled with Visual Studio. IdentityManager offered a simple user interface that allowed developers to bootstrap a new user store with users and role data and saw considerable popularity despite never being intended for production. IdentityManager was designed for ASP.NET & OWIN, supporting ASP.NET Identity 2 and Membership Reboot, which brings us to the topic of this article.
Introducing IdentityManager II
And that’s not the usual hyped up title. I'm running this project; therefore I get to introduce/announce it and use a silly font on my website.
If you want to sign in to Medium using an email address instead of a social media account, you are met with the following screen:
You'll then be sent an email that looks something like this:
The default password hasher for ASP.NET Core Identity uses PBKDF2 for password hashing. While PBKDF2 is not the worst choice, there are certainly better password hashing algorithms available to you, such as bcrypt, scrypt, and Argon2.
In this article, you’re going to see how password hashing works in ASP.NET Core Identity, how to write your own, and how you can take advantage of newer algorithms such as bcrypt and Argon2 by using some IPasswordHasher implementations available on nuget.
Looking for alternative ASP.NET Core Identity password hashers? Check out my new post Better Password Hashing in ASP.NET Core for password hashers using bcrypt, scrypt, and Argon2.
Default Password Hasher
The default password hasher that comes out of the box with ASP.NET Identity 2 ticks all the right boxes:
- It actually uses a hashing algorithm (for some reason this is still something we need to congratulate in 2017)
- It generates a per user salt
- It iteratively hashes a password (not just once like in vanilla ASP.NET Membership)
- It uses a derived key
The above can pretty much be summed up with "it uses PBKDF2", but that that didn’t read as nice.
Looking for an identity bootstrapping tool for ASP.NET Core? Check out Getting Started with IdentityManager2 for ASP.NET Core Identity and IdentityServer4 support.
Identity Manager (formerly Thinktecture Identity Manager) is the spiritual successor to the ASP.NET Web Site Administration Tool that used to be available with Visual Studio, providing a simple UI for performing CRUD operations to manage your user store.
IdentityManager is a tool for developers and/or administrators to manage the identity information for users of their applications. This includes creating users, editing user information (passwords, email, claims, etc.) and deleting users. It provides a modern replacement for the ASP.NET WebSite Administration tool that used to be built into Visual Studio. - https://github.com/IdentityManager/IdentityManager
Created by Brock Allen of Identity Server and Identity Model fame, Identity Manager uses a RESTful API that abstracts the underlying Identity database, exposing metadata and functionality that powers a browser-based UI or used programmatically within your software.
Multitenancy is when multiple applications share an environment. In our scenario this environment is the identity management library ASP.NET Identity v2.2 where we want to allow multiple organisations to store two different users with the same username in a single database.
Out of the box ASP.NET does not allow for multitenancy. With the ASP.NET Identity default behaviour, all organisations would share a single user in the database, they cannot create one each. This is a problem when the organisations are separate entities with no knowledge of each other and should not be sharing data. For example if a user updates their password within x.com, this will also change their password in y.com. Not good.
Some people recommend the work around of prepending usernames with an identifier for each tenant, however there is a way to extend ASP.NET identity to make it truly multitenanted.
Extending from the default Core and Entity Framework packages of ASP.NET Identity we can add a new claim for the concept of Tenant Id. With a bit of work we can use this claim to allow for duplicate usernames within a single ASP.NET Identity database.