【问题标题】:What's the purpose of claims-based authorization?基于声明的授权的目的是什么?
【发布时间】:2010-12-20 01:28:14
【问题描述】:

我一直在阅读有关 Azure 的访问控制服务和基于声明的授权的一般信息,无论出于何种原因,我仍然看不出从基于角色/权限的授权转向声明背后的基本原理- 基于模型。这些模型看起来和我很相似(他们可能是),除了客户端可以做什么和不能做什么的列表来自第三方并且包含在某种令牌中,而不是来自某种数据库服务器必须查询。让第三方(代币发行者)参与有什么好处?

我完全理解将身份验证外包给第三方的优势。它允许应用程序不必一直创建新用户、担心存储密码等,因为他们可以将其推送到已经设置了基础设施的其他服务。它本质上是身份验证的 DRY 原则。

但是,在我看来,同样的逻辑不适用于授权。每个应用程序都有自己必须保护的资源,因此也有自己的规则来授权用户执行某些操作。基础设施似乎很简单,每个应用程序都可以自己创建它(一个将用户映射到角色的表,可能还有另一个将角色映射到权限的表),即使您想外包它,基于声明的模型似乎也在做比这更复杂的东西。

我看到的唯一部分解释来自Building a Claims-Based Security Model in WCF,它为基于声明的身份验证提供了两个主要优点:更大的灵活性,以及​​有人“保证”声明中的信息是正确的。您什么时候需要其中任何一个?

基于声明的授权似乎越来越受欢迎,所以我认为它一定有一些很好的理由;我只是还没弄清楚那是什么。有人可以提供一个具体示例,说明基于声明的身份验证比基于角色的身份验证效果更好,以及为什么在这种情况下效果更好?

(编辑:我错过了文章中列出的第三个好处:支持单点登录/联合。但是在不涉及授权的情况下,身份验证本身就不能解决这个问题吗?)

【问题讨论】:

    标签: wcf authorization


    【解决方案1】:

    我猜想从联合安全/基于声明的系统中获益的主要承诺是减少你必须处理不同系统的领域。

    想象一个网站,其中有本地用户使用 Windows 凭据进行身份验证,一群互联网用户使用用户名/密码,其他人使用证书,可能还有另一组使用生物特征身份验证的用户。

    在当今的系统中,您必须设置和处理各种不同类型的身份验证方案及其不同的处理方式。这可能会变得非常混乱。

    联合安全解决方案的承诺是为您处理所有这些琐事 - STS(安全令牌服务器)将为您处理所有不同类型的身份验证系统,并向您提供一组统一且可信的关于来电者 - 无论他从何地、从哪条路径到达您的站点。

    当然,仅检查一组声明并做出反应,而不必了解四、五、十个不同且完全不同的身份验证系统,这对我来说似乎是一个非常令人信服的承诺!

    【讨论】:

    • 对,但对我来说,这一切听起来像是身份验证而不是授权。我想我在想象用户给了你一些具有经过身份验证的 ID 的令牌,并且服务器根据该 ID 查找权限。该令牌可能包含其他声明,但我不明白为什么会这样。我主要从 Azure 的 ACS 的角度来看待这个问题,它似乎并没有真正给您带来这些好处,因为它只接受几种类型的身份验证。将 ACS 视为纯粹的授权提供者(无身份验证)并且没有看到太多价值,我错了吗?
    • 是的,没错 - 但由于您在身份验证后会看到一组统一的声明,因此您还可以简化对它的授权。您无需处理呈现给您的不同类型的“身份” - 您只需获得一组声明,并基于此授权(或拒绝)给定的调用者执行某些操作
    • 我没有在 Azure ACS 上投入足够的时间来回答这些详细问题,抱歉
    • 谢谢,现在开始明白了。我对 ACS 还有些模糊,但我想我现在至少开始看到基于声明的身份验证背后的基本原理了。
    【解决方案2】:

    基于声明的授权的目的是允许基于布尔表达式的细粒度访问控制,该表达式评估访问实体和资源的特征。这减少或消除了配置组的需要。与联合身份一样,声明还为身份提供者提供了一种管理其用户的工具,同时允许资源提供者控制用户对资产的访问。

    注意:声明可以在单个企业内使用并提供以下好处:

    1) 访问授权和撤销不需要配置或取消配置

    2) 因此变化是瞬时的

    3) 资源所有者可以定义访问的范围和要求,而不是让管理员创建群组来管理群组成员资格 - 这会将访问控制决策交到最适合做出此类决策的人(数据所有者)手中

    4) 这导致需要的组更少,组中的成员也更少

    5) 创建单个群组以容纳具有访问权限的大型社区(对于 例如所有全职员工都可以阅读人力资源政策) - 声明避免了这个问题

    6) 审核提供更多信息 - 授予或拒绝发生的原因清晰可见

    7) 声明支持动态属性,例如 2 因素身份验证、时间或网络限制

    还有很多原因,但我想到了这些。 www.cionsystems.com 上很快就会有一个视频展示这一点(免责声明 - 我在那里工作并录制了视频 - 我仍然需要发布它)此外,作为参考,声明感知应用程序和平台包括 Windows 2012 上的 SharePoint 2010 (文件共享)、Azure、许多 SaaS 服务(Facebook 和 Salesforce)

    此外,通过声明,您可以混合来自多个来源(例如 Facebook 和您当地的广告)等的信息 - 这越来越重要

    不确定规则是否允许这样做,但请随时向我提出您的问题或 cmets。我很乐意编辑帖子以进行任何更正或添加相关信息。

    声明可以来自 AD、数据库表、SAML、OAuth、算法、XACML 或任何其他受信任的提供商。利用声明需要一些工具包 - 应用程序和平台在这个领域迅速发展。

    一切顺利,

    保罗

    【讨论】:

      【解决方案3】:

      基于声明的访问控制还有助于建立基于属性的访问控制和基于策略的访问控制。如果您将一组预先商定的声明标准化,这些声明可以根据用户的其他属性分配给用户(例如,美国经理可以拥有声明 U_M;欧洲经理可以拥有声明 E_M)。 在基于属性和基于策略的环境中,可以使用 XACML 实现细粒度授权(也称为细粒度权利)。 在这种情况下,您可以根据用户是谁(声明)以及他们想要做什么(资源信息)以及在何种情况下(上下文)来获得授权。

      带有 XACML 的 CBAC 可以让您表达如下规则:

      经理可以编辑他们自己创建的笔记或他们自己的笔记 已创建直接下属。

      【讨论】:

        【解决方案4】:

        基于角色的安全是一种有限的安全模型 授权是:

         Based on role membership only
        

        基于声明的安全性更加灵活和富有表现力 授权可以是:

        • 基于角色成员身份

          基于年龄

          基于地理位置

          基于账户余额

          基于尺寸

          基于预定义的安全级别

          基于以上任意组合

        【讨论】:

          猜你喜欢
          • 2021-04-13
          • 2012-11-07
          • 1970-01-01
          • 1970-01-01
          • 2017-06-08
          • 2014-05-01
          • 2014-03-15
          • 1970-01-01
          相关资源
          最近更新 更多