有人可以解释一下，声明机制在新的身份核心 ASP.NET 意味着什么吗？
如我所见，有一个AspNetUserLogins表，其中包含UserId、LoginProvider和ProviderKey。
但是，我仍然无法理解或找到有关何时将数据添加到AspNetUserClaims表以及此表用于什么情况的任何信息？
机制在新 ASP.NET 身份核心中是什么意思？
有两种基于角色和声明的常见授权方法。
基于角色的安全性
用户被分配到一个或多个角色，用户通过这些角色获得访问权限。 此外，通过将用户分配给角色，用户可以立即获得为该角色定义的所有访问权限。
基于声明的安全性
基于声明的标识是一组声明。声明是实体(用户或其他应用程序)所做的声明 本身，这只是一个主张。例如，声明列表可以包含用户名、用户的电子邮件、用户的年龄、用户对操作的授权。 在基于角色的安全性中，用户直接向应用程序提供凭据。 在基于声明的 模型，则用户向应用程序提供声明而不是凭据。对于具有实用性的索赔 值，它必须来自应用程序信任的实体。
以下步骤说明了在基于声明的安全模型中发生的顺序：
- 用户请求操作。信赖方 (RP) 应用程序询问 为令牌。
- 用户向 RP 应用程序信任的颁发机构提供凭据。
- 颁发机构在对用户的 凭据。
- 用户向 RP 应用程序提供令牌。应用程序验证令牌 签名，提取声明，并根据声明接受或拒绝 请求。
但是，我仍然无法理解和找到任何信息，当数据 添加到 AspNetUserClaims 以及此表用于什么情况？
当您处于不使用基于角色的安全性，并且选择使用基于声明的安全性时 安全性，您需要使用AspNetUserClaims表。 有关如何在 ASP.NET 标识中使用声明，请参阅以下链接以获取详细信息。
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
更新
我什么时候必须使用基于角色的安全性，何时必须使用基于声明的安全性？ 你能举几个例子吗？
没有一个非常明确的情况，即您将或不会使用基于角色或基于声明的安全性，而不是像您使用 A 而不是 B 的情况那样。
但是，基于声明的访问控制允许更好地将授权规则与核心业务逻辑分离。当授权规则更改时，核心业务逻辑不受影响。在某些情况下，您可能更喜欢使用基于声明的方法。
有时不需要声明。这是一个重要的免责声明。 拥有大量内部应用程序的公司可以使用集成 Windows 身份验证可实现 提供的许多好处 索赔。Active Directory在存储用户身份方面做得很好， 而且因为 Kerberos 是 Windows 的一部分，所以你的应用程序不会 必须包含许多身份验证逻辑。只要每个 您构建的应用程序可以使用集成 Windows 身份验证，您 可能已经达到了你的身份乌托邦。但是，有很多 您可能需要Windows以外的其他内容的原因 认证。您可能使用了面向 Web 的应用程序 由在您的 Windows 域中没有帐户的人员提供。另一个 原因可能是您的公司已与另一家公司合并，并且 您在跨两个 Windows 林进行身份验证时遇到问题 不要(也可能永远不会)建立信任关系。也许你想 与具有 non-.NET 框架的另一家公司共享身份 应用程序或需要在应用程序之间共享标识 在不同的平台上运行(例如，Macintosh)。这些是 只是基于声明的标识可能是正确的几种情况 为您选择。
欲了解更多信息，请访问 http://msdn.microsoft.com/en-us/library/ff359101.aspx
只是为了补充更多关于@Lin上面所说的内容。我具体指的是这个问题：
我什么时候必须使用基于角色的安全性，何时必须使用基于声明的安全性？ 你能举几个例子吗？
我不得不向这个答案添加更多信息，这是因为我没有清楚地解决基于声明和基于角色的身份验证模型之间的区别。根据经验和概念本身的性质以及Microsoft文档中的呈现和记录，这两个授权模型通常一起使用，下面的示例 3 说明了它们何时经常一起使用的示例。现在让我们详细讨论这些主题：
基于声明的授权：
需要注意的重要一点是，与基于角色的授权相比，基于声明的授权本质上是第三方绑定的。声明是由描述用户的第三方应用程序提供给你(你的应用)的信息片段。此信息可以是任何类型的数据。让我们举个例子：
示例 1：
想象一下，您有一个用于混合歌曲的软件应用程序。这个应用程序基本上使用来自Spotify或YouTube音乐平台等的歌曲，但它的构建方式使其可以完全访问该平台的音乐库。但是这个应用程序不需要你登录你的 Spotify 或谷歌帐户，你基本上只需使用电子邮件和密码注册。但是，在您在线后，要使用Spotify或YoutTube音乐中的音乐，系统会要求您输入用于创建sportify或YouTube音乐帐户的电子邮件地址。然后，应用程序(通过 Web 服务)从相应的第三方应用程序请求您的订阅帐号，并将其存储为声明。因此，每次您尝试在在线时访问音乐时，该应用程序都会使用注册声明的策略来检查您是否拥有订阅帐户，然后允许访问。这样做的好处是，声明与信息一起存储，例如存储声明来源的颁发者。 仅此而已。您使用了由第三方提供的声明 subscriotionAccountNumber，该声明描述了您站在他们这边。显然，这不是使用此类应用程序的最佳模型，但作为示例已经足够好了。您是根据从其他第三方应用程序声明的有关用户的某些信息来授权用户的。
基于角色的授权：
这里的这一点已经足够清楚了。简单来说，您可以根据用户的角色和角色向用户授予访问权限。
示例 2：
假设一个组织应用包含来自不同职位的多个用户。您可以根据用户的位置为其分配角色，并根据其角色授予对不同信息的访问权限。经理、业主、员工...基本上，并非所有员工都可以访问经理和所有者可以访问的所有内容。这适用于经理和所有者。管理员无权访问某些仅属于所有者的信息。就是这么简单。
把所有的东西放在一起：
在 ERP 系统等应用程序中，声明和角色一起使用以构建复杂的授权模型。我总是会说，当前的标识框架是如此完整，以至于通常您不需要破坏现有模型的不必要的扩展，显然需求可能会有所不同，有时分解模型可能是唯一的选择。当角色和声明一起使用时，声明充当权限。这就是模型中具有RoleClaim表和UserClaim表的原因。这是为了允许您将授权扩展到角色本身之外。 当声明与角色一起使用时，它们仅提供执行某些操作的访问权限。
例3：
考虑一个案例，您有一个时钟系统，其中有技术人员和经理。在每个星期结束时，技术人员必须安排带有计时信息的报告，显示工匠当周的工作时间，这些信息由工资单合并和使用。在提交最终报告之前，通常必须修改或纠正此类系统，因为您不想多付或少付员工工资。您可以通过创建Manager Role和Technician Role来对经理和技术人员使用Role-Based方法。但Manager Role是能够访问和编辑工匠时钟信息的人。另一方面，您可以拥有没有这些能力的Technician Role来访问该信息。但这是有趣的部分;经理可以提出索赔，并允许技术人员访问时钟系统并进行报告。因此，只能对访问权限提出声明，而不进行编辑，也可以使用访问和编辑功能提出声明。请记住，只有您的应用才能理解您的声明的含义。它们可以被命名为任何东西，GrantWriteAccess，GrantReadAccess等，没有什么限制你。将声明预定义为权限后，只需将该声明与用户关联即可。在这种情况下，技术人员会将GrantWriteAccess和GrantReadAccess添加到其UserClaim表中。
这更像是说，默认情况下，作为经理，我可以访问一些我的技术人员无法访问的信息。但我不是总是在办公室里吗？我能做些什么，即使我不在身边，他仍然可以做这项工作？为了解决这个问题，系统可以具有经理为无法访问某些特定信息的人创建声明(权限)的功能。我们经常在我们的ERP系统中随处可见这些。无权访问某些模块的用户，当他们获得晋升时，他们被授予访问 ERP 系统的更多模块的权限，有时保持相同的用户角色，并且只打开某些权限。
以下是 ASP.NET 文档中的一个非常简单的解释：
创建标识时，可以为其分配一个或多个由受信任方颁发的声明。声明是一个名称值对，它表示主题是什么，而不是主题可以做什么。例如，您可能拥有由当地驾驶执照机构颁发的驾驶执照。您的驾驶执照上有您的出生日期。在这种情况下，索赔名称将是出生日期，索赔价值将是您的出生日期，例如 1970 年 6 月 8 日，签发人将是驾驶执照颁发机构。最简单的基于声明的授权检查声明的值，并允许基于该值访问资源。
然后，它继续举一个我们几乎所有人都能理解的例子：
例如，如果您想进入夜总会，授权过程可能是： 门安全人员将在授予您访问权限之前评估您的出生日期索赔的价值以及他们是否信任发行人(驾驶执照机构)。
因此，要回答何时应该使用基于声明的安全性？，答案是何时将人员置于明确定义的角色中并不容易。例如，在夜总会方案中，很难将客户置于角色中，因此你使用基于声明的访问控制，该年龄由其 ID 确认(例如驾驶执照)。但是，在同一夜总会场景中，您可以使用基于角色的安全性来控制谁有权访问哪些房间(例如，对"仅限员工"的房间使用钥匙卡)。显然，您可以根据需要混合使用基于声明和基于角色的安全性。
ASP.Net 身份中有两种类型的身份验证。
- 基于角色
- 基于索赔
您可以同时使用其中之一或同时使用两者。当您有非常明确的事情时，请使用基于角色的内容。例如，您创建了教师和学生两个角色。只有教师可以添加科目。因此，您将教师角色分配给了您希望有权添加科目的用户。
基于声明更灵活。假设您有一个要求，一些学生也可以添加科目。在这种情况下，您必须再创建一个角色，该角色可以是学生并有权添加主题。但是，如果您使用基于声明的声明，那将非常容易。只需创建像 addSubject 这样的声明，并将其分配给您想要访问的任何用户即可添加 aubject。