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:
- The user requests an action. The relying party (RP) application asks
for a token. - The user presents the credentials to the issuing authority that the RP application trusts.
- The issuing authority issues a signed token with claims, after authenticating the user’s
credentials. - The user presents the token to the RP application. The application validates the token
signature, extracts the claims, and based on the claims, either accepts or denies the
request.
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