4

I'm trying to build a SPA web app + IdentityServer4 + ASPNET Core + ASPNET Core Identity. I've followed the quickstarts on the Identityserver documentation and its really great. I'm more interested the quickstart Identity Server Quickstart with JS Client

I've followed it and so far so good. Now I've added some fields and related tables to my User, like so:

app_user

This is the Solution Explorer

solution_explorer

I would like to create a page that displays my user and its related tables/fields. (Basically, my question is, how do I access my current user and expose an API for my JS client to consume)

How do I achieve that? (All described points below I just read it online and I'm not sure how to implement it)

  • Should I store my user in a session? Then access it from there?
  • Should I use the connect/userinfo endpoint?

Please advise.

Boy Pasmo
  • 8,021
  • 13
  • 42
  • 67
  • does this help? http://stackoverflow.com/questions/39174121/get-property-of-applicationuser-from-the-asp-net-core-identity/39174256#39174256 – Mike_G Oct 19 '16 at 15:51
  • Thanks. Will give this a try. When using usermgr, will it go make calls to db every request? Or just once? – Boy Pasmo Oct 19 '16 at 16:17
  • yes, it will get go to the db every request. If you are performing the same query multiple times within the same request it hits it once, then pulls subsequent calls from cache. (That also depends on the lifetime you have setup for in your dependency injection of the db context, but by default its setup for 'Scoped', or per request) – Mike_G Oct 19 '16 at 17:40

1 Answers1

7

The idea of IdentityServer is to separate concept of User Identity. In simple words, it means that your web API shouldn't/wouldn't have access to the database where users are stored.

Everything related to the user identity that is nessaccary in web API should be included in access token granted by IdentityServer. ( For example in claims)

In your example you can remove Points and Wallets fields from ApplicaionUser and create addition table for storing them, like this:

public class UserInfo
{
    public string UserSubject { get; set; }
    public int Points { get; set; }
    public ICollection<Wallet> Wallets { get; set; }
}

If you need something related to User Identity you can get it from claims like this:

[Authorize]
public ActionResult SomeAction()
{
    var identity = (ClaimsIdentity)User.Identity;
    IEnumerable<Claim> claims = identity.Claims;
    ...
}

If you need Points and/or Wallets of a user, you can get sub claim from these claims and query your database for it.

It also means that you need to store Points and Wallets by user subject.

bot_insane
  • 2,545
  • 18
  • 40
  • By `where users are stored`, does that mean, Users and Operational should be stored separately? Separate database? Oh, I see. So if I need additional data from a user like `Points` or `Wallets` (that doesn't have to do with user identity), I just use the `sub` claim and query the related record. Right? – Boy Pasmo Oct 23 '16 at 15:26
  • @BoyPasmo yes, absolutely. – bot_insane Oct 23 '16 at 21:49
  • 1
    doesnt matter if it shoulda/woulda - app logic must have access to user identity. this is why identity server exists. not the other way around – Boppity Bop Dec 05 '20 at 19:58