ASP.NET Identity表的解释

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

例如，如果您想要进入一个夜总会，授权过程可能是：

门卫会评估您的出生日期声明的值以及他们是否信任发行人（驾驶执照机构），然后才允许您进入。

所以回答“何时应该使用基于声明的安全性？”的问题，答案是“当很难将人们放入明确定义的角色中时”。例如，在夜总会的情景中，将客户分配到角色太困难了，因此您可以使用基于声明的访问控制，基于他们的年龄由其身份证明（例如驾驶执照）确认。然而，在同样的夜总会场景中，您可以使用基于角色的安全性来控制谁有权访问哪些房间（例如使用钥匙卡进入“仅限员工”房间）。显然，您可以根据需要混合使用基于声明的和基于角色的安全性。

ASP.NET Identity Tables Explained

在ASP.NET身份验证中，有两种常用的授权模型：基于角色的授权和基于声明的授权。这两种模型通常一起使用，以构建复杂的授权模型。本文将解释这两种模型的概念、用法和优势。

声明授权是与第三方绑定的授权模型。声明是第三方应用程序提供给你的信息，用于描述用户。这些信息可以是任何类型的数据。例如，假设你有一个音乐混合软件应用程序，它可以使用来自Spotify或YouTube Music等平台的歌曲。在这种情况下，你只需使用电子邮件和密码进行注册，然后在在线状态下，应用程序会要求你输入用于创建Spotify或YouTube Music帐户的电子邮件地址。然后，应用程序通过Web服务请求相应第三方应用程序中的订阅帐户号码，并将其存储为声明。因此，每次在在线状态下尝试访问音乐时，应用程序都会使用注册声明的策略来检查是否具有订阅帐户，并允许访问。声明的一个优点是它们存储有关声明来源的信息，比如存储声明来自哪里的发行者。

角色授权是更为简单明了的授权模型。它基于用户的角色授予访问权限。例如，假设你有一个组织应用程序，有多个来自不同职位的用户。你可以根据用户的职位给予他们不同的角色，并根据角色来授予他们访问不同信息的权限。例如，经理、所有者和员工，不是所有的员工都可以访问经理和所有者拥有的所有信息，而经理也不能访问只属于所有者的某些信息。

在某些应用程序（如ERP系统）中，角色授权和声明授权一起使用，以构建复杂的授权模型。声明在这种情况下充当权限。这也是为什么ASP.NET身份验证中有RoleClaim和UserClaim表的原因，它们允许你扩展授权模型，超出角色本身的范围。当声明与角色一起使用时，它们仅用于授予执行某些操作的访问权限。

例如，假设你有一个打卡系统，其中有一个技术员和一个经理。每周结束时，技术员必须整理包含工匠当周工作小时数的打卡信息报告，这些报告由工资单使用。在这种情况下，经理角色可以访问和编辑工匠的打卡信息，而技术员角色不能。但是，经理可以创建一个声明，并允许技术员访问打卡系统并生成报告。声明可以是仅用于访问而不具有编辑能力的，也可以是具有访问和编辑能力的。只有你的应用程序能理解声明的含义，它们可以被命名为任何内容，如GrantWriteAccess、GrantReadAccess等。在这种情况下，技术员在UserClaim表中将同时拥有GrantWriteAccess和GrantReadAccess。

角色授权和声明授权在ASP.NET身份验证中都有重要的作用。角色授权适用于基于用户角色的简单授权场景，而声明授权则适用于需要更多灵活性和临时授权的场景。通过合理地使用这两种授权模型，可以构建出功能强大且灵活的授权系统。

需要注意的是，在使用声明授权时，声明可以是来自外部资源的，用于描述主体的信息，而在应用程序中使用声明时，它们可以是允许你根据提供的值访问特定资源的键值对。

总之，掌握和理解基于角色的授权和基于声明的授权模型，可以帮助开发人员构建出更加灵活和安全的应用程序。ASP.NET身份验证提供了完整的身份验证框架，使我们能够轻松地实现这些授权模型，并根据实际需求进行调整和扩展。

ASP.NET Identity是一种用于管理用户身份验证和授权的框架。在ASP.NET Identity中，有两种常见的授权方法：基于角色的安全和基于声明的安全。

基于角色的安全是通过将用户分配给一个或多个角色来授予用户访问权限。当将用户分配给一个角色时，用户立即获得该角色定义的所有访问权限。

基于声明的安全是通过声明的方式来定义用户的身份。声明是用户或其他应用程序对自身的陈述，例如用户的姓名、电子邮件、年龄以及对某个操作的授权。在基于角色的安全模型中，用户直接向应用程序提供凭据。在基于声明的模型中，用户提供声明而不是凭据给应用程序。为了使声明具有实际价值，它必须来自应用程序信任的实体。

当不使用基于角色的安全时，选择使用基于声明的安全时，就需要使用AspNetUserClaims表。AspNetUserClaims表用于存储用户的声明信息。

在使用ASP.NET Identity时，可以通过以下链接了解如何使用声明：http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html

关于何时使用基于角色的安全和何时使用基于声明的安全，并没有非常明确的情况。但是，基于声明的访问控制允许更好地将授权规则与核心业务逻辑分离。当授权规则发生变化时，核心业务逻辑不受影响。在某些情况下，您可能更喜欢使用基于声明的方法。

有一些情况下，可能不需要使用声明。如果您的公司有许多内部应用程序，可以使用集成的Windows身份验证来实现声明提供的许多好处。Active Directory非常适合存储用户身份，因为Kerberos是Windows的一部分，所以您的应用程序不需要包含太多的身份验证逻辑。只要您构建的每个应用程序都可以使用集成的Windows身份验证，您可能已经达到了您的身份理想状态。然而，可能有许多原因需要使用除Windows身份验证之外的其他身份验证方式。例如，您可能拥有面向Web的应用程序，这些应用程序由没有在您的Windows域中拥有帐户的人使用。另一个原因可能是您的公司已与另一家公司合并，并且您很难在两个没有（也可能永远不会）建立信任关系的Windows域之间进行身份验证。也许您希望与具有非.NET Framework应用程序的另一家公司共享身份，或者您需要在不同平台上运行的应用程序之间共享身份（例如，Macintosh）。这些只是使用基于声明的身份时可能适合您的情况的一些例子。

需要注意的是，并不是所有情况下都需要使用声明，具体情况取决于应用程序的需求和设计。有关更多信息，请访问http://msdn.microsoft.com/en-us/library/ff359101.aspx。

，ASP.NET Identity中的AspNetUserClaims表用于存储用户的声明信息，而何时使用基于角色的安全或基于声明的安全没有明确的规定，取决于应用程序的需求。基于声明的访问控制可以更好地将授权规则与核心业务逻辑分离，当授权规则发生变化时，核心业务逻辑不受影响。然而，并不是所有情况下都需要使用声明，具体情况取决于应用程序的需求和设计。