asp.net - ASP .NET Identity 中的声明是什么

Question

有人可以解释一下，声明机制在新的 ASP.NET Identity Core 中意味着什么吗？

正如我所看到的，有一个 AspNetUserLogins 表，其中包含 UserId、LoginProvider 和 ProviderKey。

但是，我仍然无法理解或找不到任何有关数据何时添加到 AspNetUserClaims 表以及该表用于什么情况的信息？

Answer 1

what does claim mechanism means in new ASP.NET Identity Core?

有两种常见的授权方法，分别是基于角色和声明。

基于角色的安全

用户被分配一个或多个角色，通过这些角色用户可以获得访问权限。此外，通过将用户分配给角色，用户可以立即获得为该角色定义的所有访问权限。

基于声明的安全

基于声明的身份是一组声明。声明是实体(用户或另一个应用程序)做出的声明其本身，只是一种主张。例如，声明列表可以包含用户的姓名、用户的电子邮件、用户的年龄、用户对某项操作的授权。在基于角色的安全性中，用户直接向应用程序提供凭据。在基于 claim 的模型中，用户向应用程序提出声明而不是凭据。对于具有实用性的主张值，它必须来自应用程序信任的实体。

以下步骤说明了基于声明的安全模型中发生的顺序:

1. 用户请求执行操作。依赖方 (RP) 应用程序要求以获得 token 。
2. 用户向 RP 应用程序信任的颁发机构提供凭据。
3. 在验证用户的身份后，颁发机构会颁发带有声明的签名 token 凭据。
4. 用户向 RP 应用程序提供 token 。应用程序验证 token 签名，提取声明，并根据声明接受或拒绝请求。

But, i still can't understand and find any information, when data addes to AspNetUserClaims and what situations this table using for?

当您处于未使用基于角色的安全性的情况，并且您选择使用基于声明的安全性时安全性方面，您需要使用 AspNetUserClaims 表。有关如何在 ASP.NET Identity 中使用声明，请参阅下面的链接以获取更多信息。

http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html

更新

What time i have to use role-based security and when claim-based? Could you please write a few examples?

没有非常明确的情况表明您是否会使用基于角色或基于声明的安全性，这与您会使用 A 而不是 B 的情况不同。

但是，基于声明的访问控制可以更好地将授权规则与核心业务逻辑分开。当授权规则发生变化时，核心业务逻辑不受影响。在某些情况下，您可能更喜欢使用基于声明的方法。

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.

了解更多信息，请访问http://msdn.microsoft.com/en-us/library/ff359101.aspx