27 January 2020
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.
09 July 2018
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 bring us to the topic of this article.
And that’s not the usual hyped up title...
06 March 2018
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...
30 October 2017
The default password hasher for ASP.NET Core Identity uses PBKDF2 for password hashing. Whilst this is a decent enough implementation, there are certainly more desirable password hashing algorithms out there. So that’s exactly what I’ve addressed, with three new password hasher implementations for ASP.NET Core Identity using bcrypt, scrypt, and Argon2.
Default (PBKDF2) Password Hasher
To be precise, the ASP.NET Core Identity uses PBKDF2 with HMAC-SHA256, a 128-bit salt, a 256-bit subkey, and (by default) 10,000 iterations. Luckily this iteration count is now configurable (unlike ASP.NET Identity 2), and realistically you’ll be looking at adding another zero to that iteration count. 10,000 iterations is so 2012.
PBKDF2 is generally considered “good-enough”, assuming...
06 March 2017
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.
Great, so that’s pretty good for an out of the box password hasher from 2014. But for some reason the password hasher contains the following line of code:
08 April 2016
Last Updated: 25 July 2018
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...
08 August 2015
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.