c# - 分布式系统中基于声明的访问控制

Question

我正在尝试在分布式系统中使用基于声明的访问控制，以及如何以及在何处管理它们。我还认为我对身份验证服务发出的声明和授权服务发出的声明感到困惑，所以如果能提供任何帮助我解决这个问题的建议，我将不胜感激。

场景

我有一个受信任的联合服务器，用于许多微型站点的单点登录。每个微型网站都有特定的用途。例如。产品门户(用于创建和管理产品)和计费门户(用于创建、查看和支付发票)。

该系统由许多人使用:完全控制整个系统的管理员。内部财务部门只关心计费门户。同样，内部产品团队只对产品门户感兴趣。最后是需要访问两个门户但没有任何后端权限的客户。

联合身份验证

据我了解，当用户成功通过联合服务器的身份验证时，联合服务器会向请求的微型站点提供有关该用户身份的声明。此类声明可能包括:

• 用户电子邮件地址:bob@example.com
• 用户名:Bob
• 用户类型:产品团队
• 与用户身份
相关的任何其他内容

它没有提供与此人可以做什么相关的任何信息(这可能是我的第一个误解)。请注意，用户类型 实际上是对角色的声明。这个术语正确吗？此上下文中的声明是否不同于权限声明？

微网站授权

一旦用户通过身份验证，微型网站就需要知道允许该用户做什么。虽然该网站被交给了一个用户类型(这是对滚动的声明)，但我更愿意使用基于声明的方法。这将提供更细粒度的权限。例如:

• Bob 应该能够编辑价格但不能创建产品。
• Bill(也在产品团队)应该只能添加产品。
• 只应允许 Ben 删除产品。
• Alice(财务)应该没有权限。

使用 claims(与 rolls 相对)可以为微型网站提供额外的灵 active 来授予特定权限。

问题

• 应将这些对允许的操作的声明存储在哪里？
• 每个微型网站都应该提供它自己的联合身份到微型网站声明映射服务吗？
• 每个微型网站都应该缓存这些声明吗？如果鲍勃从产品团队转到财务团队怎么办？

我问这个问题的原因是因为我们的开发部门进行了一场辩论，我们最资深的开发人员认为联合服务器应该提供每个微型网站所需的所有声明。在我看来，这似乎会将联邦服务与每个微型站点紧密耦合。

Answer 1

所以...这里有几个部分在起作用。让我们开始工作吧。

首先，中央身份验证服务是在分布式系统场景中验证用户的好方法，但可能不是处理所有连接的微型站点和/或微服务授权的最佳场所。

基于声明的身份验证

明确地说，在 CAS(中央身份验证服务)中，您可以添加所有相关的声明，包括角色、标志和您以后可能需要的任何其他信息。

但在这里我建议您也熟悉基于资源的授权(如果您还没有的话)。

基于资源的授权

这里的概念是通过询问 Claims Principal 用户是否有权访问资源而不是角色来确定对系统部分(微型站点/微服务)和特定功能的访问权限。

现在，人们通常会在翻译中迷失方向。角色表示为声明；资源也表示为声明。

要确定对产品门户的访问权限，您可以检查 ProductPortal 声明是否存在(可以命名为任何名称)。重要的是您不是在检查用户是否具有管理员角色，而是在检查资源声明的前提。因此，当您决定不仅具有管理员角色的用户应该访问该门户时，您可以将 ProductPortal Resource 声明添加到您授予的任何其他用户它基于您需要的任何标准，例如:角色、标志等。等

但是，这代表了 future 的问题。如果您为分布式系统中每个微站点/微服务中需要的每个资源都添加一个声明，您最终会遇到大量声明。不仅如此，由于某些资源可能与某些微网站/微服务相关，而与其他微网站/微服务无关，因此您随身携带了一个装满东西的包，在任何给定时间，只有少数声明与给定的微网站/微服务相关。

但是不要担心，因为也有一个优雅的解决方案。

声明转换

这是一个您通常会注册为中间件或过滤器以拦截每个请求、读取声明(以及其角色和标志)并使用与您的微站点/微服务相关的资源声明丰富传入的声明主体的过程正在进入。

这样一来，您就不会随身携带一大堆声明，最重要的是您可以将身份验证与授权分离，插入翻译的逻辑对资源的正常声明 对系统的声明最了解它需要控制对部分和功能的访问和权限的资源粒度级别，如果您愿意的话。

---

进入正题

• Where should these claims to allowed actions be stored ?

在 Claims Principal 中，您可以将其作为访问 token 、 session 变量或其他方式传递

• Should each microsite provide it's own federation identity -to- microsite claim mapping service?

声明转换(或声明映射)将驻留在每个微型网站中；最了解最能映射其功能表面的资源的地方。

• Should each microsite cache these claims ? What if Bob moves from the Products team to the Finance team ?

不，没有缓存。您传递的访问 token (或 session )将以声明的形式保持最低限度。由于声明的丰富发生在微型网站的声明转换过程中，当 Bob 从产品团队转到财务团队时，他将失去一些角色声明并获得其他角色声明，这些声明将被正确地转换为与财务相关的资源声明微型网站，并授予他访问您认为合适的部分和功能所需的权限。

---

希望我没有让它太困惑。