Can somebody please explain, what the claim mechanism means in new ASP.NET Identity Core?
As I can see, there is an AspNetUserLogins table, which contains UserId, LoginProvider and ProviderKey.
But, I still can't understand or find any information on when data is added to the AspNetUserClaims table and what situations this table is used for?
what does claim mechanism means in new ASP.NET Identity Core?
There are two common authorization approaches that are based on Role and Claim.
Role-Based Security
A user gets assigned to one or more roles through which the user gets access rights. Also, by assigning a user to a role, the user immediately gets all the access rights defined for that role.
Claims-Based Security
A claims-based identity is the set of claims. A claim is a statement that an entity (a user or another application) makes about itself, it's just a claim. For example a claim list can have the user’s name, user’s e-mail, user’s age, user's authorization for an action. In role-based Security, a user presents the credentials directly to the application. In a claims-based model, the user presents the claims and not the credentials to the application. For a claim to have practical value, it must come from an entity the application trusts.
Below steps illustrate the sequence of that happens in a claims-based security model:
But, i still can't understand and find any information, when data addes to AspNetUserClaims and what situations this table using for?
When you are in a situation where a Role-Based Security is not used, and you chose to use Claim-Based Security, you would need to utilize AspNetUserClaims table. For how to use Claims in ASP.NET Identity, see below link for more information.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Update
What time i have to use role-based security and when claim-based? Could you please write a few examples?
There isn't a very clear situation where you would or would not use Role-Based or Claim-Based Security, Not like a case where you would use A rather than B.
But, 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 approach.
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.
For more information, please visit http://msdn.microsoft.com/en-us/library/ff359101.aspx
