关于 SAML、OAuth 的问题答案

【问题标题】：Questions about SAML, OAuth关于 SAML、OAuth 的问题
【发布时间】：2012-06-17 05:26:13
【问题描述】：

我正在开发一个在系统中实现基于令牌的身份验证的项目。我正在考虑使用 SAML 或 OAuth。

我想知道是否可以在令牌中表示实际的策略（基于系统的 ACL）。对于当前的设计，我正在考虑给用户一个包含所有资源和允许角色的令牌。该服务根据用户的请求检查此令牌以查看用户是否对所涉及的资源具有所需的权限。

是否可以使用 SAML/OAuth 令牌来表示？如果两者都可以，这里应该使用哪一个。从我看到的大多数示例中，SAML 用于 SSO 解决方案，而 OAuth 用于定义实际的授权策略。但是从演示/示例中不清楚是否可以使用 OAuth 对特定资源进行限制性访问。

例如当 Facebook 应用程序想要使用 OAuth 访问您的照片时，是否可以限制仅访问特定相册？还是更像是全有或全无的方法。是否有任何资源可供我阅读以获取更多信息？

【问题讨论】：

标签： authentication oauth authorization saml

【解决方案1】：

大多数架构（对于 SAML 和 OAuth）使用包含属性的令牌，依赖方（或接收 API）随后解释并应用其自己的策略 (ACL)。

在 OAuth 的情况下，范围用于指定访问令牌所代表的权限。范围可以随心所欲地细化（以涵盖单个相册限制等情况）。这些可能已在某些 OAuth 流程中由用户授权。令牌本身未在 OAuth 2.0 规范中定义 - 但您可以使格式自包含（可能由令牌颁发者进行数字签名），以便将范围保存在其中。一些模型使用不透明的令牌，需要通过回调（可能是反向通道）向颁发者进行验证，然后将范围返回给依赖方。

在 SAML 中，一个属性声明可以出现在一个断言中，用于类似的目的。依赖方解释各个属性以确定用户被授权做什么。属性声明可以作为 SSO 的一部分通过，也可以在稍后的某个时间点（在身份验证之后）通过 AttributeQuery 获得。

【讨论】：

感谢您的回复！如果是上述项目，我认为将有 1000 多个资源。那么根据我对角色的理解，我需要定义数千个角色吗？如果允许一个用户访问多个资源，则必须设计一个新角色。但是在 SAML 的情况下，这可以使用 AttributeQuery 以一些 XML 语句的形式来实现，而且会更干净吗？
在很多方面都差不多。如果您确实需要控制细粒度的访问，那么您最终可能会获得角色/范围与资源的 1 对 1 映射。您可能还想考虑 SAML AuthzDecisionQuery，它可以减轻您定义角色的负担（至少在身份提供者和依赖方之间是已知的）。相反，RP 只是询问 IdP 用户是否可以访问某些内容（例如给定的 URL）。
我的印象是，在 SAML 中，用户可以获得包含 XML 语句的令牌。我计划使用这些 XML 语句来定义相关用户可以使用的资源以及允许的权限。有了这个实现，就不需要定义任何角色。仍然需要定义这些组，但这只是已经存在的 ACL 的自然扩展。这就是为什么我认为这将是一个比 OAuth 更简单、更清晰的实现。如果我的理解不正确，请纠正我。再次感谢！
听起来不错。我只是建议“角色”，因为它们通常用于抽象出您需要在各方之间共享的资源/权限定义（可能与您对“组”所做的相同）。让您可以灵活地改变一侧，而不必影响另一侧。您也可以以大致相同的方式在 OAuth 中使用“范围”来执行此操作。至少使用 OAuth，您肯定可以摆脱处理 XML 的复杂性，这是一大优势。