有人可以解释，声明机制在新的ASP.NET身份核心中意味着什么吗？
我可以看到，有一个AspNetUserLogins表，其中包含UserId，LoginProvider和ProviderKey。
但是，我仍然无法理解或找到有关何时将数据添加到AspNetUserClaims表以及此表用于何种情况的任何信息？
答案 0 :(得分：169)
声明机制在新的ASP.NET身份核心中意味着什么？
有两种基于角色和声明的常见授权方法。
基于角色的安全性
用户被分配到一个或多个角色，用户通过该角色获得访问权限。 此外，通过将用户分配给角色，用户可立即获得为该角色定义的所有访问权限。
基于声明的安全性
基于声明的身份是一组声明。声明是实体（用户或其他应用程序）所做的声明 本身，这只是一个主张。例如，声明列表可以包含用户的姓名，用户的电子邮件，用户的年龄，用户对操作的授权。 在基于角色的安全性中，用户将凭证直接呈现给应用程序。以索赔为主 模型，用户向应用程序提供声明而不是凭据。对于声称具有实用性 值，它必须来自应用程序信任的实体。
以下步骤说明了基于声明的安全模型中发生的顺序：
但是，当数据时，我仍然无法理解并找到任何信息 加入AspNetUserClaims以及此表用于什么情况？
当您处于未使用基于角色的安全性且您选择使用基于声明的情况时 安全性，您需要使用AspNetUserClaims表。 有关如何在ASP.NET标识中使用声明，请参阅以下链接以获取更多信息。
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
更新
我什么时候必须使用基于角色的安全性以及基于声明的时候？ 你能写一些例子吗？
您不会或不会使用基于角色或基于声明的安全性的情况非常明显，不像您使用A而不是B的情况。
但是，基于声明的访问控制允许更好地将授权规则与核心业务逻辑分离。授权规则更改时，核心业务逻辑不受影响。在某些情况下，您可能更喜欢使用基于声明的方法。
有时候不需要索赔。这是一个重要的免责声明。 拥有大量内部应用程序的公司可以使用Integrated Windows身份验证可以实现许多提供的好处 索赔。 Active Directory可以很好地存储用户身份， 并且因为Kerberos是Windows的一部分，所以您的应用程序不会 必须包含很多身份验证逻辑。只要每一个 您构建的应用程序可以使用集成Windows身份验证 可能已经达到了你的身份乌托邦。但是，有很多 您可能需要Windows以外的其他原因的原因 认证。您可能使用了面向Web的应用程序 由您的Windows域中没有帐户的人员。另一个 原因可能是贵公司已与另一家公司合并 您在两个Windows林中进行身份验证时遇到问题 不要（也可能永远）不要有信任关系。也许你想 与另一家拥有非.NET Framework的公司共享身份 应用程序或您需要在应用程序之间共享身份 在不同的平台上运行（例如，Macintosh）。这些是 只有少数情况下，基于声明的身份才是正确的 选择你。
有关详细信息，请访问http://msdn.microsoft.com/en-us/library/ff359101.aspx
答案 1 :(得分：4)
这是ASP.NET docs的一个非常简单的解释：
<块引用>创建身份后，可能会为其分配一个或多个由受信任方发布的声明。 声明是一个名称值对，表示主题是什么，而不是主题可以做什么。例如，您可能拥有由当地驾驶执照机构颁发的驾驶执照。您的驾照上有您的出生日期。在这种情况下，索赔名称将是 DateOfBirth，索赔值将是您的出生日期，例如 1970 年 6 月 8 日，颁发者将是驾驶执照当局。最简单的基于声明的授权检查声明的值并允许基于该值访问资源。
接着举一个我们几乎都能理解的例子：
<块引用>例如，如果您想进入夜总会，授权流程可能是： 门安全员会在授予您访问权限之前评估您的出生日期声明的价值以及他们是否信任颁发者（驾驶执照当局）。
所以要回答什么时候应该使用基于声明的安全性？的问题，答案是当很难让人们担任明确定义的角色时。例如，在夜总会场景中，很难将客户置于角色中，因此您可以根据其 ID（例如驾照）确认的年龄使用基于声明的访问控制。但是，在同一个夜总会场景中，您可以使用基于角色的安全性来控制谁可以访问哪些房间（例如，对“仅限员工”的房间使用钥匙卡）。很明显您可以根据需要混合使用基于声明和基于角色的安全性。
答案 2 :(得分：1)
ASP.Net身份验证有两种类型。
您可以使用它们之一，也可以同时使用两者。定义明确的事物时，请使用基于角色的事物。例如，您创建了两个角色老师和学生。只有老师可以添加科目。因此，您将教师角色分配给了您希望有权添加主题的那些用户。
基于索赔的方式更加灵活。假设您有一个要求，一些学生也可以添加科目。在这种情况下，您必须再创建一个可以成为学生并可以添加主题的角色。但是，如果您使用基于声明的方法，这将非常容易。只需创建诸如addSubject之类的声明，并将其分配给您要访问的任何用户即可添加aubject。
答案 3 :(得分：0)
只需添加@Lin上面所说的内容即可。我专门指的是这个问题：
我什么时候必须使用基于角色的安全性以及何时基于声明？ 你能写几个例子吗？
考虑这样一种情况：您有一个拥有技术人员和经理的时钟系统。在每周结束时，技术人员必须安排带有时钟信息的报告，以显示该周工匠的工作时间，并由工资单合并和使用。在提交最终报告之前，通常必须对此类系统进行修正或更正，因为您不想多付或少付您的员工。通过创建Role-Based和Manager Role，可以为管理者和技术人员使用Technician Role方法。但是Manager Role是能够访问和编辑工匠的时钟信息的设备。另一方面，Technician Role可能没有这些功能来访问该信息。但这是有趣的部分；经理可以提出索赔，并允许技术人员访问时钟系统并进行报告。因此，可以仅对未经编辑的访问提出索赔，也可以使用访问和编辑功能提出索赔。
它更像是说，嗯，默认情况下，作为管理员，我可以访问一些我的技术人员无法访问的信息。但是我不总是在办公室里吗？我该怎么办，这样即使我不在身边，他仍然可以继续工作？为了解决这个问题，系统可以具有管理者可以为人们创建索赔的功能，而无需访问某些特定信息。我们经常在我们的ERP系统中到处看到这些。一个无法访问某些模块的用户，当他们获得晋升后，他们就可以对ERP系统进行更多的修改，有时保持相同的用户角色。
这是一个示例，您可以考虑进一步了解声明和角色。