0

What is the best way to store your user information per client? I have several applications which all use the same IdentityServer instance for authenticating. ASP.NET Identity shows how to extend a user by inheriting from IdentityUser.

public class CustomUser : IdentityUser
{
   public Int32 CompanyId { get; set; }
}

However, I have applications that have mutually exclusive user information(eg. other applications don't need CompanyId and have properties the the CustomUser's application doesn't need.).

One way would just to create a single type containing all the properties for both. There could be a problem when a property overlaps where both applications need CompanyIds for different companies, not to mention that every column would always be queried every time a lookup was done, so this doesn't seem right. The other option is that I could just create a UserData table in the client applications and query from there as needed which is probably what I have to do since I don't think there is a better option.

If anyone knows a better way let me know.

If would be perfect if UserManager allowed for registration with multiple custom user types and you could get different subsets of data based your choice while each query was optimized for only the data it needed. Then you could put an SQL index per type and maybe even user TPH in entity framework to organize the information.

jwize
  • 4,230
  • 1
  • 33
  • 51
  • Take a look at my answer here for some thoughts: https://stackoverflow.com/questions/52079466/is-claims-based-authorization-appropriate-for-individual-resources/52100609#52100609 –  Jun 19 '19 at 20:01
  • Possible duplicate of [IdentityServer4: different user types in different tables in database](https://stackoverflow.com/questions/54999335/identityserver4-different-user-types-in-different-tables-in-database) –  Jun 19 '19 at 20:43
  • The thing that came up was how am I going to deal with duplicate roles per application and I found this link (https://stackoverflow.com/questions/41800273/duplicate-role-names-on-asp-net-identity-and-multi-tenancy) that looks like it might be a good solution for role. I have to think about claims as well. I have a separate permissions solution that works per application and role. – jwize Jun 19 '19 at 20:44

1 Answers1

0

Unless diving too deep into too app-specific stuff, it looks like a normal user profile.
It contains a number of claims describing the user. Let's consider only user specific, not application specific. For instance there are age, country, postal address, gender, whatever. And some apps need only age and country to restrict some content, while the others need postal address or email.
Authorization request can contain a set of claims and scops to fulfill these requirements.
All above is just about user information, not access rules, and all above is already in the protocol.

Regarding more app-specific... why not to store such stuff more close to the apps and link by user id...

d_f
  • 4,599
  • 2
  • 23
  • 34
  • That's fine for most stuff. I don't have a problem with having a profile table that relates the users information. Also, I don't mind storing exhaustive information that is directly connected to identity such as address details to be stored centrally since there is no duplication. For roles however, and perhaps claims AspNet Identity manages these so I am thinking maybe a custom implementation for the needs such as roles per application to be managed centrally. An example is where one user might be and admin on one app but not the other. – jwize Jun 21 '19 at 21:28
  • admin is a role in a company, so it's not so authentication-related. i just explained what directly comes from the protocol spec. MS often brings all in one in their basic templates. sometimes it's ugly, sometimes ok. imho MS identity scheme + some relation to a tenant could work well enough. but you originally mentioned you need different scopes/claims sets for different *clients*, not *tenants* -- that's why I recalled you can request each time the only you need, so finally... you can combine these two approaches – d_f Jun 21 '19 at 22:08