我试图在分布式系统中使用基于声明的访问控制以及管理这些访问控制的方式和位置。我也觉得我对认证服务发出的声明和授权服务发出的声明感到困惑，所以我很感激任何帮助我清除这一点的建议。
方案
我有一个受信任的联合服务器，用于为多个微型网站进行单点登录。每个微型网站都有特定的用途。例如。产品门户（用于创建和管理产品）和结算门户（用于创建，查看和支付发票）。
许多人都使用该系统：完全控制整个系统的管理员。内部财务部门只关注计费门户。同样，内部产品团队只对产品门户感兴趣。最后是一个客户，需要访问这两个门户但没有任何后端权限。
联合身份验证
据我了解，当用户成功通过联合服务器进行身份验证时，联合服务器会向请求的微型网站提供有关该用户身份的声明。此类声明可能包括：
bob@example.com Bob Product team 它没有提供任何与此人可以做的事情有关的事情（这可能是我的第一次误解）。请注意，user type实际上是对角色的声明。这个术语是否正确？此上下文中的声明是否与权限声明不同？
微网站授权
用户通过身份验证后，微型网站需要知道该用户可以执行的操作。虽然该网站提交了user type（这是对滚动的主张），但我更倾向于使用基于声明的方法。这将在权限上提供更精细的粒度。例如：
使用声明，与卷相关使微型网站可以灵活地授予特定权限。
问题
federation identity到microsite claim地图服务？我之所以提出这个问题，是因为我们在开发部门进行了辩论，而我们最资深的开发人员认为联合服务器应提供每个微型网站所需的所有声明。在我看来，它会将联邦服务与每个微型网站紧密结合。
答案 0 :(得分：5)
所以...这里有几件作品。让我们开始工作。
首先，中央身份验证服务是在分布式系统方案中验证用户的好方法，但可能不是处理所有连接的微型网站和/或微服务授权的最佳位置。< / p>
为清楚起见，在CAS（中央身份验证服务）中添加了所有相关的声明，请将其作为角色，标记以及稍后可能需要的任何其他信息。
但在这里，我建议你也要熟悉基于资源的授权（如果你还没有）。
这里的概念是通过向Claim Principal询问用户是否可以访问资源而不是角色来确定对系统部分（微型网站/微服务）和特定功能的访问。
现在，人们通常会在翻译中迷失方向。角色表示为声明;资源也表示为声明。
要确定对产品门户的访问权限，您可以检查ProductPortal索赔是否存在（可以命名为什么）。重要的是，您没有检查用户是否具有管理员角色，而是检查资源声明的前置。因此，当您决定不仅具有管理员角色的用户应该访问门户网站时，您可以将ProductPortal 资源声明添加到基于其提供给它的任何其他用户根据您需要的任何标准，例如：Roles，Flags，et。人
但是，这代表了一个问题。如果您为分布式系统中的每个微型网站/微服务中所需的每个资源添加声明，那么最终会产生大量的声明。不仅如此，而且由于某些资源与某些微型网站/微服务相关，而在其他微型网站/微服务中则没有，因此您需要携带一个装满的包，其中只有少数声明在任何给定时间与给定的微型网站/微服务相关。
但是，不要担心，因为这也有一个优雅的解决方案。
这是一个过程，您通常会注册为中间件或过滤器来拦截每个请求，阅读声明（以及它的角色和标志）并使用与微型网站/微服务相关的资源声明来丰富传入的声明主体'进入。
通过这种方式，您不会携带大量的声明，最重要的是，您可以将身份验证与授权分离，推动翻译的逻辑对最了解的系统的资源的正常声明，需要来控制对部分和功能的访问权限和权限如果您愿意，可以使用粒度级别。
要点
- 这些对允许行为的主张应该存储在哪里？
在声明主体中，您可以作为访问令牌传递，会话变量或不是
- 每个微型网站是否应该提供自己的联盟身份 - 微型索赔地图服务？
声明转换（或声明映射）将驻留在每个微型网站中;最了解资源的地方，它最能映射其功能。
- 每个微型网站都应该缓存这些声明吗？如果Bob从产品团队转移到财务团队怎么办？
不，没有缓存。您传递的访问令牌（或会话）将以声明的形式保留最低限度。由于索赔的丰富发生在微型网站的索赔转换过程中，当Bob从产品团队转移到财务团队时，他将失去一些角色声明并获得其他人，这将被正确地转换为与财务相关的资源声明微观网站在访问它时，并为他提供他认为合适的部分和功能所需的访问权限。
希望我没有让它太混乱。