MrD*_*per 4 c# architecture authentication authorization claims-based-identity
我正在努力使自己在分布式系统中使用基于声明的访问控制，以及如何以及在何处进行管理。我还认为我对身份验证服务发出的声明和授权服务发出的声明感到困惑，因此，我感谢提供任何建议以帮助我解决这一问题。
情境
我有一个受信任的联合身份验证服务器，用于多个微站点的单点登录。每个微型站点都有特定的用途。例如，一个产品门户（用于创建和管理产品）和一个计费门户（用于创建，查看和支付发票）。
该系统由许多人使用：对整个系统有完全控制权的管理员。内部财务部门仅与计费门户有关。同样，内部产品团队仅对产品门户感兴趣。最后是一个需要访问两个门户但没有任何后端许可的客户。
联合身份验证
据我了解，当用户成功通过联合身份验证服务器进行身份验证时，联合身份验证服务器会向发出请求的微站点提供有关该用户身份的声明。这些主张可能包括：
bob@example.comBobProduct team它没有提供任何与该人可以做什么相关的信息（这可能是我的第一个误解）。请注意，user type实际上是对角色的要求。这个术语正确吗？在这种情况下，索赔与许可索赔是否不同？
微型网站授权
用户通过身份验证后，微型站点需要知道允许该用户执行的操作。将网站移交给user type（这是对版权的声明），我更喜欢使用基于声明的方法。这样可以为权限提供更好的粒度。例如：
通过使用声明，可以使微型网站具有更大的灵活性来授予特定的权限，就像使用滚动一样。
问题
federation identity至- microsite claim地图服务？我问的原因是因为我们在开发部门进行了辩论，而我们最资深的开发人员认为，联合服务器应该提供每个微型站点所需的所有声明。在我看来，这似乎将联邦服务紧密地耦合到每个微型站点。
所以...这里有几件作品。让我们开始工作。
首先，中央身份验证服务是在分布式系统方案中对用户进行身份验证的好方法，但可能不是处理其所有连接的微站点和/或微服务的授权的最佳位置。
为了清楚起见，在CAS（中央身份验证服务）中可以添加所有相关声明，包括它们的角色，标志以及以后可能需要的任何其他信息。
但是在这里，我建议您也熟悉基于资源的授权（如果还没有的话）。
这里的概念是通过询问索赔委托人用户是否有权访问资源而不是角色来确定对系统部分（微站点/微服务）和特定功能的访问。
现在，人们通常会在这里迷失翻译。角色表示为索赔；资源也表示为索赔。
要弄清楚对产品门户的访问，可以检查声明是否ProductPortal存在（可以命名为任意名称）。重要的是，您不是要检查用户是否具有管理员角色，而是要检查资源声明的正确性。所以，当你决定在路上，不仅有管理员角色的用户应该访问的门户网站，你可以在添加ProductPortal 资源索赔的任何其他用户，你要在基于任何你需要的标准，如赋予它：角色，旗，等。等
但是，这代表了未来的问题。如果为分布式系统中每个微站点/微服务中所需的每种资源添加声明，则最终会产生大量的声明。不仅如此，而且由于某些资源在某些微站点/微服务上将是相关的，而在其他微服务/微服务上将不相关，因此您携带的是一个装满了袋子的袋子，其中在任何给定时间只有少数索赔与给定的微站点/微服务有关。
但是，不必担心，因为对此也有很好的解决方案。
您通常会将该过程注册为中间件或过滤器，以拦截每个请求，读取声明（及其角色和标志）并使用与您输入的微站点/微服务相关的资源声明丰富传入的Claims Principal。 。
这样一来，你没有权利携带一个巨大的袋左右，而重要的是你能顶从授权脱钩认证，推动了逻辑转换普通债权分为资源索赔，该系统最清楚这件事将在资源需要如果需要，可以将对部分和功能的访问和权限控制到一个细粒度的级别。
要点
- 这些关于允许动作的声明应存储在哪里？
在Claims Principal中，您可以将其作为访问令牌，会话变量或其他内容传递
- 每个微型站点都应该提供自己的联合身份到微型站点声明映射服务吗？
声明转换（或声明映射）将驻留在每个微型站点中；最了解资源的地方，可以最好地映射其功能表面。
- 每个微型站点都应缓存这些声明吗？如果Bob从产品团队转到财务团队该怎么办？
不，不缓存。您传递的访问令牌（或会话）将保留声明形式的最低要求。由于索赔的充实发生在微型站点中的“索赔转换”过程中，因此，在鲍勃从产品团队移至财务团队的那一刻，他将丢失一些角色索赔而获得其他索赔，并将其正确翻译为与财务相关的资源索赔。微型网站在访问它时，为他提供了他认为需要的部分和功能所需的访问权限。
希望我不要太困惑。