13

I'm truly lost in trying to understand ASP.NET Identity 2.1.0 right now, and need to go back over the basics, in order to better understand how the cookies and claims work.

A basic query is around my not being sure I understand why a User needs properties as well as Claims: isn't a Claim just a key+value+authority, and therefore could have been used for storing the Properties(a key+value)? * What's the benefit of keeping two sets of properties (other than Typed get/sets on the Properties)? Is one intended to be more transient than the other? * Is it only to distinguish between what gets serialized and round tripped in the Cookie (only the claims, right?)? * Talking about that...just checking: it is all Claims that are round tripped by being serialized in the cookie, or is it only a subset of them (such as ClaimTypes.Roles)?

Thanks for the help!

stacker
  • 183
  • 11

1 Answers1

11

All claims on user are serialised into cookie. Not all ApplicationUser properties are serialised as claims. In fact, most of properties are not serialised into claims (unless specifically coded for).

You confusing 2 concepts: Claims are part of ClaimsPrincipal : IPrincipal that is available on every HTTP request (if user is authenticated). ClaimsPrincipal is created from ApplicationUser when user is signed in and serialised into cookie.

ApplicationUser model is a way to persist user information into database and additional properties are just additional fields for user table in your DB. You can code to have these properties become available in your cookie through adding claims, but they don't become claims automatically for you.

Adding extra information can be achieved through adding a claim or through additional property in ApplicationUser table. You are in control how to add the data. But bear in mind that these can serve different purposes. If you add a property on ApplicationUser, you are saying that all users should have something for that. If you add a claim with the same data, you are saying that this user has some data that other users may not have.

To answer your last question: all claims are serialised and round-tripped in the cookie. So don't put too much information into the cookie - these can add up and you'll be round-tripping too much data.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • Thanks for stating that all claims are round-tripped...affecting size. Thanks for explaining the nuance that Claims can be unique to a user, eg: a fact specific to the SSO used , whereas the ApplicationUser's schema is the same for all users. Also think I now understand that one can immediately use Principal for Claims (therefore Roles) -- and for *more* (eg: ShoeSize/Gender/etc), one has to fish up the User from the Db, via the UserManager. But what's the advantage to roundtrip a prop in a cookie, when 2 seconds later, I'll hit the db for the User anyway (some db Join for something else)? – stacker Oct 14 '14 at 10:46
  • What I was trying to question is: I know hitting a db is slower than memory -- but isn't a cookie containing roles, sent back with every GET for every image, css, html, js, required going to be maybe worse performance? Or is it a just a matter of trust -- that MS has done their research, and it does turn out that 15+ internet requests (for an MVC page) with somewhat long (encrypted) cookie values is still faster than a user object coming across an intranet connection. Thx. But I guess that really should be another question ;-) – stacker Oct 14 '14 at 10:54
  • To answer your first question: data you put in your claims/cookie is something that is easily available to you without hitting the DB. And if you have a heavy-used system, this can save a lot of db-calls on every request. So choose wisely what you want to put into your cookie. In our application I have saved 3 extra calls to DB on every request just by putting user data into cookie. – trailmax Oct 14 '14 at 10:59
  • For the second question, if your cookie is that large - yes, there is a problem. But my observation show that every byte you put into claims, increase your cookie size by 1.1 times. So adding person name will cost you almost nothing in the cookie (20-30 extra bytes) but will save you a db-call on every request. And if you are in cloud, your db-calls can be expensive due to network latency. – trailmax Oct 14 '14 at 11:01
  • And for the static objects like JS and CSS, you should put them in a separate domain where you don't set cookie for. – trailmax Oct 14 '14 at 11:02
  • 1
    And remember, premature optimisation is a mother of all evil. Do your profiling first, then optimise the bottlenecks. – trailmax Oct 14 '14 at 11:02
  • Thanks. Totally understand that using a Cookie-less domain for JS/CSS/Images is the optimal solution. Although admit never done it (not enough traffic ;-( ) But got the point :-) – stacker Oct 14 '14 at 21:43