问ASP .NET标识中的声明是什么

EN

在新的ASP.NET身份核心中，声明机制意味着什么？

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

基于角色的安全

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

基于声明的安全

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

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

1. 用户请求操作。信赖方( RP )应用程序请求令牌。
2. 用户向RP应用程序信任的颁发机构提供凭据。
3. 颁发机构颁发带有声明的签名令牌，在对用户的RP用户进行身份验证后将令牌提供给RP应用程序。应用程序验证令牌签名，提取声明，并根据声明接受或拒绝请求。

但是，我仍然不能理解和找到任何信息，什么时候数据添加到AspNetUserClaims，这个表用于什么情况？

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

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

更新

我必须在什么时候使用基于角色的安全性，什么时候使用基于声明的安全性？你能写几个例子吗？

没有一个非常明确的情况，你会或不会使用基于角色或基于声明的安全性，不像你会使用A而不是B的情况。

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

声明有时是不需要的。这是一个重要的免责声明。拥有大量内部应用程序的公司可以使用集成的Windows身份验证来实现claims提供的许多好处。Active Directory在存储用户标识方面做得很好，而且因为Kerberos是Windows的一部分，所以您的应用程序不必包含太多的身份验证逻辑。只要您构建的每个应用程序都可以使用集成的Windows身份验证，您就可能已经到达了您的身份乌托邦。但是，您可能需要Windows身份验证之外的其他身份验证的原因有很多。您可能有面向web的应用程序，这些应用程序由在您的Windows域中没有帐户的用户使用。另一个原因可能是，您的公司已经与另一家公司合并，而您在跨两个没有(也可能永远不会)具有信任关系的Windows林进行身份验证时遇到问题。您可能希望与另一家拥有非.NET Framework应用程序的公司共享标识，或者需要在运行于不同平台(例如，Macintosh)上的应用程序之间共享标识。在这些情况下，基于声明的身份可能是您的正确选择。

如需更多信息，请访问网址：http://msdn.microsoft.com/en-us/library/ff359101.aspx。

只是想补充更多@Lin上面所说的。我特别指的是这个问题：

我必须在什么时候使用基于角色的安全性，什么时候使用基于声明的安全性？你能写几个例子吗？

我不得不在这个答案中添加更多信息，这是因为我没有明确解决基于声明的身份验证模型和基于角色的身份验证模型之间的分离问题。从经验和概念本身的性质以及在Microsoft Docs上呈现和记录的角度来看，这两个授权模型经常一起使用，下面的示例3说明了它们经常一起使用的示例。现在让我们详细讨论一下这些主题：

基于声明的授权：

需要注意的重要一点是，与基于角色的授权相比，基于声明的授权本质上是第三方绑定的。声明是由描述用户的第三方应用程序提供给您(您的应用程序)的信息。此信息可以是任何类型的数据。让我们举个例子：

示例1：

假设你有一个用来混合歌曲的软件应用程序。这个应用程序基本上使用了来自Spotify或YouTube音乐平台等的歌曲，但它的构建方式使得它可以完全访问这些平台的音乐库。但这款应用不需要你用你的Spotify或google账户登录，基本上你只需要用电子邮件和密码注册即可。但在你上网后，如果要使用来自Spotify或YoutTube音乐的音乐，系统会要求你输入一个你用来创建你的sportify或YouTube音乐账户的电子邮件地址。然后，应用程序(通过web服务)从相应的第三方应用程序请求您的订阅账号，并将其存储为声明。所以，每次你尝试在线访问音乐时，应用程序都会使用注册声明的策略来检查你是否有订阅帐户，然后允许访问。关于这一点的好处是，索赔与信息一起存储，例如您存储索赔来自何处的Issuer。就是这样。您使用了由第三方提供的索赔subscriotionAccountNumber，它描述了您站在他们这一方。显然，这不是最好的模型-关于这种应用程序，但它作为一个例子已经足够好了。您正在根据另一个第三方应用程序声明的有关用户的一些信息来授权您的用户。

基于角色的授权：

这里的这个已经足够清楚了。在最简单的情况下，您仅根据用户的角色和角色授予用户访问权限。

示例2：

想象一下，一个组织应用程序有来自不同位置的多个用户。您可以根据用户的职位为其分配角色，并根据其角色授予对不同信息的访问权限。经理、所有者、员工…基本上，并非所有员工都有权访问经理和所有者可以访问的所有内容。这也适用于管理者和所有者。经理没有权限访问某些仅属于所有者的信息。就这么简单。

将所有这些放在一起的：

在像ERP系统这样的应用程序中，声明和角色一起使用来构建复杂的授权模型。我总是说，当前的Identity Framework是如此完整，以至于你通常不需要不必要的扩展来破坏现有的模型，显然需求可能不同，有时拆分模型可能是唯一的选择。当角色和声明一起使用时，声明充当权限。这就是为什么在模型中有RoleClaim和UserClaim表的原因。也就是说，您可以将授权扩展到角色本身之外。当声明与角色一起使用时，它们仅提供执行某些操作的访问权限。

示例3：

假设您有一个时钟系统，其中有一名技术人员和一名经理。在每周结束时，技术人员必须安排报告，并提供计时信息，显示工匠在该周工作的小时数，这些小时数由工资单合并使用。这样的系统通常必须在提交最终报告之前进行修改或更正，因为你不想给员工过高或过低的薪酬。您可以通过创建Manager Role和Technician Role对经理和技术人员使用Role-Based方法。但是Manager Role具有访问和编辑工匠的时钟信息的能力。另一方面，您可以使用没有这些功能的Technician Role来访问该信息。但这里有一个有趣的部分:经理可以提出要求，并允许技术人员访问时钟系统并生成报告。因此，声明只能用于访问而不能编辑，或者可以使用访问和编辑功能进行声明。请记住，只有您的应用程序才能理解您的声明的含义。它们可以被命名为任何名称，GrantWriteAccess，GrantReadAccess等等，没有什么能限制你。将声明预定义为权限后，您需要做的就是将该声明与用户相关联。在这种情况下，技术人员会将GrantWriteAccess和GrantReadAccess添加到他们的UserClaim表中。

这更像是在说，默认情况下，作为经理，我可以访问一些我的技术人员无法访问的信息。但我不是一直在办公室吗？我怎么做才能让他在我不在的时候还能做这件事呢？为了解决这个问题，系统可以让管理员为不能访问某些特定信息的人员创建声明(权限)。我们经常在我们的ERP系统中看到这些。没有访问某些模块的权限的用户，当他们得到提升时，他们会被授予对ERP系统的更多模块的权限，有时会保留相同的用户角色，并且只有一些权限是打开的。

在ASP.Net身份中有两种类型的身份验证。

1. Role based
2. Claim based

您可以同时使用其中的一个或两个。当你有非常明确的东西时，使用基于角色的。例如，您创建了教师和学生两个角色。只有教师才能添加科目。因此，您将教师角色分配给了您希望其有权添加科目的用户。

基于声明的方法更加灵活。假设你有一个要求，一些学生也可以添加科目。在这种情况下，您必须再创建一个角色，该角色可以是学生，并且可以访问以添加主题。但是如果你使用的是基于声明的方法，那就非常简单了。只需创建类似addSubject的声明，并将其分配给您想要访问以添加自动对象的任何用户。