概述

Keycloak支持细粒度授权策略,能够组合不同的访问控制机制:

  • Attribute-based access control 基于属性的访问控制(ABAC)

  • Role-based access control 基于角色的访问控制 (RBAC)

  • User-based access control 基于用户的访问控制 (UBAC)

  • Context-based access control 基于上下文的访问控制 (CBAC)

  • Rule-based access control 基于规则的访问控制

    • 使用Javascript

    • 使用JBoss Drools

  • Time-based access control 基于时间的访问控制

  • Support for custom access control mechanisms (ACMs) through a Policy Provider Service Provider Interface (SPI)通过策略提供商服务提供商接口(SPI)来支持自定义访问控制机制(ACM)

Keycloak基于一组管理UI和RESTful API,并且提供必要的手段为受保护的资源和作用域创建权限,将这些权限与授权策略相关联,并在应用程序和服务中实施授权决策。

资源服务器(服务受保护资源的应用程序或服务)通常依赖于某种信息来决定是否应向受保护资源授予被访问权限。对于基于REST的资源服务器,该信息通常从安全令牌获取。这个安全令牌通常作为承载令牌发送到服务器的每个请求。对于依赖会话验证用户的Web应用程序该信息通常存储在用户的会话中,并从那里检索每个请求。通常,资源服务器只能使用基于角色的访问控制(RBAC)的方式执行授权决策,其中根据映射到这些相同资源的角色检查授予用户访问受保护资源的角色。虽然角色非常有用并被应用程序使用,但它们也有一些限制:

  • 资源和角色紧密耦合,对角色的更改(如添加,删除或更改访问环境)可能会影响多个资源

  • 对安全需求的更改意味着对应用程序代码的深度修改才能体现出来。

  • 随着应用程序的越来越复杂,基于角色管理可能会更困难更容易出错。

  • 访问控制机制不够灵活,角色不代表你是谁并且缺乏上下文信息。如果你被授予了一个角色,只能说明你有一些访问权限。

就当今而言,我们需要考虑分布式环境,用户分布在不同地区,具有不同的本地策略,使用不同的设备,以及对信息共享的高需求。Keycloak授权服务可以帮助您提供应用程序和服务的授权功能:

  • 资源保护采用细粒度授权策略和不同的访问控制机制

  • 统一资源,权限和策略管理

  • 统一决策中心

  • 基于一组基于REST的授权服务的REST安全

  • 可以帮助避免跨项目代码重复(和重新配置)的基础设施并且能快速适应安全需求的变化。

results matching ""

    No results matching ""