ASP .NET Identity中的声明是什么？

Question

有人可以解释一下,声称机制在新的ASP.NET身份核心中意味着什么？

我所看到的,有一个AspNetUserLogins表,其中包含UserId,LoginProvider和ProviderKey.

但是,我仍然无法理解或找到有关何时将数据添加到AspNetUserClaims表中以及此表用于何种情况的任何信息？

Answer 1

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

有两种基于角色和声明的通用授权方法.

基于角色的安全性

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

基于声明的安全性

基于声明的身份是一组声明.声明是一个实体(用户或其他应用程序)对自己做出的声明,它只是一个声明.例如,声明列表可以包含用户的姓名,用户的电子邮件,用户的年龄,用户对操作的授权.在基于角色的安全性中,用户将凭证直接呈现给应用程序.在基于声明的模型中,用户向应用程序提供声明而非凭据.对于具有实用价值的声明,它必须来自应用程序信任的实体.

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

1. 用户请求操作.依赖方(RP)应用程序请求令牌.
2. 用户将凭证提供给RP应用程序信任的颁发机构.
3. 在验证用户的凭据之后,颁发机构发出带有声明的签名令牌.
4. 用户将令牌呈现给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林中进行身份验证时遇到了问题.您可能希望与另一家拥有非.NET Framework应用程序的公司共享身份,或者您需要在不同平台(例如,Macintosh)上运行的应用程序之间共享身份.这些仅仅是基于声明的身份可能是您的正确选择的几种情况.

有关更多信息,请访问http://msdn.microsoft.com/en-us/library/ff359101.aspx

Answer 2

只是为了补充@Lin上面所说的内容。我专门指的是这个问题：

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

考虑一种情况，如果您有一个拥有技术人员和经理的时钟系统。在每周结束时，技术人员必须安排带有时钟信息的报告，以显示该周工匠的工作时间，这些信息将合并并由工资单使用。在提交最终报告之前，通常必须对此类系统进行修正或更正，因为您不想多付或少付您的员工。您可以Role-Based通过创建Manager Role和来为经理和技术人员使用一种方法Technician Role。但是，这Manager Role是一种能够访问和编辑工匠时钟信息的功能。另一方面，您可以Technician Role没有访问这些信息的能力。但这是有趣的部分；经理可以提出索赔，并允许技术人员访问时钟系统并进行报告。因此，可以仅对未经编辑的访问提出索赔，或者可以使用访问和编辑功能提出索赔。

更像是说，嗯，默认情况下，作为管理员，我可以访问一些我的技术人员无法访问的信息。但是我不总是在办公室里吗？我该怎么办，这样即使我不在身边，他仍然可以继续工作？为了解决这个问题，系统可以具有管理者可以为人们创建索赔的功能，而无需访问某些特定信息。我们经常在我们的ERP系统中到处看到这些。没有访问某些模块的用户，当他们获得晋升时，他们将授予ERP系统的更多模块许可，有时保持相同的用户角色。

您可以考虑使用以下示例来进一步了解声明和角色。

Answer 3

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

1. 基于角色
2. 基于索赔

您可以使用其中之一，也可以同时使用两者。当您有非常明确的事物时，请使用基于角色的方法。例如，您创建了两个角色老师和学生。只有教师可以添加科目。因此，您将教师角色分配给您希望有权添加科目的用户。

基于声明的更灵活。假设您有一个要求，一些学生也可以添加科目。在这种情况下，您必须再创建一个角色，该角色可以是学生并有权添加主题。但是，如果您使用的是基于声明的，那将非常容易。只需创建像 addSubject 这样的声明并将其分配给您想要访问以添加主题的任何用户。

Answer 4

这是来自ASP.NET 文档的一个非常简单的解释：

创建身份时，可以为其分配一个或多个由受信任方发布的声明。声明是一个名称值对，表示主题是什么，而不是主题可以做什么。例如，您可能拥有当地驾驶执照当局颁发的驾驶执照。您的驾照上有您的出生日期。在这种情况下，索赔名称将是 DateOfBirth，索赔值将是您的出生日期，例如 1970 年 6 月 8 日，颁发者将是驾驶执照当局。最简单的基于声明的授权检查声明的值并允许基于该值访问资源。

然后继续举一个我们几乎所有人都能理解的例子：

例如，如果您想进入夜总会，授权过程可能是：门安全员将评估您的出生日期声明的价值以及他们是否信任发行人（驾驶执照当局），然后再授予您访问权限。

那么要回答我什么时候应该使用基于声明的安全性的问题？，答案是当很难让人们扮演明确定义的角色时。例如，在夜总会场景中，很难将客户置于角色中，因此您可以根据他们的 ID（例如驾照）确认的年龄使用基于声明的访问控制。但是，在同一个夜总会场景中，您可以使用基于角色的安全性来控制谁可以访问哪些房间（例如，对“仅限员工”的房间使用钥匙卡）。显然，您可以根据需要混合基于声明和基于角色的安全性。