search

aspnet / Identity

[Archived] ASP.NET Core Identity is the membership system for building ASP.NET Core web applications, including membership, login, and user data. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
1.97k stars 871 forks source link

Custom Storage for Identity Provider: What if my data source is not a storage layer? #1981

Closed assyadh closed 5 years ago

assyadh commented 5 years ago

Hi,

I was going over the Identity Provider paradigm (Managers, Stores and your custom data layer).

Identity architecture states that Managers are high-level classes which an app developer uses to perform operations, such as creating an Identity user. Stores are lower-level classes that specify how entities, such as users and roles, are persisted.

However, here is a simplified stack trace of a Sign in operation using ASP.NET Identity (gathered by scaffolding the default template):

SignInManager.PasswordSignInAsync(TUser user, string password) UserManager.CheckPasswordAsync(TUser user, string password) UserManager<TUser>.VerifyPasswordAsync(IUserPasswordStore<TUser> store, TUser user, string password) IUserPasswordStore<TUser>.GetPasswordHashAsync(TUser user) VerifyHashedPassword(TUser user, string hash, string password)

As you can see, there is an assumption made by the UserManager, that the UserStore way of verifying a password is by retrieving the hash from the storage layer and comparing it to the password.

To me, it looks like the UserManager is somehow specifying how entities are persisted.

It looks like if I am using a backend store where I don't have access to password hashes, I would have to rewrite my own SigninManager and UserManager, to get away from that hashes comparison paradigm.

Do you have any plans on accommodating storage layers where you don't have access to password hashes such as external user management services hosted in the cloud?

I can come up with a few ideas on how to add an additional layer of abstraction on how password are deemed to be stored.

Thanks!

HaoK commented 5 years ago

I think for those situations you would have a derived UserManager where you override the PasswordSignIn/CheckPassword/VerifyPassword methods to do what you need

assyadh commented 5 years ago

Thanks, this is what I am planning to do.

However I was wondering if there was any plan on not relying to a 'data storage' layer, but rather go even more abstract on how users are managed?

My thinking I guess is that going forward, more and more developers will get rid of the security risk that comes with handling password hashes, and externalize this to other services.

Hamza

blowdart commented 5 years ago

Once you want external services then you might as well move to OIDC, that's what it's there for.