Last post Apr 16, 2018 01:54 AM by Brando ZWZ
Apr 02, 2018 03:42 PM|zhulien|LINK
Hey! I've researched quite a bit what's the exact purpose of the UserClaims table in Identity but I'm still not quite sure. Can you please give me some more information except 'it is used for claims authentication'. I'm building an API which is using custom
identity tables and I want to incorporate JWT tokens. I'm confused if I should implement the Claims part of identity in this scenario. Does JWT middleware use the claims table in any way or is it fully independent. Isn't the JWT payload just evaluated on the
server and extracted as to get the information we need? Is there any scenario where we need to actually store some form of claims in the database?
Apr 04, 2018 06:15 AM|Brando ZWZ|LINK
Hey! I've researched quite a bit what's the exact purpose of the UserClaims table in Identity but I'm still not quite sure. Can you please give me some more information except 'it is used for claims authentication'.
As far as I know, claim is a piece of identity information such as name, e-mail address, age, membership in the Sales role.
The more claims your application receives, the more you’ll know about your user.
You may be wondering why these are called “claims,” rather than “attributes,” as is commonly used in describing enterprise directories.
The reason has to do with the delivery method.
In this model, your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust
For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user herself. WIF represents claims with a Claim type, which has an Issuer property that allows you to find out who issued the claim.
So the UserClaims is used to store other claims information for user and generate the token according to the claims.
Does JWT middleware use the claims table in any way or is it fully independent. Isn't the JWT payload just evaluated on the server and extracted as to get the information we need?
If you use identity to add user claims, it will auto generate the token according to the user claim.
More details about how to add claims in asp.net core, you could refer to below answer.
Is there any scenario where we need to actually store some form of claims in the database?
Normally, we will add some external information about the user in the claims.
Bank Card number of the user.
Apr 05, 2018 09:13 AM|zhulien|LINK
Thanks for the input but I just got more confused now. Why do we store the claims at all? The issuing authority creates a payload which contains user claims. The client sends this token to the server and the server just use this information to do further
processing. Why do we store the claims in the server at all? I see only one viable case for this and it is when we store/have absolutely no information about the users(in the sense of user accounts) and everything is coming from an authentication service who
is doing all of the user auth/info storage and we just store the claims because this is all the information we have for a given user.
Apr 16, 2018 01:54 AM|Brando ZWZ|LINK
In my opinion, claim-Based access control allows better separation of authorization rules from the core business logic. When authorization rules change, the core business logic remain unaffected. There will be situations where you might prefer using Claim-Based
According to this
Sometimes claims aren't needed. This is an important disclaimer. Companies with a host of internal applications can use Integrated Windows Authentication to achieve many of the benefits provided by claims. Active Directory does
a great job of storing user identities, and because Kerberos is a part of Windows, your applications don't have to include much authentication logic. As long as every application you build can use Integrated Windows Authentication, you may have already reached
your identity utopia. However, there are many reasons why you might need something other than Windows authentication. You might have web-facing applications that are used by people who don't have accounts in your Windows domain. Another reason might be that
your company has merged with another company and you're having trouble authenticating across two Windows forests that don't (and may never) have a trust relationship. Perhaps you want to share identities with another company that has non-.NET Framework applications
or you need to share identities between applications running on different platforms (for example, the Macintosh). These are just a few situations in which claims-based identity can be the right choice for you.