권한 부여 서비스 가이드


Red Hat Single Sign-On 7.6

Red Hat Single Sign-On 7.6과 함께 사용하는 경우

Red Hat Customer Content Services

초록

이 안내서는 Red Hat Single Sign-On 7.6의 권한 부여 서비스에 대한 정보로 구성되어 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 권한 부여 서비스 개요

Red Hat Single Sign-On은 세분화된 권한 부여 정책을 지원하며 다음과 같은 다양한 액세스 제어 메커니즘을 결합할 수 있습니다.

  • ABAC(Attribute-based access control)
  • 역할 기반 액세스 제어(RBAC)
  • UBAC(User-based Access Control)
  • 컨텍스트 기반 액세스 제어(CBAC)
  • 규칙 기반 액세스 제어

    • Using JavaScript
  • 시간 기반 액세스 제어
  • SPI(Service Provider Interface)를 통해 ACM(Custom Access Control mechanisms) 지원

Red Hat Single Sign-On은 관리 UI와 RESTful API 세트를 기반으로 하며, 보호된 리소스 및 범위에 대한 권한을 생성하고, 해당 권한을 권한 부여 정책과 연결하고, 애플리케이션 및 서비스에 권한 부여 결정을 적용하는 데 필요한 수단을 제공합니다.

일반적으로 보호된 리소스를 제공하는 리소스 서버(애플리케이션 또는 서비스)는 어떤 종류의 정보를 사용하여 보호되는 리소스에 대한 액세스 권한을 부여해야 하는지 결정합니다. RESTful 기반 리소스 서버의 경우 해당 정보는 일반적으로 보안 토큰에서 얻을 수 있으며 일반적으로 서버에 대한 모든 요청에서 전달자 토큰으로 전송됩니다. 세션을 통해 사용자를 인증하는 웹 애플리케이션의 경우 해당 정보는 일반적으로 사용자 세션에 저장되며 각 요청에 대해 해당 정보가 검색됩니다.

종종 리소스 서버는 보호되는 리소스에 액세스하려는 사용자에게 부여된 역할이 이러한 동일한 리소스에 매핑된 역할에 대해 확인되는 RBAC(역할 기반 액세스 제어)를 기반으로 권한 결정만 수행합니다. 역할은 매우 유용하고 애플리케이션에서 사용하지만 몇 가지 제한 사항이 있습니다.

  • 리소스 및 역할은 긴밀하게 연결되고 역할에 대한 변경(예: 액세스 컨텍스트 추가, 제거 또는 변경)이 여러 리소스에 영향을 미칠 수 있습니다.
  • 보안 요구 사항을 변경하면 이러한 변경 사항을 반영하기 위해 애플리케이션 코드에 대한 깊은 변경이 발생할 수 있습니다.
  • 애플리케이션 크기에 따라 역할 관리가 어려워지고 오류가 발생하기 쉽습니다.
  • 가장 유연한 액세스 제어 메커니즘은 아닙니다. 역할은 사용자가 누구인지 및 상황 정보가 없는 사람을 나타내지 않습니다. 역할을 부여 받은 경우 적어도 일부 액세스 권한이 있어야 합니다.

오늘날 Red Hat은 사용자가 서로 다른 로컬 정책, 서로 다른 장치를 사용하고, 정보 공유를 위한 높은 수요와 함께 다양한 지역에 분산된 이기종 환경을 고려해야 합니다. Red Hat Single Sign-On 인증 서비스는 다음과 같은 기능을 제공하여 애플리케이션 및 서비스의 권한 부여 기능을 개선하는 데 도움이 될 수 있습니다.

  • 세분화된 권한 부여 정책 및 다른 액세스 제어 메커니즘을 사용한 리소스 보호
  • 중앙 집중식 리소스, 권한 및 정책 관리
  • 중앙 집중식 정책 결정 지점
  • REST 기반 권한 부여 서비스 세트를 기반으로 REST 보안
  • 권한 부여 워크플로 및 사용자 관리 액세스
  • 인프라로 인해 프로젝트 간에 코드 복제를 방지하고 보안 요구 사항에 빠르게 대응할 수 있습니다.

1.1. 아키텍처

Red Hat Single Sign-On AuthZ architecture overview

설계 관점에서 Authorization Services는 다음과 같은 기능을 제공하는 잘 정의된 권한 부여 패턴 세트를 기반으로 합니다.

  • 정책 관리 포인트 (PAP)

    Red Hat Single Sign-On 관리 콘솔을 기반으로 하는 UI 세트를 제공하여 리소스 서버, 리소스, 범위, 권한 및 정책을 관리합니다. 이 중 일부는 Protection API 를 사용하여 원격으로 수행됩니다.

  • PDP(Policy Decision Point)

    권한 부여 요청이 전송되는 위치에 배포 가능한 정책 결정 지점을 제공하고 요청된 권한에 따라 정책을 평가합니다. 자세한 내용은 권한 가져오기를 참조하십시오.

  • PEP (Policy Enforcement Point)

    리소스 서버 측에서 권한 결정을 실제로 적용하기 위한 다양한 환경에 대한 구현을 제공합니다. Red Hat Single Sign-On은 몇 가지 기본 제공 정책 강화 기능을 제공합니다.

  • 정책 정보 포인트 (PIP)

    Red Hat Single Sign-On Authentication Server를 기반으로 하는 경우 권한 부여 정책을 평가하는 동안 ID 및 런타임 환경에서 속성을 얻을 수 있습니다.

1.1.1. 권한 부여 프로세스

Red Hat Single Sign-On 사용 방법을 이해하는 데 필요한 세 가지 주요 프로세스를 통해 애플리케이션에 대한 세분화된 승인을 가능하게 합니다.

  • 리소스 관리
  • 권한 및 정책 관리
  • 정책 적용
1.1.1.1. 리소스 관리

리소스 관리는 보호 대상을 정의하는 데 필요한 모든 단계를 포함합니다.

Resource management overview

먼저 웹 애플리케이션 또는 하나 이상의 서비스 집합을 나타내는 보호하기 위해 Red Hat Single Sign-On을 지정해야 합니다. 리소스 서버에 대한 자세한 내용은 Terminology 를 참조하십시오.

리소스 서버는 Red Hat Single Sign-On 관리 콘솔을 사용하여 관리됩니다. 여기에서 등록된 클라이언트 애플리케이션을 리소스 서버로 활성화하고 보호하려는 리소스 및 범위 관리를 시작할 수 있습니다.

Resource Server overview

리소스는 웹 페이지, RESTFul 리소스, 파일 시스템의 파일, NodePort 등일 수 있습니다. 리소스 그룹(Java의 클래스처럼) 또는 단일 특정 리소스를 나타낼 수 있습니다.

예를 들어, 모든 뱅킹 계정을 나타내는 CloudEvent 계정 리소스가 있을 수 있으며 이를 사용하여 모든 뱅킹 계정에 공통적인 권한 부여 정책을 정의할 수 있습니다. 그러나 소유자만 일부 정보에 액세스하거나 작업을 수행할 수 있는 Alice 계정에 대한 특정 정책(고객에 속하는 리소스 인스턴스)을 정의할 수 있습니다.

리소스는 Red Hat Single Sign-On 관리 콘솔 또는 Protection API 를 사용하여 관리할 수 있습니다. 후자의 경우 리소스 서버는 리소스를 원격으로 관리할 수 있습니다.

범위는 일반적으로 리소스에서 수행할 수 있지만 이에 국한되지 않는 작업을 나타냅니다. 범위를 사용하여 리소스 내에서 하나 이상의 속성을 나타낼 수도 있습니다.

1.1.1.2. 권한 및 정책 관리

리소스 서버와 보호하려는 모든 리소스를 정의한 후에는 권한 및 정책을 설정해야 합니다.

이 프로세스에는 리소스를 관리하는 보안 및 액세스 요구 사항을 실제로 정의하는 데 필요한 모든 단계가 포함됩니다.

Permission and policy management overview

정책은 어떤 항목(리소스 또는 범위)에서 작업에 액세스하거나 실행하기 위해 충족해야 하는 조건을 정의하지만 보호 대상과 연결되지 않습니다. 이는 일반적이며 권한 또는 훨씬 더 복잡한 정책을 빌드하도록 재사용할 수 있습니다.

예를 들어 역할 "User Premium"으로 부여된 사용자만 리소스 그룹에 대한 액세스를 허용하려면 RBAC(역할 기반 액세스 제어)를 사용할 수 있습니다.

Red Hat Single Sign-On은 가장 일반적인 액세스 제어 메커니즘을 다루는 몇 가지 기본 제공 정책 유형(및 해당 정책 공급자)을 제공합니다. JavaScript를 사용하여 작성된 규칙을 기반으로 정책을 만들 수도 있습니다.

정책을 정의하면 권한 정의를 시작할 수 있습니다. 권한은 보호하려는 리소스와 결합됩니다. 여기에서 보호하려는 내용(리소스 또는 범위)과 권한을 부여하거나 거부하기 위해 만족해야 하는 정책을 지정합니다.

1.1.1.3. 정책 시행

정책 적용 에는 리소스 서버에 권한 결정을 실제로 적용하는 데 필요한 단계가 포함됩니다. 권한 부여 서버와 통신할 수 있는 리소스 서버에서 Policy Enforcement Point 또는 PEP를 활성화하고, 권한 부여 데이터를 요청하고, 서버에서 반환된 결정 및 권한에 따라 보호 리소스에 대한 액세스를 제어하도록 함으로써 달성됩니다.

PEP overview

Red Hat Single Sign-On은 실행 중인 플랫폼에 따라 애플리케이션을 보호하는 데 사용할 수 있는 일부 기본 제공 정책 적용 구현을 제공합니다.

1.1.2. 권한 부여 서비스

권한 부여 서비스는 다음 RESTFul 엔드포인트로 구성됩니다.

  • 토큰 끝점
  • 리소스 관리 끝점
  • 권한 관리 끝점

이러한 각 서비스는 권한 부여 프로세스와 관련된 다양한 단계를 다루는 특정 API를 제공합니다.

1.1.2.1. 토큰 끝점

OAuth2 클라이언트(예: 프런트 엔드 애플리케이션)는 토큰 끝점을 사용하여 서버에서 액세스 토큰을 가져오고 동일한 토큰을 사용하여 리소스 서버(예: 백엔드 서비스)로 보호된 리소스에 액세스할 수 있습니다. 마찬가지로 Red Hat Single Sign-On Authorization Services는 OAuth2의 확장을 제공하여 요청되는 리소스 또는 범위와 관련된 모든 정책의 처리에 따라 액세스 토큰을 발행할 수 있도록 합니다. 즉, 리소스 서버는 서버에서 부여하고 액세스 토큰에 의해 보유되는 권한에 따라 보호되는 리소스에 대한 액세스를 적용할 수 있습니다. Red Hat Single Sign-On Authorization Services에서 권한이 있는 액세스 토큰은 요청 당사자 토큰 또는 RPT라고 합니다.

1.1.2.2. 보호 API

Protection API 는 리소스 서버가 관련 리소스, 범위, 권한 및 정책을 관리할 수 있도록 지원하는 일련의 UMA 호환 엔드포인트입니다. 리소스 서버만 이 API에 액세스할 수 있습니다. 이 API에는 uma_protection 범위도 필요합니다.

Protection API에서 제공하는 작업은 다음 두 가지 주요 그룹으로 구성할 수 있습니다.

  • 리소스 관리

    • 리소스 생성
    • 리소스 삭제
    • Id로 검색
    • 쿼리
  • 권한 관리

    • 권한 티켓 발행
참고

기본적으로 원격 리소스 관리가 활성화됩니다. Red Hat Single Sign-On 관리 콘솔을 사용하여 변경할 수 있으며 콘솔을 통해 리소스 관리만 허용할 수 있습니다.

UMA 프로토콜을 사용할 때 Protection API의 권한 티켓 발급은 전체 승인 프로세스에서 중요한 부분입니다. 후속 섹션에 설명된 대로 클라이언트에서 요청하는 권한을 나타내며 서버로 전송된 권한 및 요청 범위와 연결된 권한 및 정책을 평가하는 동안 부여된 모든 권한이 있는 최종 토큰을 가져옵니다.

1.2. 용어

또한 Red Hat Single Sign-On Authorization Services에서 도입한 이러한 용어와 개념을 이해하는 것이 중요합니다.

1.2.1. 리소스 서버

OAuth2 용어에 따라 리소스 서버는 보호된 리소스를 호스팅하는 서버이며 보호되는 리소스 요청을 수락하고 응답할 수 있습니다.

일반적으로 리소스 서버는 보안 리소스에 대한 액세스 권한을 부여해야 하는지 여부를 결정하는 데 일종의 정보를 사용합니다. RESTful 기반 리소스 서버의 경우 해당 정보는 일반적으로 보안 토큰으로 전송되며 일반적으로 서버에 대한 모든 요청과 함께 전달자 토큰으로 전송됩니다. 세션을 통해 사용자를 인증하는 웹 애플리케이션은 일반적으로 사용자 세션에 해당 정보를 저장하고 각 요청에 대해 이를 검색합니다.

Red Hat Single Sign-On에서는 모든 기밀 클라이언트 애플리케이션이 리소스 서버 역할을 할 수 있습니다. 이 클라이언트의 리소스와 각 범위는 일련의 권한 부여 정책에 의해 보호 및 관리됩니다.

1.2.2. 리소스

리소스는 애플리케이션 및 조직의 자산의 일부입니다. 하나 이상의 끝점 세트, HTML 페이지 등과 같은 클래식 웹 리소스일 수 있습니다. 권한 부여 정책 용어에서 리소스는 보호되는 오브젝트 입니다.

모든 리소스에는 단일 리소스 또는 리소스 집합을 나타낼 수 있는 고유 식별자가 있습니다. 예를 들어, 모든 뱅킹 계정에 대한 권한 부여 정책 집합을 정의하고 정의하는 Banking 계정 리소스를 관리할 수 있습니다. 그러나 사용자는 자체 권한 부여 정책을 가질 수 있는 단일 고객이 소유한 단일 리소스를 나타내는 Alice의Banking 계정 이라는 다른 리소스를 보유할 수도 있습니다.

1.2.3. 범위

리소스의 범위는 리소스에서 수행할 수 있는 바인딩된 액세스 범위입니다. 권한 부여 정책 용어에서 범위는 리소스에 논리적으로 적용할 수 있는 여러 동사 중 하나입니다.

일반적으로 지정된 리소스로 수행할 수 있는 작업을 나타냅니다. 범위 예는 view, edit, delete 등입니다. 그러나 범위는 리소스에서 제공하는 특정 정보와 관련이 있을 수도 있습니다. 이 경우 프로젝트 리소스와 비용 범위가 있을 수 있습니다. 여기서 비용 범위는 사용자가 프로젝트 비용에 액세스할 수 있는 특정 정책 및 권한을 정의하는 데 사용됩니다.

1.2.4. 권한

이 간단하고 일반적인 권한을 고려하십시오.

권한은 보호 중인 오브젝트를 평가하여 액세스 권한이 부여되는지 여부를 판별해야 하는 정책과 연결합니다.

  • X 는 리소스 Z에서 Y 를 수행할 수 있습니다.

    • 여기서 …​

      • X 는 하나 이상의 사용자, 역할 또는 그룹 또는 그 중 하나를 나타냅니다. 여기에서 클레임 및 컨텍스트를 사용할 수도 있습니다.
      • Y 는 수행할 작업(예: 쓰기, 보기 등)을 나타냅니다.
      • Z 는 보호된 리소스(예: "/accounts)를 나타냅니다.

Red Hat Single Sign-On은 간단한 규칙 기반 동적 권한까지 다양한 권한 전략을 구축하기 위한 풍부한 플랫폼을 제공합니다. 유연성을 제공하고 다음을 수행하는 데 도움이 됩니다.

  • 코드 리팩토링 및 권한 관리 비용 절감
  • 보다 유연한 보안 모델을 지원하여 보안 요구 사항에 쉽게 적응할 수 있도록 지원합니다.
  • 런타임 시 변경 작업을 수행합니다. 애플리케이션은 보호되는 리소스와 범위에 대해서만 관련이 있으며 보호되는 방법이 아닙니다.

1.2.5. 정책

정책은 오브젝트에 대한 액세스 권한을 부여하기 위해 충족해야 하는 조건을 정의합니다. 권한과 달리 보호되는 오브젝트는 지정할 수 없지만 지정된 개체(예: 리소스, 범위 또는 둘 다)에 액세스하기 위해 충족해야 하는 조건을 지정해야 합니다. 정책은 리소스를 보호하는 데 사용할 수 있는 다양한 ACM(액세스 제어 메커니즘)과 긴밀하게 관련이 있습니다. 정책을 사용하면 속성 기반 액세스 제어(ABAC), 역할 기반 액세스 제어(RBAC), 컨텍스트 기반 액세스 제어 또는 이러한 조합에 대한 전략을 구현할 수 있습니다.

Red Hat Single Sign-On은 "정책" 정책을 구축하고 평가 동작을 계속 제어할 수 있는 집계된 정책에 대한 개념을 제공하여 정책의 개념과 정책 정의 방법을 활용합니다. 지정된 리소스에 액세스하기 위해 충족해야 하는 모든 조건에 대해 하나의 대규모 정책을 작성하는 대신 Red Hat Single Sign-On Authorization Services의 정책 구현은 분할 및 빈도 기술을 따릅니다. 즉, 개별 정책을 생성한 다음 다른 권한으로 재사용하고 개별 정책을 결합하여 더 복잡한 정책을 빌드할 수 있습니다.

1.2.6. 정책 공급자

정책 공급자는 특정 정책 유형의 구현입니다. Red Hat Single Sign-On은 해당 정책 공급자가 지원하는 내장 정책을 제공하며 특정 요구 사항을 지원하는 고유한 정책 유형을 생성할 수 있습니다.

Red Hat Single Sign-On은 자체 정책 공급자 구현을 연결하는 데 사용할 수 있는 SPI(Service Provider Interface)를 제공합니다.

1.2.7. 권한 티켓

권한 티켓은 권한 부여 서버에 의해 결정되는 불투명 구조를 제공하는 UMA(User-Managed Access) 사양에 정의된 특수한 유형의 토큰입니다. 이 구조는 클라이언트가 요청하는 리소스 및/또는 범위 및 권한 부여 데이터 요청(RPT)에 적용해야 하는 정책을 나타냅니다.

UMA에서 권한 티켓은 개인 간 공유와 조직 간 공유를 지원하는 데 중요합니다. 권한 부여 워크플로에 대한 권한 티켓을 사용하면 리소스 소유자와 리소스 서버가 이러한 리소스에 대한 액세스를 제어하는 세분화된 정책을 기반으로 리소스를 완벽하게 제어할 수 있는 간단한 시나리오에서 복잡한 다양한 시나리오를 사용할 수 있습니다.

UMA 워크플로에서는 권한 부여 서버에서 리소스 서버로 권한 티켓을 발행하여 보호되는 리소스에 액세스하려는 클라이언트에 권한 티켓을 반환합니다. 클라이언트가 티켓을 수신하면 티켓을 권한 부여 서버로 다시 보내 RPT(승인 데이터를 보유한 최종 토큰)를 요청할 수 있습니다.

권한 티켓에 대한 자세한 내용은 User-Managed AccessUMA 사양을 참조하십시오.

2장. 시작하기

이 튜토리얼을 사용하기 전에 Red Hat Single Sign-On 설치를 완료하고 시작하기 가이드 튜토리얼에 표시된 대로 초기 admin 사용자를 생성해야 합니다. 여기에는 한 가지 주의 사항이 있습니다. Red Hat Single Sign-On Server와 동일한 시스템에서 별도의 JBoss EAP 인스턴스를 실행해야 합니다. 이 별도의 인스턴스는 Java Servlet 애플리케이션을 실행합니다. 따라서 동일한 시스템에서 실행할 때 포트 충돌이 발생하지 않도록 Red Hat Single Sign-On을 다른 포트에서 실행해야 합니다. 명령줄에서 jboss.socket.binding.port-offset 시스템 속성을 사용합니다. 이 속성의 값은 Red Hat Single Sign-On Server에서 연 모든 포트의 기본 값에 추가되는 번호입니다.

Red Hat Single Sign-On Server를 부팅하려면 다음을 수행합니다.

Linux/Unix

$ .../bin/standalone.sh -Djboss.socket.binding.port-offset=100
Copy to Clipboard

Windows

> ...\bin\standalone.bat -Djboss.socket.binding.port-offset=100
Copy to Clipboard

두 서버를 모두 설치하고 부팅한 후에는 http://localhost:8180/auth/admin/에서 Red Hat Single Sign-On 관리 콘솔과 http://localhost:8080 EAP 인스턴스에 액세스할 수 있습니다.

2.1. 서블릿 애플리케이션 보안

이 시작하기 가이드의 목적은 Red Hat Single Sign-On에서 제공하는 다양한 권한 부여 기능을 실험하고 테스트할 수 있도록 최대한 빨리 시작하고 실행하는 것입니다. 이 빠른 둘러보기는 기본 데이터베이스 및 서버 구성에 크게 사용되며 복잡한 배포 옵션은 다루지 않습니다. 기능 또는 구성 옵션에 대한 자세한 내용은 이 문서의 해당 섹션을 참조하십시오.

이 가이드에서는 Red Hat Single Sign-On 인증 서비스에 대한 주요 개념에 대해 설명합니다.

  • 클라이언트 애플리케이션에 대한 세분화된 권한 부여 활성화
  • 보안 리소스를 사용하여 클라이언트 애플리케이션을 리소스 서버로 구성
  • 보호 리소스에 대한 액세스 제어 권한 및 권한 부여 정책 정의
  • 애플리케이션에 대한 정책 시행 활성화.

2.2. 영역 및 사용자 생성

이 튜토리얼의 첫 번째 단계는 해당 영역에 영역과 사용자를 생성하는 것입니다. 그러면 영역 내에서 단일 클라이언트 애플리케이션을 생성합니다. 그러면 권한 부여 서비스를 활성화해야 하는 리소스 서버가 됩니다.

절차

  1. 이름이 hello-world-authz 인 영역을 만듭니다. 생성되면 다음과 유사한 페이지가 표시됩니다.

    realm hello-world-authz

    Realm hello-world-authz

  2. 사용자를 클릭합니다.

    사용자 목록 페이지에 사용자를 만들 수 있는 위치가 표시됩니다.

  3. 사용자 추가를 클릭합니다.
  4. Username,Email,First Name, Last Name 필드를 작성합니다.
  5. 사용자 활성화를 ON 으로 전환
  6. 저장을 클릭합니다.

    사용자 추가

    Add User

  7. 인증 정보 탭을 클릭하여 사용자의 암호를 설정합니다.

    사용자 암호 설정

    Set user password

  8. 암호를 사용하여 암호 및 암호 확인 필드를 작성하고 TemporaryOFF 로 전환합니다.
  9. Set Password 를 클릭하여 사용자 암호를 설정합니다.

2.3. 권한 부여 서비스 활성화

OpenID Connect 프로토콜을 사용하도록 구성된 기존 클라이언트 애플리케이션에서 권한 부여 서비스를 활성화할 수 있습니다. 다음 절차에 따라 클라이언트를 생성할 수도 있습니다.

절차

  1. 클라이언트를 클릭하여 클라이언트 애플리케이션 생성을 시작합니다.
  2. Client ID,Client Protocol, Root URL 필드를 입력합니다.

    클라이언트 애플리케이션 생성

    Create client application

  3. 저장을 클릭합니다.

    클라이언트 설정 페이지가 표시됩니다.

  4. 액세스 유형 필드에서 기밀 을 선택하고 Authorization EnabledON으로 전환합니다.
  5. 저장을 클릭합니다.

    클라이언트에 대한 새 권한 부여 탭이 표시됩니다.

    클라이언트 설정

    Client Settings

  6. Authorization 탭을 클릭합니다.

    다음과 유사한 인증 설정 페이지가 표시됩니다.

    권한 부여 설정

    Authorization settings

클라이언트 애플리케이션에 대한 권한 부여 서비스를 활성화하면 Red Hat Single Sign-On은 클라이언트 권한 부여 구성에 대한 몇 가지 기본 설정을 자동으로 생성합니다.

2.4. 애플리케이션을 빌드, 배포 및 테스트합니다.

이제 app-authz- vaninitiator 리소스 서버(또는 클라이언트)가 올바르게 구성되어 권한 부여 서비스가 활성화되었으므로 서버에 배포할 수 있습니다.

배포하려는 애플리케이션의 프로젝트와 코드는 Red Hat Single Sign-On 빠른 시작 리포지토리에서 사용할 수 있습니다. 계속하려면 다음을 시스템에 설치하고 PATH에서 사용할 수 있습니다.

  • Java JDK 8
  • Apache Maven 3.1.1 이상
  • Git

https://github.com/redhat-developer/redhat-sso-quickstarts 에서 리포지토리를 복제하여 코드를 가져올 수 있습니다. 사용 중인 Red Hat Single Sign-On 버전과 일치하는 분기를 사용합니다.

다음 단계에 따라 코드를 다운로드합니다.

복제 프로젝트

$ git clone https://github.com/redhat-developer/redhat-sso-quickstarts
Copy to Clipboard

빌드 및 배포하려는 애플리케이션은 다음에 있습니다.

$ cd redhat-sso-quickstarts/app-authz-jee-vanilla
Copy to Clipboard

2.4.1. 어댑터 구성 가져오기

애플리케이션을 빌드하고 배포하기 전에 먼저 어댑터 구성을 가져와야 합니다.

절차

  1. 관리 콘솔에 로그인합니다.
  2. 메뉴에서 Clients 를 클릭합니다.
  3. 클라이언트 목록에서 app-authz-vanill 클라이언트 애플리케이션을 클릭합니다. 클라이언트 설정 페이지가 열립니다.

    클라이언트 설정

    Client Settings

  4. 설치 탭을 클릭합니다.
  5. 형식 옵션 항목 목록에서 Keycloak OIDC JSON 을 선택합니다.

    어댑터 구성은 JSON 형식으로 표시됩니다.

  6. 다운로드를 클릭합니다.

    Adapter 구성

    Adapter configuration

  7. keycloak.json 파일을 app-authz-jee-vaninitiator/config 디렉터리로 이동합니다.
  8. 필요한 경우 리디렉션 URL을 지정합니다.

    기본적으로 정책 적용자는 사용자에게 리소스 서버의 보호된 리소스에 액세스할 수 있는 권한이 부족하면 403 상태 코드로 응답합니다. 그러나 권한이 없는 사용자의 리디렉션 URL을 지정할 수도 있습니다. 리디렉션 URL을 지정하려면 업데이트한 keycloak.json 파일을 편집하고 policy-enforcer 구성을 다음으로 바꿉니다.

    "policy-enforcer": {
        "on-deny-redirect-to" : "/app-authz-vanilla/error.jsp"
    }
    Copy to Clipboard

    이 변경 사항은 사용자에게 도움이 되지 않는 403 Unauthorized 메시지가 아니라 보호 리소스에 액세스하는 데 필요한 권한이 없는 경우 사용자를 /app-authz-van 대개/error.jsp 페이지로 리디렉션하는 정책 적용자에게 지정합니다.

2.4.2. 애플리케이션 빌드 및 배포

애플리케이션을 빌드하고 배포하려면 다음 명령을 실행합니다.

$ cd redhat-sso-quickstarts/app-authz-jee-vanilla
$ mvn clean package wildfly:deploy
Copy to Clipboard

2.4.3. 애플리케이션 테스트

애플리케이션이 성공적으로 배포된 경우 http://localhost:8080/app-authz-vanilla 에서 액세스할 수 있습니다. Red Hat Single Sign-On 로그인 페이지가 열립니다.

로그인 페이지

Login page

절차

  1. 해당 사용자에 대해 지정한 암호를 사용하여 alice 로 로그인합니다. 다음 페이지가 표시됩니다.

    hello World Authz 메인 페이지

    Hello World Authz main page

    클라이언트 애플리케이션에 대한 권한 부여 서비스를 활성화할 때 Red Hat Single Sign-On에서 정의한 기본 설정은 이 정책으로 보호되는 리소스에 항상 액세스 권한을 부여하는 간단한 정책을 제공합니다.

기본 권한 및 정책을 변경하고 애플리케이션의 응답 방법을 테스트하거나 Red Hat Single Sign-On에서 제공하는 다양한 정책 유형을 사용하여 새 정책을 만들 수도 있습니다.

이 애플리케이션을 테스트하기 위해 지금 할 수있는 일이 많이 있습니다. 예를 들어 클라이언트의 Authorization 탭을 클릭한 다음 Policies 탭에서 client를 클릭한 다음 목록에서 Default Policy 를 클릭하여 기본 정책을 변경할 수 있습니다. 이제 이 페이지의 드롭다운 목록을 사용하여 LogicNegative 로 변경합니다.

  1. 데모 애플리케이션에서 로그아웃한 후 다시 로그인합니다.

    더 이상 애플리케이션에 액세스할 수 없습니다.

    Access Denied page

2.4.4. 다음 단계

다음과 같은 추가 작업을 수행할 수 있습니다.

  • 범위를 생성하고, 정책 및 권한을 정의하며, 애플리케이션 측에서 테스트합니다. 사용자가 작업을 수행할 수 있습니까?
  • 다양한 유형의 정책을 생성하고 이러한 정책을 기본 권한 과 연결합니다.
  • 기본 권한에 여러 정책을 적용하고 해당 동작을 테스트합니다. 예를 들어 여러 정책을 결합하고 그에 따라 결정 전략을 변경합니다.

2.5. 권한 부여 빠른 시작

이전 섹션에서 샘플 애플리케이션으로 사용되었던 app-authz-jee- van 대개 빠른 시작 외에도 Red Hat Single Sign-On Quickstarts Repository 에는 이 문서에 설명된 권한 부여 서비스를 사용하는 다른 애플리케이션이 포함되어 있습니다.

권한 부여 빠른 시작은 권한 부여 서비스가 다양한 시나리오와 다양한 기술 및 통합을 사용하도록 설계되었습니다. 권한 부여와 관련된 가능한 모든 사용 사례의 포괄적인 세트는 아니지만 권한 부여 서비스를 자체 애플리케이션에서 사용할 수 있는 방법을 이해하는 데 관심이 있는 사용자에게 시작점을 제공해야 합니다.

각 빠른 시작에는 샘플 애플리케이션을 빌드, 배포, 테스트하는 방법에 대한 지침이 포함된 README 파일이 있습니다. 다음 표에서는 사용 가능한 권한 부여 빠른 시작에 대한 간략한 설명을 제공합니다.

표 2.1. 권한 부여 빠른 시작
이름설명

app-authz-jee-servlet

특정 리소스를 보호하고 Red Hat Single Sign-On Server에서 얻은 권한에 따라 동적 메뉴를 구축하기 위해 Jakarta EE 애플리케이션에 대한 권한을 세분화하는 방법을 설명합니다.

app-authz-jee-vanilla

Jakarta EE 애플리케이션에 대한 세분화된 권한 부여를 활성화하고 기본 권한 설정을 사용하여 애플리케이션의 모든 리소스를 보호하는 방법을 보여줍니다.

app-authz-rest-springboot

Red Hat Single Sign-On 인증 서비스를 사용하여 SpringBoot REST 서비스를 보호하는 방법을 시연합니다.

app-authz-springboot

인증 및 권한 부여 측면이 Red Hat Single Sign-On에서 관리하는 SpringBoot 웹 애플리케이션을 작성하는 방법을 설명합니다.

app-authz-uma-photoz

HTML5+AngularJS+JAX-RS 기반의 간단한 애플리케이션으로, 애플리케이션에 대한 사용자 관리 액세스를 활성화하고 사용자가 리소스에 대한 권한을 관리하는 방법을 보여줍니다.

3장. 리소스 서버 관리

OAuth2 사양에 따라 리소스 서버는 보호된 리소스를 호스팅하는 서버이며 보호된 리소스 요청을 수락하고 응답할 수 있는 서버입니다.

Red Hat Single Sign-On에서는 리소스 서버에 다양한 액세스 제어 메커니즘을 기반으로 권한 결정을 내릴 수 있는 보호 리소스에 대한 세분화된 권한을 제공할 수 있는 풍부한 플랫폼이 제공됩니다.

세분화된 권한을 지원하도록 모든 클라이언트 애플리케이션을 구성할 수 있습니다. 이렇게 하면 개념적으로 클라이언트 애플리케이션을 리소스 서버로 전환하고 있습니다.

3.1. 클라이언트 애플리케이션 생성

Red Hat Single Sign-On 인증 서비스를 활성화하기 위한 첫 번째 단계는 리소스 서버로 전환할 클라이언트 애플리케이션을 생성하는 것입니다.

절차

  1. 클라이언트를 클릭합니다.

    클라이언트

    Clients

  2. 이 페이지에서 Create 를 클릭합니다.

    클라이언트 추가

    Add Client

  3. 클라이언트의 클라이언트 ID 를 입력합니다. 예를 들면 my-resource-server 입니다.
  4. 애플리케이션의 루트 URL 을 입력합니다. 예를 들면 다음과 같습니다.

    http://${host}:${port}/my-resource-server
    Copy to Clipboard
  5. 저장을 클릭합니다. 클라이언트가 생성되고 클라이언트 설정 페이지가 열립니다. 다음과 유사한 페이지가 표시됩니다.

    클라이언트 설정

    Client Settings

3.2. 권한 부여 서비스 활성화

OIDC Client Application을 리소스 서버로 전환하고 권한을 세부적으로 부여하려면 액세스 유형 기밀 을 선택하고 Authorization Enabled 스위치를 ON 으로 클릭한 다음 저장 을 클릭합니다.

권한 부여 서비스 활성화

Enabling authorization services

이 클라이언트에 대한 새 권한 부여 탭이 표시됩니다. Authorization 탭을 클릭하면 다음과 유사한 페이지가 표시됩니다.

리소스 서버 설정

Resource server settings

Authorization 탭에는 애플리케이션 리소스를 실제로 보호하기 위해 따라야 하는 다양한 단계를 다루는 추가 하위 탭이 포함되어 있습니다. 각 탭에는 이 문서의 특정 주제에서 별도로 다룹니다. 각각에 대한 간략한 설명은 다음과 같습니다.

  • 설정

    리소스 서버의 일반 설정입니다. 이 페이지에 대한 자세한 내용은 리소스 서버 설정 섹션을 참조하십시오.

  • 리소스

    이 페이지에서 애플리케이션의 리소스를 관리할 수 있습니다.

  • 권한 부여 범위

    이 페이지에서 범위를 관리할 수 있습니다.

  • Policies

    이 페이지에서 권한 부여 정책을 관리하고 권한 을 부여하기 위해 충족해야 하는 조건을 정의할 수 있습니다.

  • 권한

    이 페이지에서 생성한 정책과 연결하여 보호되는 리소스 및 범위에 대한 권한 을 관리할 수 있습니다.

  • 평가

    이 페이지에서 권한 부여 요청을 시뮬레이션 하고 정의한 권한 및 권한 부여 정책 평가 결과를 볼 수 있습니다.

  • 내보내기 설정

    이 페이지에서 권한 부여 설정을 JSON 파일로 내보낼 수 있습니다.

3.2.1. 리소스 서버 설정

리소스 서버 설정 페이지에서 정책 적용 모드를 구성하고, 원격 리소스 관리를 허용하고, 권한 부여 구성 설정을 내보낼 수 있습니다.

  • 정책 적용 모드

    서버에 전송된 권한 부여 요청을 처리할 때 정책을 적용하는 방법을 지정합니다.

    • enforcing

      (기본 모드) 지정된 리소스와 연결된 정책이 없는 경우에도 기본적으로 요청이 거부됩니다.

    • Permissive

      지정된 리소스와 연결된 정책이 없는 경우에도 요청이 허용됩니다.

    • disabled

      모든 정책의 평가를 비활성화하고 모든 리소스에 대한 액세스를 허용합니다.

  • 결정 전략

    이 구성에서는 정책 평가 엔진에서 모든 평가 권한의 결과에 따라 리소스 또는 범위를 부여할지 여부를 결정하는 방법을 변경합니다. 확인란 하나 이상의 권한이 리소스 및 해당 범위에 대한 액세스 권한을 부여하기 위해 양수 결정을 평가해야 함을 의미합니다. 모든 권한이 긍정적인 결정을 내리기 위해서는 모든 권한이 긍정적인 결정으로 평가되어야 한다는 것을 의미합니다. 예를 들어 동일한 리소스 또는 범위에 대한 두 개의 권한이 충돌하는 경우 (그 중 하나는 액세스를 부여하고 다른 하나는 액세스를 거부하고 다른 하나는 선택 전략이 동의한 경우 리소스 또는 범위에 대한 권한이 부여됩니다. 그렇지 않으면 모든 권한에서 하나의 거부도 리소스 또는 범위에 대한 액세스를 거부합니다.

  • 원격 리소스 관리

    리소스 서버에서 원격으로 리소스를 관리할 수 있는지 여부를 지정합니다. false인 경우 관리 콘솔에서만 리소스를 관리할 수 있습니다.

3.3. 기본 설정

리소스 서버를 생성할 때 Red Hat Single Sign-On은 새로 생성된 리소스 서버에 대한 기본 구성을 생성합니다.

기본 구성은 다음과 같습니다.

  • 애플리케이션의 모든 리소스를 나타내는 기본 보호 리소스입니다.
  • 이 정책으로 보호되는 리소스에 항상 액세스 권한을 부여하는 정책입니다.
  • 기본 정책을 기반으로 모든 리소스에 대한 액세스를 관리하는 권한입니다.

기본 보호 리소스는 기본 리소스라고 하며 리소스 탭으로 이동할 때 이를 볼 수 있습니다.

기본 리소스

Default resource

이 리소스는 유형, 즉 urn:my-resource-server:resources:defaultURI /* 를 정의합니다. URI 필드는 이 리소스가 애플리케이션의 모든 경로를 나타내는 Red Hat Single Sign-On에 표시되는 와일드카드 패턴을 정의합니다. 즉, 애플리케이션에 대한 정책 적용을 활성화하면 액세스 권한을 부여하기 전에 리소스와 관련된 모든 권한을 검사합니다.

이전에 언급한 Type 은 동일한 유형을 사용하여 기본 리소스 또는 기타 리소스에 적용해야 하는 형식의 리소스 권한 을 생성하는 데 사용할 수 있는 값을 정의합니다.

기본 정책은 영역 정책에서만 참조되며 Policies 탭으로 이동하면 이를 볼 수 있습니다.

기본 정책

Default policy

이 정책은 이 정책으로 보호되는 리소스에 항상 액세스 권한을 부여하는 조건을 정의하는 JavaScript 기반 정책입니다. 이 정책을 클릭하면 다음과 같이 규칙을 정의하는 것을 확인할 수 있습니다.

// by default, grants any permission associated with this policy
$evaluation.grant();
Copy to Clipboard

마지막으로 기본 권한을 기본 권한 이라고 하며 Permissions 탭으로 이동하면 이를 볼 수 있습니다.

기본 권한

Default Permission

이 권한은 리소스 기반 권한 이며, 지정된 유형의 모든 리소스에 적용되는 하나 이상의 정책 세트를 정의합니다.

3.3.1. 기본 구성 변경

기본 리소스, 정책 또는 권한 정의를 제거하고 자체 생성하여 기본 구성을 변경할 수 있습니다.

기본 리소스는 /* 패턴을 사용하여 애플리케이션의 리소스 또는 경로에 매핑되는 URI 를 사용하여 생성됩니다. 자체 리소스, 권한 및 정책을 생성하기 전에 기본 구성이 자체 설정과 충돌하지 않는지 확인합니다.

참고

기본 구성은 애플리케이션의 모든 경로에 매핑되는 리소스를 정의합니다. 자체 리소스에 대한 권한을 쓰려는 경우 기본 리소스를 제거하거나 URIS 필드를 애플리케이션의 특정 경로로 변경해야 합니다. 그렇지 않으면 기본 리소스(기본적으로 항상 액세스 권한을 부여)와 연결된 정책은 Red Hat Single Sign-On을 통해 모든 보호 리소스에 대한 액세스 권한을 부여할 수 있습니다.

3.4. 권한 부여 구성 내보내기 및 가져오기

리소스 서버(또는 클라이언트)의 구성 설정을 내보내고 다운로드할 수 있습니다. 리소스 서버의 기존 구성 파일을 가져올 수도 있습니다. 구성 파일을 가져오고 내보내면 리소스 서버에 대한 초기 구성을 생성하거나 기존 구성을 업데이트하려는 경우에 유용합니다. 구성 파일에는 다음에 대한 정의가 포함되어 있습니다.

  • 보호되는 리소스 및 범위
  • Policies
  • 권한

3.4.1. 구성 파일 내보내기

절차

  1. 리소스 서버 설정 페이지로 이동합니다.
  2. 설정 내보내기 탭을 클릭합니다.
  3. 이 페이지에서 내보내기 를 클릭합니다.

    내보내기 설정

    Export Settings

구성 파일은 JSON 형식으로 내보내지고 텍스트 영역에 표시되며, 이 영역에서 복사하고 붙여넣을 수 있습니다. 또한 다운로드를 클릭하여 구성 파일을 다운로드하여 저장할 수도 있습니다.

3.4.2. 구성 파일 가져오기

리소스 서버의 구성 파일을 가져올 수 있습니다.

절차

  1. 리소스 서버 설정 페이지로 이동합니다.

    가져오기 설정

    Import Settings

  2. 파일 선택을 클릭하고 가져올 구성이 포함된 파일을 선택합니다.

4장. 리소스 및 범위 관리

리소스 관리는 간단하고 일반적입니다. 리소스 서버를 생성한 후 보호하려는 리소스 및 범위 생성을 시작할 수 있습니다. 리소스 및 권한 부여 범위 탭으로 이동하면 각각 리소스 및 범위를 관리할 수 있습니다.

4.1. 리소스 보기

리소스 페이지에 리소스 서버와 연결된 리소스 목록이 표시됩니다.

Resources

Resources

리소스 목록은 다음과 같이 보호되는 리소스에 대한 정보를 제공합니다.

  • 유형
  • URIS
  • 소유자
  • 해당하는 범위(있는 경우)
  • 관련 권한

이 목록에서 권한을 만들 리소스에 대한 권한 만들기를 클릭하여 권한 을 직접 생성할 수도 있습니다.

참고

리소스에 대한 권한을 만들기 전에 권한과 연결할 정책을 이미 정의해야 합니다.

4.2. 리소스 생성

리소스를 생성하는 것은 간단하고 일반적입니다. 가장 큰 문제는 생성하는 리소스의 세분성입니다. 즉, 하나 이상의 리소스 세트를 나타내기 위해 리소스를 생성할 수 있으며 이러한 리소스를 정의하는 방식이 권한을 관리하는 데 매우 중요합니다.

새 리소스를 생성하려면 리소스 목록의 오른쪽 상단에 있는 Create 를 클릭합니다.

리소스 추가

Add resource

Red Hat Single Sign-On에서 리소스는 다음과 같은 다양한 유형의 리소스에 공통적인 작은 정보 세트를 정의합니다.

  • 이름

    이 리소스를 설명하는 사람이 읽을 수 있고 고유한 문자열입니다.

  • 유형

    하나 이상의 리소스 집합의 유형을 고유하게 식별하는 문자열입니다. 유형은 다양한 리소스 인스턴스를 그룹화하는 데 사용되는 문자열입니다. 예를 들어 자동으로 생성된 기본 리소스의 기본 유형은 urn:resource-server-name:resources:default입니다.

  • URIS

    리소스의 위치/네이버를 제공하는 URI입니다. HTTP 리소스의 경우 URIS는 일반적으로 이러한 리소스를 제공하는 데 사용되는 상대 경로입니다.

  • scopes

    리소스와 연결할 하나 이상의 범위입니다.

4.2.1. 리소스 속성

리소스에는 관련 속성이 있을 수 있습니다. 이러한 속성은 리소스에 대한 추가 정보를 제공하고 리소스와 연결된 권한을 평가할 때 정책에 추가 정보를 제공하는 데 사용할 수 있습니다.

각 속성은 값이 하나 이상의 문자열 집합일 수 있는 키 및 값 쌍입니다. 각 값을 쉼표로 구분하여 속성에 대해 여러 값을 정의할 수 있습니다.

4.2.2. 입력한 리소스

리소스의 type 필드를 사용하여 다양한 리소스를 함께 그룹화할 수 있으므로 공통 권한 세트를 사용하여 보호할 수 있습니다.

4.2.3. 리소스 소유자

리소스에는 소유자도 있습니다. 기본적으로 리소스는 리소스 서버에서 소유합니다.

그러나 리소스는 사용자와 연결할 수도 있으므로 리소스 소유자를 기반으로 권한을 생성할 수도 있습니다. 예를 들어 리소스 소유자만 지정된 리소스를 삭제하거나 업데이트할 수 있습니다.

4.2.4. 원격으로 리소스 관리

또한 보호 API 를 통해 리소스 관리가 노출되어 리소스 서버가 리소스를 원격으로 관리할 수 있습니다.

Protection API를 사용하면 사용자가 소유한 리소스를 관리하기 위해 리소스 서버를 구현할 수 있습니다. 이 경우 사용자 ID를 지정하여 특정 사용자에 속하는 리소스를 구성할 수 있습니다.

참고

Red Hat Single Sign-On은 리소스 서버에 리소스에 대한 완전한 제어를 제공합니다. 나중에는 사용자가 자신의 리소스를 제어하고 권한 부여 요청을 승인하고, 특히 UMA 프로토콜을 사용할 때 권한을 관리하도록 허용할 수 있어야 합니다.

5장. 정책 관리

앞서 언급했듯이 정책은 오브젝트에 대한 액세스 권한을 부여하기 전에 충족해야 하는 조건을 정의합니다.

절차

  1. 정책 탭을 클릭하여 리소스 서버와 관련된 모든 정책을 확인합니다.

    Policies

    Policies

    이 탭에서는 이전에 생성된 정책 목록을 볼 수 있으며 정책을 생성 및 편집할 수 있습니다.

  2. 새 정책을 생성하려면 오른쪽 상단에 있는 Create policy item 목록에서 정책 유형을 선택합니다.

    각 정책 유형에 대한 자세한 내용은 이 섹션에 설명되어 있습니다.

5.1. 사용자 기반 정책

이 유형의 정책을 사용하여 하나 이상의 사용자 집합이 오브젝트에 액세스할 수 있는 권한에 대한 조건을 정의할 수 있습니다.

새 사용자 기반 정책을 만들려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 User 를 선택합니다.

사용자 정책 추가

Add User Policy

5.1.1. 설정

  • 이름

    정책을 식별하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 사용자

    이 정책에서 사용자에게 제공되는 액세스 권한을 지정합니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.2. 역할 기반 정책

이 유형의 정책을 사용하여 하나 이상의 역할 집합이 오브젝트에 액세스할 수 있는 권한에 대한 조건을 정의할 수 있습니다.

기본적으로 이 정책에 추가된 역할은 필요에 따라 지정되지 않으며 사용자에게 이러한 역할을 요청하는 사용자에게 액세스 권한이 부여된 경우 정책은 액세스 권한을 부여합니다. 그러나 특정 역할을 적용하려면 필요에 따라 특정 역할을 지정할 수 있습니다. 영역 또는 클라이언트 역할 여부에 관계없이 필요한 역할과 필수 역할을 결합할 수도 있습니다.

역할 정책은 오브젝트에 대한 액세스 권한을 부여하기 위해 특정 역할을 적용해야 하는 RBAC(역할 기반 액세스 제어)가 필요한 경우 유용할 수 있습니다. 예를 들어, 사용자가 사용자 리소스에 액세스하도록 클라이언트 애플리케이션(사용자를 대신하여)을 허용하는 데 동의해야 함을 강제 적용할 수 있습니다. Red Hat Single Sign-On 클라이언트 범위 매핑을 사용하여 동의 페이지를 활성화하거나 클라이언트가 Red Hat Single Sign-On 서버에서 액세스 토큰을 가져올 때 범위를 명시적으로 제공하도록 시행할 수 있습니다.

새 역할 기반 정책을 생성하려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 Role 을 선택합니다.

역할 정책 추가

Add Role Policy

5.2.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 영역 역할

    이 정책에서 허용되는 영역 역할을 지정합니다.

  • 클라이언트 역할

    이 정책에서 허용되는 클라이언트 역할을 지정합니다. 이 필드를 활성화하려면 먼저 클라이언트를 선택해야 합니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.2.2. 필요에 따라 역할 정의

역할 기반 정책을 생성할 때 Required 로 특정 역할을 지정할 수 있습니다. 이렇게 하면 권한을 요청하는 사용자에게 필요한 모든 역할이 부여된 경우에만 정책은 액세스 권한을 부여합니다. 영역 및 클라이언트 역할은 다음과 같이 구성할 수 있습니다.

필수 역할의 예

Example of a required role

필요에 따라 역할을 지정하려면 필요에 따라 구성할 역할의 Required 확인란을 선택합니다.

필수 역할은 정책이 여러 역할을 정의하는 경우 유용할 수 있지만, 해당 역할의 하위 집합만 필수입니다. 이 경우 realm 및 client 역할을 결합하여 애플리케이션에 대해 더욱 세분화된 RBAC(역할 기반 액세스 제어) 모델을 활성화할 수 있습니다. 예를 들어 클라이언트 고유의 정책을 사용할 수 있으며 해당 클라이언트와 연결된 특정 클라이언트 역할이 필요할 수 있습니다. 또는 액세스 권한을 특정 영역 역할의 존재에서만 적용할 수 있습니다. 동일한 정책 내에서 두 방법을 결합할 수도 있습니다.

5.3. JavaScript 기반 정책

주의

정책 구현에서 아래 예제와 같이 특성 기반 액세스 제어(ABAC)를 사용하는 경우 사용자가 보호되는 특성을 편집할 수 없고 해당 속성이 읽기 전용입니다. 위협 모델 완화 장에서 자세한 내용을 참조하십시오.

이 유형의 정책을 사용하여 JavaScript를 사용하여 권한에 대한 조건을 정의할 수 있습니다. Red Hat Single Sign-On에서 지원하는 규칙 기반 정책 유형 중 하나로, appvail API를 기반으로 모든 정책을 작성할 수 있는 유연성을 제공합니다.

새로운 JavaScript 기반 정책을 만들려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 JavaScript 를 선택합니다.

참고

기본적으로 JavaScript 정책을 서버에 업로드할 수 없습니다. JavaScript Provider 에 설명된 대로 JS 정책을 서버에 직접 배포하는 것을 선호해야 합니다.

5.3.1. 배포된 JAR 파일에서 JS 정책 생성

Red Hat Single Sign-On을 사용하면 서버에 스크립트를 배포하기 위해 JAR 파일을 배포할 수 있습니다. 자세한 내용은 JavaScript Provider를 참조하십시오.

스크립트가 배포되면 사용 가능한 정책 공급자 목록에서 배포한 스크립트를 선택할 수 있어야 합니다.

5.3.2. 예

5.3.2.1. 평가 컨텍스트에서 속성 확인

다음은 특성 기반 액세스 제어(ABAC)를 사용하여 실행 컨텍스트에서 얻은 특성을 기반으로 조건을 정의하는 JavaScript 기반 정책의 간단한 예입니다.

const context = $evaluation.getContext();
const contextAttributes = context.getAttributes();

if (contextAttributes.containsValue('kc.client.network.ip_address', '127.0.0.1')) {
    $evaluation.grant();
}
Copy to Clipboard
5.3.2.2. 현재 ID에서 속성 확인

다음은 특성 기반 액세스 제어(ABAC)를 사용하여 현재 ID와 연결된 특성을 기반으로 조건을 정의하는 JavaScript 기반 정책의 간단한 예입니다.

const context = $evaluation.getContext();
const identity = context.getIdentity();
const attributes = identity.getAttributes();
const email = attributes.getValue('email').asString(0);

if (email.endsWith('@keycloak.org')) {
    $evaluation.grant();
}
Copy to Clipboard

권한 부여 요청에 사용된 토큰에 정의된 모든 클레임에서 이러한 특성이 매핑되는 위치입니다.

5.3.2.3. 현재 ID에 부여된 역할 확인

정책에서 RBAC(역할 기반 액세스 제어)를 사용할 수도 있습니다. 아래 예제에서는 사용자에게 keycloak_user 영역 역할이 부여되었는지 확인합니다.

const context = $evaluation.getContext();
const identity = context.getIdentity();

if (identity.hasRealmRole('keycloak_user')) {
    $evaluation.grant();
}
Copy to Clipboard

또는 my- client -role 클라이언트 역할이 사용자에게 부여되었는지 확인할 수 있습니다. 여기서 my-client 는 클라이언트 애플리케이션의 클라이언트 ID입니다.

const context = $evaluation.getContext();
const identity = context.getIdentity();

if (identity.hasClientRole('my-client', 'my-client-role')) {
    $evaluation.grant();
}
Copy to Clipboard
5.3.2.4. 사용자에게 부여된 역할 확인

사용자에게 부여된 영역 역할을 확인하려면 다음을 수행하십시오.

const realm = $evaluation.getRealm();

if (realm.isUserInRealmRole('marta', 'role-a')) {
    $evaluation.grant();
}
Copy to Clipboard

사용자에게 부여된 클라이언트 역할의 경우:

const realm = $evaluation.getRealm();

if (realm.isUserInClientRole('marta', 'my-client', 'some-client-role')) {
    $evaluation.grant();
}
Copy to Clipboard
5.3.2.5. 그룹에 부여된 역할 확인

그룹에 부여된 영역 역할을 확인하려면 다음을 수행하십시오.

const realm = $evaluation.getRealm();

if (realm.isGroupInRole('/Group A/Group D', 'role-a')) {
    $evaluation.grant();
}
Copy to Clipboard
5.3.2.6. 리소스 서버에 임의의 클레임 푸시

권한을 적용하는 방법에 대한 추가 정보를 제공하기 위해 리소스 서버에 임의의 클레임을 푸시하려면 다음을 수행합니다.

const permission = $evaluation.getPermission();

// decide if permission should be granted

if (granted) {
    permission.addClaim('claim-a', 'claim-a');
    permission.addClaim('claim-a', 'claim-a1');
    permission.addClaim('claim-b', 'claim-b');
}
Copy to Clipboard
5.3.2.7. 그룹 멤버십 확인
const realm = $evaluation.getRealm();

if (realm.isUserInGroup('marta', '/Group A/Group B')) {
    $evaluation.grant();
}
Copy to Clipboard
5.3.2.8. 다른 액세스 제어 메커니즘 혼합

여러 액세스 제어 메커니즘의 조합을 사용할 수도 있습니다. 아래 예제에서는 역할(RBAC) 및 클레임/attribute(ABAC) 검사를 동일한 정책 내에서 사용하는 방법을 보여줍니다. 이 경우 사용자가 admin 역할로 부여되었는지 또는 keycloak.org 도메인의 이메일이 있는지 확인합니다.

const context = $evaluation.getContext();
const identity = context.getIdentity();
const attributes = identity.getAttributes();
const email = attributes.getValue('email').asString(0);

if (identity.hasRealmRole('admin') || email.endsWith('@keycloak.org')) {
    $evaluation.grant();
}
Copy to Clipboard
참고

자체 규칙을 작성할 때 $evaluation 오브젝트는 org.keycloak.authorization.policy.evaluation.Evaluation 을 구현하는 오브젝트임을 유의하십시오. 이 인터페이스에서 액세스할 수 있는 항목에 대한 자세한 내용은 API를 참조하십시오.

5.4. 시간 기반 정책

이 유형의 정책을 사용하여 권한에 대한 시간 조건을 정의할 수 있습니다.

새 시간 기반 정책을 만들려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 시간을 선택합니다.

시간 정책 추가

Add Time Policy

5.4.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 이전되지 않음

    액세스를 부여하지 않아야 하는 시간을 정의합니다. 현재 날짜/시간이 이 값보다 크거나 같은 경우에만 권한이 부여됩니다.

  • On 또는 이후 없음

    액세스를 부여하지 않아야 하는 시간을 정의합니다. 현재 날짜/시간이 이 값보다 작거나 같은 경우에만 권한이 부여됩니다.

  • 월의 일

    액세스해야 하는 월의 일을 정의합니다. 날짜 범위를 지정할 수도 있습니다. 이 경우 월의 현재 날짜가 지정된 두 값과 같거나 같은 경우에만 사용 권한이 부여됩니다.In this case, permission is granted only if the current day of the month is between or equal to the two values specified.

  • 액세스 권한을 부여해야 하는 달을 정의합니다. 또한 다양한 기간을 지정할 수 있습니다. 이 경우 현재 월이 지정된 두 값과 같거나 같은 경우에만 사용 권한이 부여됩니다.In this case, permission is granted only if the current month is between or equal to the two values specified.

  • 액세스 권한을 부여해야 하는 년을 정의합니다. 다양한 연도를 지정할 수도 있습니다. 이 경우 현재 연도가 지정된 두 값과 같거나 같은 경우에만 사용 권한이 부여됩니다.In this case, permission is granted only if the current year is between or equal to the two values specified.

  • hour

    액세스 권한을 부여해야 하는 시간을 정의합니다. 시간 범위를 지정할 수도 있습니다. 이 경우 현재 시간이 지정된 두 값과 같거나 같은 경우에만 사용 권한이 부여됩니다.

  • minute

    액세스 권한을 부여해야 하는 분을 정의합니다. 또한 분 범위를 지정할 수도 있습니다. 이 경우 현재 밀리초가 지정된 두 값 사이의 또는 같은 경우에만 사용 권한이 부여됩니다.In this case, permission is granted only if the current minute is between or equal to the two values specified.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

모든 조건이 충족되는 경우에만 액세스 권한이 부여됩니다. Red Hat Single Sign-On은 각 조건의 결과에 따라 AND 를 수행합니다.

5.5. 집계된 정책

앞에서 언급했듯이 Red Hat Single Sign-On을 사용하면 정책 집계라는 개념인 정책 정책을 빌드할 수 있습니다. 정책 집계를 사용하여 기존 정책을 재사용하여 더 복잡한 정책을 구축하고 권한 부여 요청 처리 중에 평가되는 정책에서 권한을 훨씬 더 분리할 수 있습니다.

새 집계된 정책을 생성하려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 집계 를 선택합니다.

집계된 정책 추가

Add aggregated policy

keycloak.org 도메인과 특정 범위의 IP 주소에서만 액세스할 수 있는 기밀성 리소스라는 리소스가 있다고 가정해 보겠습니다. 두 조건을 모두 사용하여 단일 정책을 생성할 수 있습니다. 그러나 이 정책의 도메인 부분을 재사용하여 원래 네트워크에 관계없이 작동하는 권한에 적용하려고 합니다.

도메인 및 네트워크 조건에 대해 별도의 정책을 생성하고 이 두 가지 정책의 조합에 따라 세 번째 정책을 생성할 수 있습니다. 집계된 정책을 사용하면 다른 정책을 자유롭게 결합한 다음 새 집계 정책을 원하는 모든 권한에 적용할 수 있습니다.

참고

집계된 정책을 생성할 때 정책 간에 순환 참조 또는 종속성을 도입하지 않는다는 점에 유의하십시오. 순환 종속성이 감지되면 정책을 생성하거나 업데이트할 수 없습니다.

5.5.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 귀하의 비즈니스 및 보안 요구 사항과 밀접하게 관련된 이름을 사용하는 것이 좋습니다. 따라서 더 쉽게 식별하고 무엇을 의미하는지 알 수 있습니다.

  • 설명

    이 정책에 대한 자세한 정보가 있는 문자열입니다.

  • 적용 정책

    집계된 정책과 연결할 하나 이상의 정책 세트를 정의합니다. 정책을 연결하려면 기존 정책을 선택하거나 생성할 정책 유형을 선택하여 새 정책을 생성할 수 있습니다.

  • 결정 전략

    이 권한에 대한 결정 전략입니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.5.2. 집계된 정책에 대한 결정 전략

집계된 정책을 생성할 때 각 정책의 결과에 따라 최종 결정을 결정하는 데 사용할 결정 전략을 정의할 수도 있습니다.

  • unanimous

    기본 전략이 제공되지 않는 경우 이 경우 모든 정책은 최종 결정에도 긍정적인 결정을 내릴 수 있어야 합니다.

  • 검증

    이 경우, 적어도 하나의 정책은 최종 결정에도 긍정적인 영향을 주기 위해 긍정적인 결정으로 평가되어야 합니다.

  • 조정

    이 경우 긍정 의사 결정 수가 음수 의사 결정 수보다 커야 합니다. 긍정적인 결정과 부정적인 결정의 수가 동일하면 최종 결정은 음수가 됩니다.

5.6. 클라이언트 기반 정책

이 유형의 정책을 사용하여 하나 이상의 클라이언트 집합이 오브젝트에 액세스할 수 있는 권한에 대한 조건을 정의할 수 있습니다.

새 클라이언트 기반 정책을 생성하려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 Client 를 선택합니다.

클라이언트 정책 추가

Add a Client Policy

5.6.1. 설정

  • 이름

    정책을 식별하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 클라이언트

    이 정책에서 어떤 클라이언트에 액세스 권한을 부여할지 지정합니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.7. 그룹 기반 정책

이 유형의 정책을 사용하여 하나 이상의 그룹(및 해당 계층 구조)이 오브젝트에 액세스할 수 있는 권한에 대한 조건을 정의할 수 있습니다.

새 그룹 기반 정책을 만들려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 그룹을 선택합니다.

그룹 정책 Add Group Policy

5.7.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • groups Claim

    그룹 이름 및/또는 경로를 보유하는 토큰의 클레임 이름을 지정합니다. 일반적으로 권한 부여 요청은 이전에 일부 사용자를 대신하여 작동하는 클라이언트에 이전에 발행된 ID 토큰 또는 액세스 토큰을 기반으로 처리됩니다. 정의된 경우 토큰에는 이 정책이 사용자가 속한 그룹을 가져올 위치의 클레임이 포함되어야 합니다. 정의되지 않은 경우 사용자 그룹이 영역 구성에서 가져옵니다.

  • 그룹

    권한을 평가할 때 이 정책에서 적용해야 하는 그룹을 선택할 수 있습니다. 그룹을 추가한 후 확인란의 확장을 통해 그룹 하위 항목에 대한 액세스를 확장할 수 있습니다. 표시되지 않는 경우 액세스 제한 사항은 선택한 그룹에만 적용됩니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.7.2. 하위 그룹에 대한 액세스 확장

기본적으로 이 정책에 그룹을 추가하면 액세스 제한 사항이 선택한 그룹의 멤버에만 적용됩니다.

경우에 따라 그룹 자체뿐만 아니라 계층의 하위 그룹에 대한 액세스를 허용해야 할 수도 있습니다. 추가된 모든 그룹의 경우, 하위 그룹에 대한 액세스 확장하기 위해 확인란을 확장할 수 있습니다.

하위 그룹에 대한 액세스 확장

Extending access to child groups

위의 예에서 정책은 IT 의 모든 사용자 멤버 또는 그 하위 멤버에게 액세스 권한을 부여합니다.

5.8. 클라이언트 범위 기반 정책

이 유형의 정책을 사용하여 하나 이상의 클라이언트 범위로 개체에 액세스할 수 있는 권한에 대한 조건을 정의할 수 있습니다.

기본적으로 이 정책에 추가된 클라이언트 범위는 필요에 따라 지정되지 않으며, 클라이언트에 이러한 클라이언트 범위가 부여된 경우 정책은 액세스 권한을 부여합니다. 그러나 특정 클라이언트 범위를 적용하려면 필요에 따라 특정 클라이언트 범위를 지정할 수 있습니다.

클라이언트 범위 기반 정책을 생성하려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 클라이언트 범위를 선택합니다.

클라이언트 범위 정책 추가

Add Client Scope Policy

5.8.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 클라이언트 범위

    이 정책에서 허용되는 클라이언트 범위를 지정합니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리입니다.

5.8.2. 필요에 따라 클라이언트 범위 정의

클라이언트 범위 기반 정책을 생성할 때 특정 클라이언트 범위를 Required 로 지정할 수 있습니다. 이렇게 하면 액세스를 요청하는 클라이언트에 필요한 모든 클라이언트 범위가 부여된 경우에만 정책은 액세스 권한을 부여합니다.

필수 클라이언트 범위의 예

Example of required client scope

필요에 따라 클라이언트 범위를 지정하려면 필요에 따라 구성하려는 클라이언트 범위의 필수 확인란을 선택합니다.

정책이 여러 클라이언트 범위를 정의하는 경우 필수 클라이언트 범위가 유용할 수 있지만 해당 항목의 하위 집합만 필수입니다.

5.9. regex 기반 정책

이 유형의 정책을 사용하여 권한에 대한 regex 조건을 정의할 수 있습니다.

새 regex 기반 정책을 만들려면 정책 목록의 오른쪽 상단에 있는 항목 목록에서 Regex 를 선택합니다.

Regex 정책 추가

Add Regex Policy

5.9.1. 설정

  • 이름

    정책을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 정책에 대한 세부 정보가 포함된 문자열입니다.

  • 대상 클레임

    토큰에서 대상 클레임의 이름을 지정합니다.

  • Regex Pattern

    regex 패턴을 지정합니다.

  • 논리

    다른 조건을 평가한 후에 적용할 이 정책의 논리 입니다.

5.10. 양수 및 음수 논리

정책은 양수 또는 음수 논리로 구성할 수 있습니다. 간단히 말해 이 옵션을 사용하여 정책 결과를 그대로 유지하거나 부정해야 하는지 여부를 정의할 수 있습니다.

예를 들어 특정 역할로 부여되지 않은 사용자에게만 액세스 권한이 부여되어야 하는 정책을 생성한다고 가정합니다. 이 경우 해당 역할을 사용하여 역할 기반 정책을 생성하고 Logic 필드를 Negative 로 설정할 수 있습니다. 기본 동작인 Positive 를 유지하면 정책 결과가 그대로 유지됩니다.

5.11. 정책 평가 API

JavaScript를 사용하여 규칙 기반 정책을 작성하는 경우 Red Hat Single Sign-On은 권한 부여 여부를 결정하는 데 유용한 정보를 제공하는 apps API를 제공합니다.

이 API는 다음과 같은 정보에 대한 액세스를 제공하는 몇 가지 인터페이스로 구성됩니다.

  • 요청된 리소스와 범위를 모두 나타내는 평가 중인 권한입니다.
  • 요청 중인 리소스와 관련된 속성
  • 런타임 환경 및 실행 컨텍스트와 관련된 기타 속성
  • 그룹 멤버십 및 역할과 같은 사용자에 대한 정보

기본 인터페이스는 org.keycloak.authorization.policy.evaluation.Evaluation 이며 다음 계약을 정의합니다.

public interface Evaluation {

    /**
     * Returns the {@link ResourcePermission} to be evaluated.
     *
     * @return the permission to be evaluated
     */
    ResourcePermission getPermission();

    /**
     * Returns the {@link EvaluationContext}. Which provides access to the whole evaluation runtime context.
     *
     * @return the evaluation context
     */
    EvaluationContext getContext();

    /**
     * Returns a {@link Realm} that can be used by policies to query information.
     *
     * @return a {@link Realm} instance
     */
    Realm getRealm();

    /**
     * Grants the requested permission to the caller.
     */
    void grant();

    /**
     * Denies the requested permission.
     */
    void deny();
}
Copy to Clipboard

권한 부여 요청을 처리할 때 Red Hat Single Sign-On은 정책을 평가하기 전에 skopeo 인스턴스를 생성합니다. 그런 다음 이 인스턴스는 각 정책에 전달되어 액세스가 GRANT 인지 DENY 인지 확인합니다.

정책은 iPXE 인스턴스에서 grant() 또는 deny() 메서드를 호출하여 이를 결정합니다. 기본적으로initiator 인스턴스의 상태는 거부됩니다. 즉, 정책에서 grant() 메서드를 명시적으로 호출하여 권한을 부여해야 하는 정책 평가 엔진에 나타내야 합니다.

추가 리소스

5.11.1. 평가 컨텍스트

평가 컨텍스트는 평가 중에 정책에 유용한 정보를 제공합니다.

public interface EvaluationContext {

    /**
     * Returns the {@link Identity} that represents an entity (person or non-person) to which the permissions must be granted, or not.
     *
     * @return the identity to which the permissions must be granted, or not
     */
    Identity getIdentity();

    /**
     * Returns all attributes within the current execution and runtime environment.
     *
     * @return the attributes within the current execution and runtime environment
     */
    Attributes getAttributes();
}
Copy to Clipboard

이 인터페이스에서 정책을 가져올 수 있습니다.

  • 인증된 ID
  • 실행 컨텍스트 및 런타임 환경에 대한 정보

ID 는 권한 부여 요청과 함께 전송된 OAuth2 액세스 토큰을 기반으로 빌드되며, 이 구성은 원래 토큰에서 추출한 모든 클레임에 액세스할 수 있습니다. 예를 들어 OAuth2 액세스 토큰에 사용자 정의 클레임을 포함하도록 프로토콜 매퍼 를 사용하는 경우 정책에서 이 클레임에 액세스하여 조건을 빌드하는 데 사용할 수도 있습니다.

또한 limitationsContext 를 사용하면 실행 및 런타임 환경과 관련된 속성에 액세스할 수 있습니다. 현재는 몇 가지 기본 제공 속성만 있습니다.

표 5.1. 실행 및 런타임 속성
이름설명유형

kc.time.date_time

현재 날짜 및 시간

문자열. MM/dd/yyyyyyy hh:mm:ss

kc.client.network.ip_address

클라이언트의 IPv4 주소

문자열

kc.client.network.host

클라이언트의 호스트 이름

문자열

kc.client.id

클라이언트 ID

문자열

kc.client.user_agent

'User-Agent' HTTP 헤더의 값

String[]

kc.realm.name

영역의 이름

문자열

6장. 권한 관리

권한은 보호되는 오브젝트와 액세스 허용 여부를 결정하기 위해 평가해야 하는 정책을 연결합니다.

보호하려는 리소스와 이러한 리소스를 보호하는 데 사용할 정책을 생성한 후 권한 관리를 시작할 수 있습니다. 권한을 관리하려면 리소스 서버를 편집할 때 권한 탭을 클릭합니다.

권한

Permissions

권한은 두 가지 주요 유형의 오브젝트를 보호하기 위해 생성할 수 있습니다.

  • Resources
  • scopes

권한을 생성하려면 권한 목록의 오른쪽 상단에 있는 항목 목록에서 생성할 권한 유형을 선택합니다. 다음 섹션에서는 이러한 두 가지 유형의 오브젝트를 자세히 설명합니다.

6.1. 리소스 기반 권한 생성

리소스 기반 권한은 하나 이상의 권한 부여 정책 세트를 사용하여 보호할 하나 이상의 리소스 세트를 정의합니다.

새 리소스 기반 권한을 생성하려면 권한 목록의 오른쪽 상단에 있는 항목 목록에서 리소스 기반 을 선택합니다.

리소스 권한 추가

Add Resource Permission

6.1.1. 설정

  • 이름

    권한을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 권한에 대한 세부 정보가 포함된 문자열입니다.

  • 리소스 유형에 적용

    지정된 형식의 모든 리소스에 권한이 적용되는지 여부를 지정합니다. 이 필드를 선택하면 보호할 리소스 유형을 입력하라는 메시지가 표시됩니다.

    • 리소스 유형

      보호할 리소스 유형을 정의합니다. 정의된 경우 이 권한은 해당 유형과 일치하는 모든 리소스에 대해 평가됩니다.

  • Resources

    보호할 하나 이상의 리소스 세트를 정의합니다.

  • 적용 정책

    권한과 연결할 하나 이상의 정책 세트를 정의합니다. 정책을 연결하려면 기존 정책을 선택하거나 생성할 정책 유형을 선택하여 새 정책을 생성할 수 있습니다.

  • 결정 전략

    이 권한에 대한 결정 전략 입니다.

6.1.2. 형식화된 리소스 권한

리소스 권한을 사용하여 지정된 유형으로 모든 리소스에 적용할 정책을 정의할 수도 있습니다. 이러한 형태의 리소스 기반 권한은 공통 액세스 요구 사항 및 제약 조건을 공유하는 리소스가 있는 경우 유용할 수 있습니다.

애플리케이션 내 리소스는 캡슐화된 데이터 또는 제공하는 기능에 따라 분류(또는 입력)될 수 있습니다. 예를 들어, 재무 애플리케이션은 각각 특정 고객에게 속하는 다양한 뱅킹 계정을 관리할 수 있습니다. 이러한 계정은 서로 다른 뱅킹 계정이지만, 뱅킹 조직에서 전역적으로 정의하는 공통의 보안 요구 사항과 제약 조건을 공유합니다. 형식화된 리소스 권한을 사용하면 다음과 같은 모든 뱅킹 계정에 적용할 공통 정책을 정의할 수 있습니다.

  • 소유자만 계정을 관리할 수 있습니다.
  • 소유자의 국가 및/또는 지역으로부터의 액세스만 허용
  • 특정 인증 방법 적용

입력한 리소스 권한을 생성하려면 새 리소스 기반 권한을 생성할 때 리소스 유형에 적용을 클릭합니다. 리소스 유형에 적용을 On 으로 설정하여 보호할 유형 과 지정한 유형의 모든 리소스에 대한 액세스를 제어하기 위해 적용할 정책을 지정할 수 있습니다.

형식화된 리소스 권한의 예

Example of a typed resource permission

6.2. 범위 기반 권한 생성

범위 기반 권한은 하나 이상의 권한 부여 정책 집합을 사용하여 보호할 하나 이상의 범위 집합을 정의합니다. 리소스 기반 권한과 달리 이 권한 유형을 사용하여 리소스뿐만 아니라 리소스 관련 범위에 대한 권한을 생성할 수 있으며, 리소스를 관리하는 권한과 수행할 수 있는 작업을 정의할 때 보다 세분성을 제공할 수 있습니다.

새 범위 기반 권한을 만들려면 권한 목록의 오른쪽 상단에 있는 항목 목록에서 Scope-based 를 선택합니다.

범위 권한 추가

Add Scope Permission

6.2.1. 설정

  • 이름

    권한을 설명하는 사람이 읽을 수 있고 고유한 문자열입니다. 가장 좋은 방법은 비즈니스 및 보안 요구 사항과 밀접한 관련이 있는 이름을 사용하여 보다 쉽게 식별할 수 있도록 하는 것입니다.

  • 설명

    이 권한에 대한 세부 정보가 포함된 문자열입니다.

  • 리소스

    선택한 리소스와 연결된 범위를 제한합니다. 선택한 항목이 없으면 모든 범위를 사용할 수 있습니다.

  • scopes

    보호할 하나 이상의 범위 집합을 정의합니다.

  • 적용 정책

    권한과 연결할 하나 이상의 정책 세트를 정의합니다. 정책을 연결하려면 기존 정책을 선택하거나 생성할 정책 유형을 선택하여 새 정책을 생성할 수 있습니다.

  • 결정 전략

    이 권한에 대한 결정 전략 입니다.

6.3. 정책 결정 전략

정책과 권한을 연결하는 경우 의사 결정 전략을 정의하여 액세스를 결정하는 관련 정책의 결과를 평가하는 방법을 지정할 수도 있습니다.

  • unanimous

    기본 전략이 제공되지 않는 경우 이 경우 모든 정책은 최종 결정에도 긍정적인 결정을 내릴 수 있어야 합니다.

  • 검증

    이 경우 적어도 하나의 정책은 최종 결정에도 긍정적인 결정을 내릴 수 있어야 합니다.

  • 조정

    이 경우 긍정 의사 결정 수가 음수 의사 결정 수보다 커야 합니다. 양수 및 음수 의사 결정 수가 동일하면 최종 결정은 음수가 됩니다.

7장. 정책 평가 및 테스트

정책을 설계할 때 권한 부여 요청을 시뮬레이션하여 정책 평가 방법을 테스트할 수 있습니다.

리소스 서버를 편집할 때 Evaluate 탭을 클릭하여 Policy>-< Tool에 액세스할 수 있습니다. 여기에서 실제 권한 부여 요청을 시뮬레이션하고 정책의 영향을 테스트하기 위해 다양한 입력을 지정할 수 있습니다.

정책 평가 툴

Policy evaluation tool

7.1. ID 정보 제공

Identity Information 필터를 사용하여 권한을 요청하는 사용자를 지정할 수 있습니다.

7.2. 상황별 정보 제공

컨텍스트 정보 필터를 사용하여 평가 컨텍스트에 대한 추가 특성을 정의할 수 있으므로 정책이 동일한 특성을 얻을 수 있습니다.

7.3. 권한 제공

권한 필터를 사용하여 권한 부여 요청을 빌드할 수 있습니다. 하나 이상의 리소스 및 범위 집합에 대한 권한을 요청할 수 있습니다. 보호된 모든 리소스 및 범위를 기반으로 권한 부여 요청을 시뮬레이션하려면 리소스 또는 범위를 지정하지 않고 추가 클릭합니다.

원하는 값을 지정한 경우 Evaluate 를 클릭합니다.

8장. 권한 부여 서비스

Red Hat Single Sign-On 인증 서비스는 OAuth2 및 사용자 관리 액세스 사양과 같은 잘 알려진 표준을 기반으로 합니다.

OAuth2 클라이언트(예: 프런트 엔드 애플리케이션)는 토큰 끝점을 사용하여 서버에서 액세스 토큰을 가져오고 동일한 토큰을 사용하여 리소스 서버(예: 백엔드 서비스)로 보호된 리소스에 액세스할 수 있습니다. 마찬가지로 Red Hat Single Sign-On Authorization Services는 OAuth2의 확장을 제공하여 요청되는 리소스 또는 범위와 관련된 모든 정책의 처리에 따라 액세스 토큰을 발행할 수 있도록 합니다. 즉, 리소스 서버는 서버에서 부여하고 액세스 토큰에 의해 보유되는 권한에 따라 보호되는 리소스에 대한 액세스를 적용할 수 있습니다. Red Hat Single Sign-On Authorization Services에서 권한이 있는 액세스 토큰은 요청 당사자 토큰 또는 RPT라고 합니다.

Red Hat Single Sign-On Authorization Services는 RPT를 발행하는 것 외에도 리소스 서버가 보호되는 리소스, 범위, 권한 및 정책을 관리할 수 있는 RESTful 엔드포인트 세트를 제공하므로 개발자가 세분화된 권한 부여를 지원하기 위해 이러한 기능을 애플리케이션에 확장하거나 통합할 수 있습니다.

8.1. 권한 부여 서비스 엔드 포인트 및 메타데이터 검색

Red Hat Single Sign-On은 클라이언트가 엔드포인트 위치 및 기능을 포함하여 Red Hat Single Sign-On 인증 서비스와 상호 작용하는 데 필요한 모든 정보를 얻을 수 있는 검색 문서를 제공합니다.

검색 문서는 다음에서 얻을 수 있습니다.

curl -X GET \
  http://${host}:${port}/auth/realms/${realm}/.well-known/uma2-configuration
Copy to Clipboard

여기서 ${host}:${port} 는 호스트 이름(또는 IP 주소)과 Red Hat Single Sign-On이 실행 중인 포트이며 ${realm} 은 Red Hat Single Sign-On의 영역 이름입니다.

결과적으로 다음과 같이 응답을 받아야 합니다.

{

    // some claims are expected here

    // these are the main claims in the discovery document about Authorization Services endpoints location
    "token_endpoint": "http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token",
    "token_introspection_endpoint": "http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token/introspect",
    "resource_registration_endpoint": "http://${host}:${port}/auth/realms/${realm}/authz/protection/resource_set",
    "permission_endpoint": "http://${host}:${port}/auth/realms/${realm}/authz/protection/permission",
    "policy_endpoint": "http://${host}:${port}/auth/realms/${realm}/authz/protection/uma-policy"
}
Copy to Clipboard

이러한 각 끝점에서는 특정 기능 세트를 노출합니다.

  • token_endpoint

    urn:ietf:params:oauth:grant-type:uma-ticket 부여 유형을 지원하는 OAuth2 호환 토큰 엔드 포인트입니다. 이 끝점 클라이언트를 통해 권한 부여 요청을 보내고 Red Hat Single Sign-On에서 부여한 모든 권한이 있는 RPT를 받을 수 있습니다.

  • token_introspection_endpoint

    클라이언트가 RPT의 활성 상태를 확인하고 Red Hat Single Sign-On에서 부여한 권한과 같은 기타 모든 정보를 결정하는 데 사용할 수 있는 OAuth2 호환 토큰 인트로스펙션 엔드 포인트입니다.

  • resource_registration_endpoint

    리소스 서버가 보호되는 리소스 및 범위를 관리하는 데 사용할 수 있는 UMA 호환 리소스 등록 엔드 포인트입니다. 이 엔드포인트에서는 Red Hat Single Sign-On의 작업 생성, 읽기, 업데이트, 삭제 및 범위를 제공합니다.

  • permission_endpoint

    권한 서버에서 권한 티켓을 관리하는 데 사용할 수 있는 권한 끝점입니다. 이 엔드포인트에서는 Red Hat Single Sign-On의 작업 생성, 읽기, 업데이트 및 삭제 권한 티켓을 제공합니다.

8.2. 권한 가져오기

Red Hat Single Sign-On에서 권한을 얻으려면 토큰 끝점에 권한 부여 요청을 보냅니다. 결과적으로 Red Hat Single Sign-On은 요청되는 리소스와 범위와 관련된 모든 정책을 평가하고 서버가 부여한 모든 권한으로 RPT를 발행합니다.

클라이언트는 다음 매개변수를 사용하여 토큰 끝점에 권한 부여 요청을 보낼 수 있습니다.

  • grant_type

    이 매개변수는 필수입니다. urn:ietf:params:oauth:grant-type:uma-ticket 이어야 합니다.

  • 티켓

    이 매개변수는 선택 사항입니다. 클라이언트가 UMA 권한 부여 프로세스의 일부로 수신한 최신 권한 티켓입니다.

  • claim_token

    이 매개변수는 선택 사항입니다. 요청 중인 리소스 및 범위에 대한 권한을 평가할 때 서버에서 고려해야 하는 추가 클레임을 나타내는 문자열입니다. 이 매개변수를 사용하면 클라이언트가 Red Hat Single Sign-On에 클레임을 푸시할 수 있습니다. 지원되는 모든 토큰 형식에 대한 자세한 내용은 claim_token_format 매개변수를 참조하십시오.

  • claim_token_format

    이 매개변수는 선택 사항입니다. claim_token 매개변수에 지정된 토큰의 형식을 나타내는 문자열입니다. Red Hat Single Sign-On은 urn:ietf:params:oauth:token-type:jwthttps://openid.net/specs/openid-connect-core-1_0.html#IDToken 등 두 가지 토큰 형식을 지원합니다. urn:ietf:params:oauth:token-type:jwt 형식은 claim_token 매개변수가 액세스 토큰을 참조함을 나타냅니다. https://openid.net/specs/openid-connect-core-1_0.html#IDTokenclaim_token 매개변수가 OpenID Connect ID 토큰을 참조함을 나타냅니다.

  • rpt

    이 매개변수는 선택 사항입니다. 이전에 발행된 RPT는 새 권한도 평가하고 추가해야 하는 RPT입니다. 이 매개변수를 사용하면 클라이언트가 RPT를 보유하고 있는 클라이언트가 필요에 따라 권한이 추가되는 증분 승인을 수행할 수 있습니다.

  • 권한

    이 매개변수는 선택 사항입니다. 클라이언트가 액세스하려는 하나 이상의 리소스 및 범위를 나타내는 문자열입니다. 여러 리소스 및 범위에 대한 권한을 요청하기 위해 이 매개변수를 여러 번 정의할 수 있습니다. 이 매개변수는 클라이언트가 권한 티켓 없이 권한 요청을 보낼 수 있도록 urn:ietf:params:oauth:grant-type:uma-ticket 권한 부여 유형을 나타냅니다. 문자열 형식은 RESOURCE_ID#SCOPE_ID 여야 합니다. 예를 들어 리소스 A#Scope A,Resource A#Scope A, Scope B, Scope C,Resource A,#Scope A.

  • 대상

    이 매개변수는 선택 사항입니다. 클라이언트가 액세스하려는 리소스 서버의 클라이언트 식별자입니다. 권한 매개 변수가 정의된 경우 이 매개변수는 필수입니다. Red Hat Single Sign-On에 대한 힌트 역할을 하여 평가해야 하는 권한을 컨텍스트로 표시합니다.

  • response_include_resource_name

    이 매개변수는 선택 사항입니다. RPT 권한에 리소스 이름이 포함되어야 하는지 여부를 서버에 나타내는 부울 값입니다. false인 경우 리소스 식별자만 포함됩니다.

  • response_permissions_limit

    이 매개변수는 선택 사항입니다. RPT에 있을 수 있는 권한 수에 대한 제한을 정의하는 정수 N입니다. rpt 매개변수와 함께 사용하면 마지막 N개의 요청된 권한만 RPT에 유지됩니다.

  • submit_request

    이 매개변수는 선택 사항입니다. 서버가 권한 티켓에서 참조하는 리소스 및 범위에 대한 권한 요청을 생성해야 하는지 여부를 나타내는 부울 값입니다. 이 매개변수는 UMA 권한 부여 프로세스의 일부로 티켓 매개변수와 함께 사용되는 경우에만 적용됩니다.

  • response_mode

    이 매개변수는 선택 사항입니다. 서버가 권한 부여 요청에 응답하는 방법을 나타내는 문자열 값입니다. 이 매개변수는 표준 OAuth2 응답이 아니라 서버에서 부여한 전체 결정 또는 권한에 주로 관심이 있을 때 특히 유용합니다. 가능한 값은 다음과 같습니다.

    • 결정

      서버의 응답은 다음 형식으로 JSON을 반환하여 전체 결정만 나타내야 함을 나타냅니다.

      {
          'result': true
      }
      Copy to Clipboard

      권한 부여 요청이 권한에 매핑되지 않으면 403 HTTP 상태 코드가 대신 반환됩니다.

    • 권한

      서버의 응답에 다음 형식의 JSON을 반환하여 서버에서 부여하는 권한이 포함되어 있어야 함을 나타냅니다.

      [
          {
              'rsid': 'My Resource'
              'scopes': ['view', 'update']
          },
      
          ...
      ]
      Copy to Clipboard

      권한 부여 요청이 권한에 매핑되지 않으면 403 HTTP 상태 코드가 대신 반환됩니다.

클라이언트가 리소스 서버에서 보호되는 두 리소스에 액세스할 때 권한 부여 요청의 예.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "audience={resource_server_client_id}" \
  --data "permission=Resource A#Scope A" \
  --data "permission=Resource B#Scope B"
Copy to Clipboard

클라이언트가 리소스에 액세스하고 리소스 서버에서 보호하는 권한 부여 요청의 예.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "audience={resource_server_client_id}"
Copy to Clipboard

권한 부여 프로세스의 일부로 리소스 서버에서 권한 티켓을 수신한 후 클라이언트가 UMA 보호 리소스에 액세스할 때 권한 부여 요청의 예는 다음과 같습니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "ticket=${permission_ticket}
Copy to Clipboard

Red Hat Single Sign-On 평가 프로세스에서 사용 권한 발급을 초래하는 경우 권한이 연결된 RPT를 발행합니다.

Red Hat Single Sign-On은 RPT로 클라이언트에 응답

HTTP/1.1 200 OK
Content-Type: application/json
...
{
    "access_token": "${rpt}",
}
Copy to Clipboard

서버의 응답은 다른 권한 부여 유형을 사용하는 경우 토큰 끝점의 다른 응답과 동일합니다. RPT는 access_token 응답 매개변수에서 얻을 수 있습니다. 클라이언트 권한이 없는 경우 Red Hat Single Sign-On은 403 HTTP 상태 코드로 응답합니다.

Red Hat Single Sign-On은 권한 부여 요청을 거부합니다.

HTTP/1.1 403 Forbidden
Content-Type: application/json
...
{
    "error": "access_denied",
    "error_description": "request_denied"
}
Copy to Clipboard

8.2.1. 클라이언트 인증 방법

클라이언트는 RPT를 얻으려면 토큰 끝점에 인증해야 합니다. urn:ietf:params:oauth:grant-type:uma-ticket 권한 유형을 사용하는 경우 클라이언트는 다음 인증 방법 중 하나를 사용할 수 있습니다.

  • 전달자 토큰

    클라이언트는 HTTP 인증 헤더의 전달자 자격 증명으로 액세스 토큰을 토큰 끝점에 보내야 합니다.

    예: 토큰 끝점에 인증하기 위해 액세스 토큰을 사용한 권한 부여 요청

    curl -X POST \
      http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
      -H "Authorization: Bearer ${access_token}" \
      --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
    Copy to Clipboard

    이 방법은 클라이언트가 사용자를 대신하여 작동하는 경우 특히 유용합니다. 이 경우 전달자 토큰은 이전에 Red Hat Single Sign-On에서 사용자를 대신하여 작동하는 일부 클라이언트(또는 자체 대신)에 의해 발행된 액세스 토큰입니다. 권한은 액세스 토큰으로 표시되는 액세스 컨텍스트를 고려하여 평가됩니다. 예를 들어 사용자 A를 대신하여 액세스 토큰을 클라이언트 A에 발행한 경우 User A에 액세스할 수 있는 리소스 및 범위에 따라 권한이 부여됩니다.

  • 클라이언트 인증 정보

    클라이언트는 Red Hat Single Sign-On에서 지원하는 모든 클라이언트 인증 방법을 사용할 수 있습니다. 예를 들면 client_id/client_secret 또는 JWT입니다.

    예: 토큰 끝점에 인증하기 위해 클라이언트 ID 및 클라이언트 시크릿을 사용한 권한 부여 요청

    curl -X POST \
      http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
      -H "Authorization: Basic cGhvdGg6L7Jl13RmfWgtkk==pOnNlY3JldA==" \
      --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
    Copy to Clipboard

8.2.2. 클레임 푸시

서버에서 권한을 얻는 경우 권한을 평가할 때 이러한 클레임을 정책에 사용할 수 있도록 임의의 클레임을 푸시할 수 있습니다.

권한 티켓(UMA flow)을 사용하지 않고 서버에서 권한을 얻는 경우 다음과 같이 권한 부여 요청을 토큰 끝점으로 보낼 수 있습니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "claim_token=ewogICAib3JnYW5pemF0aW9uIjogWyJhY21lIl0KfQ==" \
  --data "claim_token_format=urn:ietf:params:oauth:token-type:jwt" \
  --data "client_id={resource_server_client_id}" \
  --data "client_secret={resource_server_client_secret}" \
  --data "audience={resource_server_client_id}"
Copy to Clipboard

claim_token 매개변수에는 아래 예제와 유사한 형식의 BASE64 인코딩 JSON이 필요합니다.

{
    "organization" : ["acme"]
}
Copy to Clipboard

형식은 각 클레임의 값이 문자열 배열이어야 하는 클레임을 하나 이상 예상합니다.

8.2.2.1. UMA를 사용하여 클레임 푸시

UMA 및 권한 티켓을 사용할 때 클레임을 푸시하는 방법에 대한 자세한 내용은 Permission API를 참조하십시오.

8.3. 사용자가 관리하는 액세스

Red Hat Single Sign-On 권한 부여 서비스는 사용자 관리 액세스 또는 UMA를 기반으로 합니다. UMA는 다음과 같은 방법으로 OAuth2 기능을 개선하는 사양입니다.

  • 개인 정보

    현재 사용자 개인 정보 보호는 점점 더 많은 데이터와 장치가 클라우드에 연결되어 있으므로 우려가 증가하고 있습니다. UMA 및 Red Hat Single Sign-On을 사용하면 리소스 서버에서 사용자가 정의한 정책에 따라 권한이 부여되는 사용자 개인 정보와 관련하여 리소스가 보호되는 방식을 개선하기 위해 기능을 향상시킬 수 있습니다.

  • party-to-party 권한 부여

    리소스 소유자(예: 일반 최종 사용자)는 리소스에 대한 액세스를 관리하고 다른 당사자(예: 일반 최종 사용자)가 이러한 리소스에 액세스할 수 있도록 권한을 부여할 수 있습니다. 이는 사용자를 대신하여 클라이언트 애플리케이션에 대한 동의가 제공되는 OAuth2와는 달리 UMA 리소스 소유자가 완전히 비동기식으로 다른 사용자에 대한 액세스에 동의할 수 있습니다.

  • 리소스 공유

    리소스 소유자는 리소스에 대한 권한을 관리하고 특정 리소스에 액세스할 수 있는 사용자와 방법을 결정할 수 있습니다. 그런 다음 Red Hat Single Sign-On은 리소스 소유자가 리소스를 관리할 수 있는 공유 관리 서비스로 작동할 수 있습니다.

Red Hat Single Sign-On은 대부분의 UMA 기능을 제공하는 UMA 2.0 호환 인증 서버입니다.

예를 들어,슬롯 계정(리소스 계정)을 관리하기 위해 인터넷Banking Service(리소스 서버)를 사용하는 사용자 Alice(리소스 소유자)를 고려해 보십시오. 1일, lice는 회계전문인 (requesting party)에 자신의 금지 계정을 개설하기로 결정합니다. 그러나 iPXE는 Alice의 계정 보기(범위)만 액세스할 수 있어야 합니다.

리소스 서버로서, 인터넷Banking Service는 브라이트코브 계정을 보호할 수 있어야 합니다. 이를 위해 Red Hat Single Sign-On 리소스 등록 끝점을 사용하여 Alice의 hugepages 계정을 나타내는 서버에서 리소스를 생성합니다.

현재 iPXE가 Alice의Bank 계정에 액세스하려고 하면 액세스가 거부됩니다. 인터넷Banking Service는 뱅킹 계정에 대한 몇 가지 기본 정책을 정의합니다. 그 중 하나는 소유자 (이 경우 Alice) 만 자신의랜서에 액세스 할 수 있다는 것입니다.

그러나 Alice의 개인 정보와 관련된 인터넷Banking Service를 사용하면 뱅킹 계정에 대한 특정 정책도 변경할 수 있습니다. 자신이 변경할 수 있는 정책 중 하나는 어떤 사람이 자신의 결제 계정을 볼 수 있는지 정의하는 것입니다. 이를 위해 인터넷Banking Service는 Red Hat Single Sign-On을 사용하여 Alice에게 액세스할 수 있는 개인과 데이터(또는 데이터)를 선택할 수 있는 공간을 제공합니다. 언제든지 Alice는 액세스 권한을 취소하거나 iPXE에 추가 권한을 부여할 수 있습니다.

8.3.1. 권한 부여 프로세스

UMA에서 권한 부여 프로세스는 클라이언트가 UMA 보호 리소스 서버에 액세스하려고 할 때 시작됩니다.

UMA 보호 리소스 서버에는 토큰이 RPT인 요청에 전달자 토큰이 필요합니다. 클라이언트가 RPT 없이 리소스 서버에서 리소스를 요청하는 경우:

클라이언트가 RPT를 전송하지 않고 보호되는 리소스를 요청합니다.

curl -X GET \
  http://${host}:${port}/my-resource-server/resource/1bfdfe78-a4e1-4c2d-b142-fc92b75b986f
Copy to Clipboard

리소스 서버는 권한 티켓이 있는 클라이언트에 다시 Red Hat Single Sign-On 서버의 위치와 함께 RPT를 받기 위해 티켓을 보내야 하는 위치로 as_uri 매개 변수를 보냅니다.

리소스 서버는 권한 티켓으로 응답

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="${realm}",
    as_uri="https://${host}:${port}/auth/realms/${realm}",
    ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
Copy to Clipboard

권한 티켓은 Red Hat Single Sign-On Permission API에서 발행한 특수한 유형의 토큰입니다. 요청되는 권한(예: 리소스 및 범위)은 요청과 관련된 기타 정보를 나타냅니다. 리소스 서버만 해당 토큰을 생성할 수 있습니다.

클라이언트에 권한 티켓과 Red Hat Single Sign-On 서버의 위치도 있으므로 클라이언트는 검색 문서를 사용하여 토큰 끝점의 위치를 가져와 권한 부여 요청을 보낼 수 있습니다.

클라이언트는 RPT를 얻기 위해 토큰 끝점에 권한 부여 요청을 보냅니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "ticket=${permission_ticket}
Copy to Clipboard

Red Hat Single Sign-On 평가 프로세스에서 사용 권한 발급을 초래하는 경우 권한이 연결된 RPT를 발행합니다.

Red Hat Single Sign-On은 RPT로 클라이언트에 응답

HTTP/1.1 200 OK
Content-Type: application/json
...
{
    "access_token": "${rpt}",
}
Copy to Clipboard

서버의 응답은 다른 권한 부여 유형을 사용하는 경우 토큰 끝점의 다른 응답과 동일합니다. RPT는 access_token 응답 매개변수에서 얻을 수 있습니다. 클라이언트의 권한이 없는 경우 Red Hat Single Sign-On은 403 HTTP 상태 코드로 응답합니다.

Red Hat Single Sign-On은 권한 부여 요청을 거부합니다.

HTTP/1.1 403 Forbidden
Content-Type: application/json
...
{
    "error": "access_denied",
    "error_description": "request_denied"
}
Copy to Clipboard

8.3.2. 권한 요청 제출

권한 부여 프로세스의 일부로 클라이언트는 먼저 Red Hat Single Sign-On Token Endpoint에서 RPT와 교환하기 위해 UMA 보호 리소스 서버에서 권한 티켓을 받아야 합니다.

기본적으로 Red Hat Single Sign-On은 RPT로 클라이언트를 발행할 수 없는 경우 403 HTTP 상태 코드 및 request_denied 오류로 응답합니다.

Red Hat Single Sign-On은 권한 부여 요청을 거부합니다.

HTTP/1.1 403 Forbidden
Content-Type: application/json
...
{
    "error": "access_denied",
    "error_description": "request_denied"
}
Copy to Clipboard

이러한 응답은 Red Hat Single Sign-On이 권한 티켓에 표시된 권한으로 RPT를 발행할 수 없음을 의미합니다.

클라이언트 애플리케이션은 비동기 권한 부여 흐름을 시작하고 요청된 리소스의 소유자가 액세스 권한을 부여해야 하는지 여부를 결정하도록 할 수 있습니다. 이를 위해 클라이언트는 토큰 끝점에 대한 권한 부여 요청과 함께 submit_request 요청 매개변수를 사용할 수 있습니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "ticket=${permission_ticket} \
  --data "submit_request=true"
Copy to Clipboard

submit_request 매개변수를 사용하는 경우 Red Hat Single Sign-On은 액세스가 거부된 각 리소스에 대한 권한 요청을 유지합니다. 리소스 소유자가 생성되면 계정을 확인하고 권한 요청을 관리할 수 있습니다.

이 기능은 사용자가 다른 사용자에게 해당 리소스에 대한 액세스 권한을 요청할 수 있는 요청 액세스 버튼으로 생각할 수 있습니다.

8.3.3. 사용자 리소스에 대한 액세스 관리

사용자는 Red Hat Single Sign-On 사용자 계정 서비스를 사용하여 리소스에 대한 액세스를 관리할 수 있습니다. 이 기능을 활성화하려면 먼저 해당 영역에 대해 User-Managed Access를 활성화해야 합니다.

절차

  1. 관리 콘솔에 로그인합니다.
  2. 메뉴에서 CloudEvent Settings 을 클릭합니다.
  3. 사용자 관리 액세스ON 으로 전환합니다.

    My Resources

  4. 메뉴 옵션에서 My Resources 를 클릭합니다. 다음 옵션을 사용하여 페이지가 표시됩니다.

    • 승인이 필요한권한 요청 관리

      이 섹션에는 승인을 기다리는 모든 권한 요청 목록이 포함되어 있습니다. 이러한 요청은 특정 리소스에 대한 액세스를 요청하는 당사자(사용자)에 연결됩니다. 사용자는 이러한 요청을 승인하거나 거부할 수 있습니다.

    • 내 리소스관리

      이 섹션에는 사용자가 소유한 모든 리소스 목록이 포함되어 있습니다. 사용자는 보다 자세한 내용을 위해 리소스를 클릭하고 다른 사용자와 리소스를 공유할 수 있습니다.

    • 나와 공유되는 리소스관리

      이 섹션에는 사용자와 공유하는 모든 리소스 목록이 포함되어 있습니다.

    • 승인 대기 중인 요청관리

      이 섹션에는 다른 사용자 또는 리소스 소유자의 승인을 기다리는 사용자가 보낸 권한 요청 목록이 포함되어 있습니다.

변경할 특정 리소스를 클릭하면 다음 페이지가 표시됩니다.

Resource Detail

이 페이지에서는 다음 옵션을 제공합니다.

  • 이 리소스에 대한 액세스 권한이 있는 role관리

    이 섹션에는 이 리소스에 액세스할 수 있는 사용자 목록이 포함되어 있습니다. 사용자는 Revoke 버튼을 클릭하거나 특정 권한 을 제거하여 액세스를 취소할 수 있습니다.

  • 다른 사용자와 리소스 공유

    다른 사용자의 사용자 이름 또는 이메일을 입력하면 사용자가 리소스를 공유하고 액세스 권한을 부여하려는 권한을 선택할 수 있습니다.

8.4. 보호 API

Protection API는 다음 기능을 제공하는 UMA 호환 끝점 세트를 제공합니다.

  • 리소스 관리

    이 끝점을 사용하면 리소스 서버가 리소스를 원격으로 관리하고 정책 시행자가 서버를 보호해야 하는 리소스에 대해 쿼리할 수 있습니다.

  • 권한 관리

    UMA 프로토콜에서 리소스 서버는 이 끝점에 액세스하여 권한 티켓을 생성합니다. Red Hat Single Sign-On은 권한 상태 및 쿼리 권한을 관리하기 위한 엔드포인트도 제공합니다.

  • 정책 API

    Red Hat Single Sign-On은 UMA Protection API를 활용하여 리소스 서버가 사용자의 권한을 관리할 수 있도록 합니다. 리소스 및 권한 API 외에도 Red Hat Single Sign-On은 사용자 대신 리소스 서버에서 권한을 리소스로 설정할 수 있는 정책 API를 제공합니다.

이 API의 중요한 요구 사항은 리소스 서버 보호 API 토큰(PAT)이라는 특수 OAuth2 액세스 토큰을 사용하여 끝점에 액세스할 수 있다는 것입니다. UMA에서 PAT는 uma_protection 범위가 있는 토큰입니다.

8.4.1. PAT 란 무엇이며 어떻게 얻을 수 있습니까?

PAT( Protected API token)는 uma_protection 으로 정의된 범위가 있는 특수 OAuth2 액세스 토큰입니다. 리소스 서버를 생성할 때 Red Hat Single Sign-On은 해당 클라이언트 애플리케이션에 대한 역할 uma_protection 을 자동으로 생성하여 클라이언트의 서비스 계정과 연결합니다.

uma_protection 역할로 부여된 서비스 계정

Service Account granted with uma_protection role

리소스 서버는 다른 OAuth2 액세스 토큰과 마찬가지로 Red Hat Single Sign-On에서 PAT를 가져올 수 있습니다. 예를 들어 curl을 사용합니다.

curl -X POST \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d 'grant_type=client_credentials&client_id=${client_id}&client_secret=${client_secret}' \
    "http://localhost:8080/auth/realms/${realm_name}/protocol/openid-connect/token"
Copy to Clipboard

위의 예제에서는 client_credentials 부여 유형을 사용하여 서버에서 PAT를 가져오는 것입니다. 결과적으로 서버는 다음과 유사한 응답을 반환합니다.

{
  "access_token": ${PAT},
  "expires_in": 300,
  "refresh_expires_in": 1800,
  "refresh_token": ${refresh_token},
  "token_type": "bearer",
  "id_token": ${id_token},
  "not-before-policy": 0,
  "session_state": "ccea4a55-9aec-4024-b11c-44f6f168439e"
}
Copy to Clipboard
참고

Red Hat Single Sign-On은 다양한 방법으로 클라이언트 애플리케이션을 인증할 수 있습니다. 단순화를 위해 client_credentials 부여 유형은 여기에 사용됩니다. client_idclient_secret. 지원되는 인증 방법을 사용하도록 선택할 수 있습니다.

8.4.2. 리소스 관리

리소스 서버는 UMA 호환 엔드포인트를 사용하여 리소스를 원격으로 관리할 수 있습니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set
Copy to Clipboard

이 끝점은 다음과 같이 요약된 작업을 제공합니다(명확성을 위해 생략된 경로).

  • 리소스 세트 설명 생성: POST /resource_set
  • 읽기 리소스 세트 설명: GET /resource_set/{_id}
  • 리소스 세트 설명 업데이트: PUT /resource_set/{_id}
  • 리소스 세트 설명 삭제: DELETE /resource_set/{_id}
  • 리소스 세트 설명 나열: GET /resource_set

이러한 각 작업에 대한 자세한 내용은 UMA 리소스 등록 API 를 참조하십시오.

8.4.2.1. 리소스 생성

리소스를 생성하려면 다음과 같이 HTTP POST 요청을 보내야 합니다.

curl -v -X POST \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '{
     "name":"Tweedl Social Service",
     "type":"http://www.example.com/rsrcs/socialstream/140-compatible",
     "icon_uri":"http://www.example.com/icons/sharesocial.png",
     "resource_scopes":[
         "read-public",
         "post-updates",
         "read-private",
         "http://www.example.com/scopes/all"
      ]
  }'
Copy to Clipboard

기본적으로 리소스 소유자는 리소스 서버입니다. 특정 사용자와 같은 다른 소유자를 정의하려는 경우 다음과 같이 요청을 보낼 수 있습니다.

curl -v -X POST \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '{
     "name":"Alice Resource",
     "owner": "alice"
  }'
Copy to Clipboard

여기서 속성 소유자는 사용자의 사용자 이름 또는 식별자를 사용하여 설정할 수 있습니다.

8.4.2.2. 사용자 관리 리소스 생성

기본적으로 보호 API를 통해 생성된 리소스는 사용자 계정 서비스를 통해 리소스 소유자가 관리할 수 없습니다.

리소스를 생성하고 리소스 소유자가 이러한 리소스를 관리할 수 있도록 하려면 다음과 같이 ownerManagedAccess 속성을 설정해야 합니다.

curl -v -X POST \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '{
     "name":"Alice Resource",
     "owner": "alice",
     "ownerManagedAccess": true
  }'
Copy to Clipboard
8.4.2.3. 리소스 업데이트

기존 리소스를 업데이트하려면 다음과 같이 HTTP PUT 요청을 보냅니다.

curl -v -X PUT \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set/{resource_id} \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '{
     "_id": "Alice Resource",
     "name":"Alice Resource",
     "resource_scopes": [
        "read"
     ]
  }'
Copy to Clipboard
8.4.2.4. 리소스 삭제

기존 리소스를 삭제하려면 다음과 같이 HTTP DELETE 요청을 보냅니다.

curl -v -X DELETE \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set/{resource_id} \
  -H 'Authorization: Bearer '$pat
Copy to Clipboard
8.4.2.5. 리소스 쿼리

id 로 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set/{resource_id}
Copy to Clipboard

이름이 지정된 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?name=Alice Resource
Copy to Clipboard

기본적으로 이름 필터는 지정된 패턴과 모든 리소스와 일치합니다. 쿼리에서 정확히 일치하는 리소스만 반환하도록 제한하려면 다음을 사용합니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?name=Alice Resource&exactName=true
Copy to Clipboard

uri 가 지정된 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?uri=/api/alice
Copy to Clipboard

소유자가 제공한 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?owner=alice
Copy to Clipboard

유형이 지정된 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?type=albums
Copy to Clipboard

범위가 지정된 리소스를 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?scope=read
Copy to Clipboard

서버에 권한을 쿼리할 때 먼저 매개변수와 max 결과를 사용하여 결과를 제한합니다.

8.4.3. 권한 요청 관리

UMA 프로토콜을 사용하는 리소스 서버는 특정 끝점을 사용하여 권한 요청을 관리할 수 있습니다. 이 끝점은 권한 요청을 등록하고 권한 티켓을 받기 위한 UMA 준수 흐름을 제공합니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission
Copy to Clipboard

권한 티켓은 권한 요청을 나타내는 특수한 보안 토큰 유형입니다. UMA 사양에 따라 권한 티켓은 다음과 같습니다.

권한 부여 서버에서 리소스 서버로, 리소스 서버에서 클라이언트로 전달되고 궁극적으로 클라이언트로부터 권한 부여 서버로 전달되는 상관 관계 처리로 권한 부여 서버가 권한 부여 데이터 요청에 적용할 올바른 정책을 평가할 수 있도록 합니다.

대부분의 경우 이 엔드포인트를 직접 처리할 필요가 없습니다. Red Hat Single Sign-On은 리소스 서버에 대해 UMA를 사용하도록 지원하는 정책 시행기를 제공하여 권한 부여 서버에서 권한 티켓을 취득하고 이 티켓을 클라이언트 애플리케이션에 반환하며 최종 요청 당사자 토큰(RPT)에 따라 권한 결정을 시행할 수 있도록 합니다.

Red Hat Single Sign-On에서 권한 티켓을 얻는 프로세스는 일반 클라이언트 애플리케이션이 아닌 리소스 서버에서 수행합니다. 여기서 클라이언트가 리소스에 액세스할 수 있는 권한 부여 없이 보호 리소스에 액세스하려고 하면 권한 티켓을 받습니다. 권한 티켓 발행은 리소스 서버가 다음을 수행할 수 있도록 UMA를 사용할 때 중요한 요소입니다.

  • 리소스 서버에서 보호되는 리소스와 연결된 데이터를 클라이언트에서 추상화
  • 나중에 리소스 소유자의 동의에 따라 액세스 권한을 부여하기 위해 나중에 워크플로에서 사용할 수 있는 Red Hat Single Sign-On 권한 부여 요청에 등록하십시오.
  • 권한 부여 서버에서 리소스 서버를 분리하고 다른 권한 부여 서버를 사용하여 리소스를 보호하고 관리할 수 있도록 합니다.

고객이 안심할 수 있는 권한 티켓에는 다음과 같은 중요한 측면이 있습니다.

  • 클라이언트는 권한 부여 데이터가 보호되는 리소스와 어떻게 연관되는지에 대해 알 필요가 없습니다. 고객에게 권한 티켓은 완전히 불투명합니다.
  • 클라이언트는 다양한 리소스 서버의 리소스에 액세스하고 다른 권한 부여 서버로 보호할 수 있습니다.

이는 UMA에서 제공하는 몇 가지 이점으로, UMA의 다른 측면이 권한 티켓, 특히 개인 정보 보호 및 사용자가 자신의 리소스에 대한 액세스를 제어하는 것에 기반을 두고 있습니다.

8.4.3.1. 권한 티켓 생성

권한 티켓을 생성하려면 다음과 같이 HTTP POST 요청을 보냅니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '[
  {
    "resource_id": "{resource_id}",
    "resource_scopes": [
      "view"
    ]
  }
]'
Copy to Clipboard

티켓을 생성할 때 임의의 클레임을 푸시하고 이러한 클레임을 티켓과 연결할 수도 있습니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission \
  -H 'Authorization: Bearer '$pat \
  -H 'Content-Type: application/json' \
  -d '[
  {
    "resource_id": "{resource_id}",
    "resource_scopes": [
      "view"
    ],
    "claims": {
        "organization": ["acme"]
    }
  }
]'
Copy to Clipboard

권한 티켓과 관련된 리소스 및 범위에 대한 권한을 평가할 때 정책에 이러한 클레임을 사용할 수 있습니다.

8.4.3.2. 기타 UMA 호환 끝점
8.4.3.2.1. 권한 티켓 생성

리소스의 소유자가 다음과 같이 id {resource_id}인 특정 리소스에 대한 권한을 id {user_id}인 사용자에게 부여하려면 다음을 수행합니다.

curl -X POST \
     http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission/ticket \
     -H 'Authorization: Bearer '$access_token \
     -H 'Content-Type: application/json' \
     -d '{
       "resource": "{resource_id}",
       "requester": "{user_id}",
       "granted": true,
       "scopeName": "view"
     }'
Copy to Clipboard
8.4.3.2.2. 권한 티켓 받기
curl http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission/ticket \
     -H 'Authorization: Bearer '$access_token
Copy to Clipboard

다음 쿼리 매개변수 중 하나를 사용할 수 있습니다.

  • scopeId
  • resourceId
  • 소유자
  • requester
  • granted
  • returnNames
  • first
  • max
8.4.3.2.3. 권한 티켓 업데이트
curl -X PUT \
     http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission/ticket \
     -H 'Authorization: Bearer '$access_token \
     -H 'Content-Type: application/json' \
     -d '{
       "id": "{ticket_id}"
       "resource": "{resource_id}",
       "requester": "{user_id}",
       "granted": false,
       "scopeName": "view"
     }'
Copy to Clipboard
8.4.3.2.4. 권한 티켓 삭제
curl -X DELETE http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission/ticket/{ticket_id} \
     -H 'Authorization: Bearer '$access_token
Copy to Clipboard

8.4.4. 정책 API를 사용하여 리소스 권한 관리

Red Hat Single Sign-On은 UMA Protection API를 활용하여 리소스 서버가 사용자의 권한을 관리할 수 있도록 합니다. 리소스 및 권한 API 외에도 Red Hat Single Sign-On은 사용자 대신 리소스 서버에서 권한을 리소스로 설정할 수 있는 정책 API를 제공합니다.

Policy API는 다음에서 사용할 수 있습니다.

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/uma-policy/{resource_id}
Copy to Clipboard

이 API는 전달자 토큰에 의해 보호되며, 사용자가 대신하여 권한을 관리하기 위해 사용자가 부여한 동의를 리소스 서버에 표시해야 합니다. 전달자 토큰은 다음을 사용하여 토큰 끝점에서 얻은 일반 액세스 토큰일 수 있습니다.

  • 리소스 소유자 암호 자격 증명 부여 유형
  • 토큰 교환, 대상 사용자가 리소스 서버인 토큰에 대해 일부 클라이언트(공용 클라이언트)에 부여된 액세스 토큰을 교환합니다.
8.4.4.1. 리소스와 권한 연결

권한을 특정 리소스와 연결하려면 다음과 같이 HTTP POST 요청을 보내야 합니다.

curl -X POST \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{resource_id} \
  -H 'Authorization: Bearer '$access_token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Any people manager",
	"description": "Allow access to any people manager",
	"scopes": ["read"],
	"roles": ["people-manager"]
}'
Copy to Clipboard

위의 예에서는 resource_id 에 의해 표시되는 리소스에 새 권한을 만들고 연관시키고 있습니다. 여기서 people-manager 역할이 있는 모든 사용자에게 읽기 범위가 부여되어야 합니다.

그룹 사용과 같은 다른 액세스 제어 메커니즘을 사용하여 정책을 생성할 수도 있습니다.

curl -X POST \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{resource_id} \
  -H 'Authorization: Bearer '$access_token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Any people manager",
	"description": "Allow access to any people manager",
	"scopes": ["read"],
	"groups": ["/Managers/People Managers"]
}'
Copy to Clipboard

또는 특정 클라이언트:

curl -X POST \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{resource_id} \
  -H 'Authorization: Bearer '$access_token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Any people manager",
	"description": "Allow access to any people manager",
	"scopes": ["read"],
	"clients": ["my-client"]
}'
Copy to Clipboard

또는 JavaScript를 사용하여 사용자 지정 정책도 사용합니다.

참고

Upload Scripts는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 이 기능은 기본적으로 비활성화되어 있습니다.

-Dkeycloak.profile.feature.upload_scripts=enabled 로 서버를 시작하려면 다음을 수행하십시오. 자세한 내용은 프로필을 참조하십시오.

curl -X POST \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{resource_id} \
  -H 'Authorization: Bearer '$access_token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Any people manager",
	"description": "Allow access to any people manager",
	"scopes": ["read"],
	"condition": "my-deployed-script.js"
}'
Copy to Clipboard

이러한 액세스 제어 메커니즘의 임의의 조합을 설정할 수도 있습니다.

기존 권한을 업데이트하려면 HTTP PUT 요청을 다음과 같이 보냅니다.

curl -X PUT \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{permission_id} \
  -H 'Authorization: Bearer '$access_token \
  -H 'Content-Type: application/json' \
  -d '{
    "id": "21eb3fed-02d7-4b5a-9102-29f3f09b6de2",
    "name": "Any people manager",
    "description": "Allow access to any people manager",
    "type": "uma",
    "scopes": [
        "album:view"
    ],
    "logic": "POSITIVE",
    "decisionStrategy": "UNANIMOUS",
    "owner": "7e22131a-aa57-4f5f-b1db-6e82babcd322",
    "roles": [
        "user"
    ]
}'
Copy to Clipboard
8.4.4.2. 권한 제거

리소스와 관련된 권한을 제거하려면 다음과 같이 HTTP DELETE 요청을 보냅니다.

curl -X DELETE \
  http://localhost:8180/auth/realms/photoz/authz/protection/uma-policy/{permission_id} \
  -H 'Authorization: Bearer '$access_token
Copy to Clipboard
8.4.4.3. 권한 쿼리

리소스와 관련된 권한을 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm}/authz/protection/uma-policy?resource={resource_id}
Copy to Clipboard

이름이 지정된 권한을 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm}/authz/protection/uma-policy?name=Any people manager
Copy to Clipboard

특정 범위와 관련된 권한을 쿼리하려면 다음과 같이 HTTP GET 요청을 보냅니다.

http://${host}:${port}/auth/realms/${realm}/authz/protection/uma-policy?scope=read
Copy to Clipboard

모든 권한을 쿼리하려면 HTTP GET 요청을 다음과 같이 보냅니다.

http://${host}:${port}/auth/realms/${realm}/authz/protection/uma-policy
Copy to Clipboard

서버에 권한을 쿼리할 때 먼저 매개변수와 max 결과를 사용하여 결과를 제한합니다.

8.5. 당사자 토큰 요청

요청 당사자 토큰 (RPT)은 JSON 웹 서명 ( JWS)을 사용하여 디지털 서명 JSON 웹 토큰 (JWT ) 입니다. 토큰은 사용자를 대신하여 작동하는 특정 클라이언트에 대해 이전에 Red Hat Single Sign-On에서 발행한 OAuth2 액세스 토큰을 기반으로 빌드됩니다.

RPT를 디코딩하면 다음과 유사한 페이로드가 표시됩니다.

{
  "authorization": {
      "permissions": [
        {
          "resource_set_id": "d2fe9843-6462-4bfc-baba-b5787bb6e0e7",
          "resource_set_name": "Hello World Resource"
        }
      ]
  },
  "jti": "d6109a09-78fd-4998-bf89-95730dfd0892-1464906679405",
  "exp": 1464906971,
  "nbf": 0,
  "iat": 1464906671,
  "sub": "f1888f4d-5172-4359-be0c-af338505d86c",
  "typ": "kc_ett",
  "azp": "hello-world-authz-service"
}
Copy to Clipboard

이 토큰에서 서버에서 부여한 모든 권한을 권한 클레임에서 얻을 수 있습니다.

또한 권한은 실제로 동일한 권한을 부여하고 발급하는 데 사용된 액세스 제어 방법과 완전히 분리되는 리소스/범위와 직접 관련이 있습니다.

8.5.1. 요청 당사자 토큰 세부 검사

경우에 따라 요청 당사자 토큰(RPT)을 검사하여 유효성을 확인하거나 토큰 내 권한을 확보하여 리소스 서버 측에 권한 결정을 적용할 수 있습니다.

토큰 인트로스펙션이 도움이 될 수 있는 두 가지 주요 사용 사례가 있습니다.

  • 클라이언트 애플리케이션에서 토큰 유효성을 쿼리하여 동일하거나 추가 권한이 있는 새 권한을 확보해야 하는 경우
  • 리소스 서버 측에서 권한 결정을 적용하는 경우 특히 기본 제공 정책 적용자가 애플리케이션에 맞지 않는 경우

8.5.2. RPT에 대한 정보 얻기

토큰 인트로스펙션은 기본적으로 RPT에 대한 정보를 얻을 수 있는 OAuth2 토큰 인트로스펙션- 호환 끝점입니다.

http://${host}:${port}/auth/realms/${realm_name}/protocol/openid-connect/token/introspect
Copy to Clipboard

이 끝점을 사용하여 RPT를 인트로스펙션하려면 다음과 같이 서버에 요청을 보낼 수 있습니다.

curl -X POST \
    -H "Authorization: Basic aGVsbG8td29ybGQtYXV0aHotc2VydmljZTpzZWNyZXQ=" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d 'token_type_hint=requesting_party_token&token=${RPT}' \
    "http://localhost:8080/auth/realms/hello-world-authz/protocol/openid-connect/token/introspect"
Copy to Clipboard
참고

위의 요청은 HTTP BASIC을 사용하고 클라이언트의 자격 증명(클라이언트 ID 및 시크릿)을 전달하여 토큰을 인트로스펙션하려는 클라이언트를 인증하지만 Red Hat Single Sign-On에서 지원하는 다른 클라이언트 인증 방법을 사용할 수 있습니다.

인트로스펙션 끝점에는 다음 두 개의 매개변수가 필요합니다.

  • token_type_hint

    requesting_party_token 을 이 매개변수 값으로 사용합니다. 이 매개변수는 RPT를 인트로스펙션할 것임을 나타냅니다.

  • token

    권한 부여 프로세스 중에 서버에서 반환한 토큰 문자열을 이 매개변수의 값으로 사용합니다.

결과적으로 서버 응답은 다음과 같습니다.

{
  "permissions": [
    {
      "resource_id": "90ccc6fc-b296-4cd1-881e-089e1ee15957",
      "resource_name": "Hello World Resource"
    }
  ],
  "exp": 1465314139,
  "nbf": 0,
  "iat": 1465313839,
  "aud": "hello-world-authz-service",
  "active": true
}
Copy to Clipboard

RPT가 활성 상태가 아닌 경우 이 응답은 대신 반환됩니다.

{
  "active": false
}
Copy to Clipboard

8.5.3. RPT를 인트로스펙션할 때마다 서버를 호출해야 합니까?

아니요. Red Hat Single Sign-On 서버에서 발행한 일반 액세스 토큰과 마찬가지로 RPT는 JSON 웹 토큰(JWT) 사양을 기본 형식으로 사용합니다.

원격 인트로스펙션 엔드포인트를 호출하지 않고 이러한 토큰을 검증하려면 RPT를 디코딩하고 로컬로 유효성을 쿼리할 수 있습니다. 토큰을 디코딩한 후 토큰 내 권한을 사용하여 권한 결정을 적용할 수도 있습니다.

이것이 바로 정책 강화가 하는 역할입니다. 다음을 확인하십시오.

  • 영역의 공개 키 기반(RPT)의 서명을 검증합니다.
  • exp,iat, aud 클레임을 기반으로 토큰 유효성을 쿼리합니다.

8.6. 권한 부여 클라이언트 Java API

리소스 서버는 요구 사항에 따라 리소스를 원격으로 관리하거나 프로그래밍 방식으로 권한을 확인할 수 있어야 합니다. Java를 사용하는 경우 Authorization Client API를 사용하여 Red Hat Single Sign-On 인증 서비스에 액세스할 수 있습니다.

토큰 엔드 포인트, 리소스, 권한 관리 엔드포인트와 같이 서버에서 제공하는 다양한 엔드포인트에 액세스하려는 리소스 서버를 대상으로 합니다.

8.6.1. Maven 종속성

<dependencies>
    <dependency>
        <groupId>org.keycloak</groupId>
        <artifactId>keycloak-authz-client</artifactId>
        <version>${KEYCLOAK_VERSION}</version>
    </dependency>
</dependencies>
Copy to Clipboard

8.6.2. 설정

클라이언트 구성은 다음과 같이 keycloak.json 파일에 정의됩니다.

{
  "realm": "hello-world-authz",
  "auth-server-url" : "http://localhost:8080/auth",
  "resource" : "hello-world-authz-service",
  "credentials": {
    "secret": "secret"
  }
}
Copy to Clipboard
  • 영역 (필수)

    영역의 이름입니다.

  • auth-server-url (필수)

    Red Hat Single Sign-On 서버의 기본 URL입니다. 다른 모든 Red Hat Single Sign-On 페이지 및 REST 서비스 엔드포인트는 여기에서 파생됩니다. 일반적으로 https://host:port/auth 형식으로 되어 있습니다.

  • 리소스 (필수)

    애플리케이션의 클라이언트 ID입니다. 각 애플리케이션에는 애플리케이션을 식별하는 데 사용되는 클라이언트 ID가 있습니다.

  • 인증 정보 (필수)

    애플리케이션의 자격 증명을 지정합니다. 키가 인증 정보 유형이고 값은 인증 정보 유형의 값인 오브젝트 표기법입니다.

구성 파일은 일반적으로 클라이언트가 keycloak.json 파일을 찾으려고 하는 기본 위치인 애플리케이션의 classpath에 있습니다.

8.6.3. 권한 부여 클라이언트 생성

classpath에 keycloak.json 파일이 있으면 다음과 같이 새 AuthzClient 인스턴스를 만들 수 있습니다.

    // create a new instance based on the configuration defined in a keycloak.json located in your classpath
    AuthzClient authzClient = AuthzClient.create();
Copy to Clipboard

8.6.4. 사용자 인타이틀먼트 가져오기

다음은 사용자 인타이틀먼트를 얻는 방법을 보여주는 예입니다.

// create a new instance based on the configuration defined in keycloak.json
AuthzClient authzClient = AuthzClient.create();

// create an authorization request
AuthorizationRequest request = new AuthorizationRequest();

// send the entitlement request to the server in order to
// obtain an RPT with all permissions granted to the user
AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize(request);
String rpt = response.getToken();

System.out.println("You got an RPT: " + rpt);

// now you can use the RPT to access protected resources on the resource server
Copy to Clipboard

다음은 하나 이상의 리소스 집합에 대한 사용자 자격을 얻는 방법을 보여주는 예입니다.

// create a new instance based on the configuration defined in keycloak.json
AuthzClient authzClient = AuthzClient.create();

// create an authorization request
AuthorizationRequest request = new AuthorizationRequest();

// add permissions to the request based on the resources and scopes you want to check access
request.addPermission("Default Resource");

// send the entitlement request to the server in order to
// obtain an RPT with permissions for a single resource
AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize(request);
String rpt = response.getToken();

System.out.println("You got an RPT: " + rpt);

// now you can use the RPT to access protected resources on the resource server
Copy to Clipboard

8.6.5. 보호 API를 사용하여 리소스 생성

// create a new instance based on the configuration defined in keycloak.json
AuthzClient authzClient = AuthzClient.create();

// create a new resource representation with the information we want
ResourceRepresentation newResource = new ResourceRepresentation();

newResource.setName("New Resource");
newResource.setType("urn:hello-world-authz:resources:example");

newResource.addScope(new ScopeRepresentation("urn:hello-world-authz:scopes:view"));

ProtectedResource resourceClient = authzClient.protection().resource();
ResourceRepresentation existingResource = resourceClient.findByName(newResource.getName());

if (existingResource != null) {
    resourceClient.delete(existingResource.getId());
}

// create the resource on the server
ResourceRepresentation response = resourceClient.create(newResource);
String resourceId = response.getId();

// query the resource using its newly generated id
ResourceRepresentation resource = resourceClient.findById(resourceId);

System.out.println(resource);
Copy to Clipboard

8.6.6. RPT 검사

// create a new instance based on the configuration defined in keycloak.json
AuthzClient authzClient = AuthzClient.create();

// send the authorization request to the server in order to
// obtain an RPT with all permissions granted to the user
AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize();
String rpt = response.getToken();

// introspect the token
TokenIntrospectionResponse requestingPartyToken = authzClient.protection().introspectRequestingPartyToken(rpt);

System.out.println("Token status is: " + requestingPartyToken.getActive());
System.out.println("Permissions granted by the server: ");

for (Permission granted : requestingPartyToken.getPermissions()) {
    System.out.println(granted);
}
Copy to Clipboard

9장. 정책 적용자

PEP (Policy Enforcement Point)는 설계 패턴이므로 다양한 방식으로 구현할 수 있습니다. Red Hat Single Sign-On은 다양한 플랫폼, 환경 및 프로그래밍 언어를 위한 PEP를 구현하는 데 필요한 모든 수단을 제공합니다. Red Hat Single Sign-On 권한 부여 서비스는 RESTful API를 제공하고 OAuth2 권한 부여 기능을 활용하여 중앙 집중식 권한 부여 서버를 사용하여 세분화됩니다.

PEP overview

PEP는 보호 리소스와 관련된 정책을 평가하여 이러한 결정을 내릴 Red Hat Single Sign-On 서버의 액세스 결정을 시행합니다. 이러한 결정이 부여된 권한에 따라 보호 리소스에 대한 특정 요청을 이행할 수 있는지 여부를 확인하기 위해 애플리케이션에서 필터 또는 인터셉터 역할을 합니다.

사용 중인 프로토콜에 따라 권한이 적용됩니다. UMA를 사용할 때 정책 적용자는 요청을 제공할 수 있는지 여부를 결정하기 위해 항상 RPT를 전달자 토큰으로 예상합니다. 즉, 클라이언트는 먼저 리소스 서버에 요청을 보내기 전에 Red Hat Single Sign-On에서 RPT를 받아야 합니다.

그러나 UMA를 사용하지 않는 경우 리소스 서버에 일반 액세스 토큰을 보낼 수도 있습니다. 이 경우 정책 적용자는 서버에서 직접 권한을 가져오려고 합니다.

Red Hat Single Sign-On OIDC 어댑터를 사용하는 경우 keycloak.json 파일에 다음 속성을 추가하여 정책 적용자를 쉽게 활성화할 수 있습니다.

keycloak.json

{
 "policy-enforcer": {}
}
Copy to Clipboard

정책을 활성화하면 애플리케이션에 전송된 모든 요청이 가로채고 Red Hat Single Sign-On에서 요청한 ID에 대한 권한에 따라 보호되는 리소스에 대한 액세스가 부여됩니다.

정책 적용은 Red Hat Single Sign-On 관리 콘솔을 사용하여 애플리케이션 경로 및 리소스 서버에 생성한 리소스에 강력하게 연결됩니다. 기본적으로 리소스 서버를 생성할 때 Red Hat Single Sign-On은 리소스 서버에 대한 기본 구성을 생성하여 정책 적용을 신속하게 활성화할 수 있습니다.

9.1. 설정

애플리케이션에 대한 정책 적용을 활성화하려면 keycloak.json 파일에 다음 속성을 추가합니다.

keycloak.json

{
  "policy-enforcer": {}
}
Copy to Clipboard

또는 보호되는 리소스를 수동으로 정의하려는 경우 보다 자세한 정보를 확인할 수 있습니다.

{
  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING",
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      },
      {
        "name" : "Some Resource",
        "path" : "/usingPattern/{id}",
        "methods" : [
          {
            "method": "DELETE",
            "scopes" : ["urn:app.com:scopes:delete"]
          }
        ]
      },
      {
        "path" : "/exactMatch"
      },
      {
        "name" : "Admin Resources",
        "path" : "/usingWildCards/*"
      }
    ]
  }
}
Copy to Clipboard

다음은 각 구성 옵션에 대한 설명입니다.

  • policy-enforcer

    정책이 실제로 적용되는 방법과 보호하려는 경로를 선택적으로 정의하는 구성 옵션을 지정합니다. 지정하지 않으면 정책은 서버에서 서버에서 보호 중인 리소스 서버와 연결된 모든 리소스에 대해 쿼리합니다. 이 경우 보호하려는 경로와 일치하는 URIS 속성으로 리소스가 올바르게 구성되었는지 확인해야 합니다.

    • user-managed-access

      어댑터가 UMA 프로토콜을 사용하도록 지정합니다. 지정된 경우 어댑터는 서버에서 권한 티켓을 쿼리하고 UMA 사양에 따라 클라이언트로 반환합니다. 지정하지 않으면 정책 적용자가 일반 액세스 토큰 또는 RPT에 따라 권한을 적용할 수 있습니다. 이 경우 토큰에 권한이 없는 경우 리소스에 대한 액세스를 거부하기 전에 정책 적용자가 서버에서 직접 권한을 확보하려고 합니다.

    • enforcement-mode

      정책을 적용하는 방법을 지정합니다.

      • ENFORCING

        (기본 모드) 지정된 리소스와 연결된 정책이 없는 경우에도 기본적으로 요청이 거부됩니다.

      • PERMISSIVE

        지정된 리소스와 연결된 정책이 없는 경우에도 요청이 허용됩니다.

      • DISABLED

        정책 평가를 완전히 비활성화하고 모든 리소스에 액세스할 수 있습니다. 적용 모드DISABLED 애플리케이션인 경우에도 권한 부여 컨텍스트를 통해 Red Hat Single Sign-On에서 부여한 모든 권한을 얻을 수 있습니다.

    • on-deny-redirect-to

      서버에서 "access denied" 메시지를 가져올 때 클라이언트 요청이 리디렉션되는 URL을 정의합니다. 기본적으로 어댑터는 403 HTTP 상태 코드로 응답합니다.

    • path-cache

      정책 적용자가 Red Hat Single Sign-On에 정의된 애플리케이션 경로와 리소스 간의 연결을 추적하는 방법을 정의합니다. 경로와 보호 리소스 간에 연결을 캐싱하여 Red Hat Single Sign-On 서버에 대한 불필요한 요청을 방지하려면 캐시가 필요합니다.

      • Lifespan

        항목을 만료해야 하는 시간(밀리초)을 정의합니다. 제공되지 않는 경우 기본값은 30000 입니다. 0과 같은 값을 설정하면 캐시를 완전히 비활성화할 수 있습니다. 캐시 만료를 비활성화하려면 -1과 같은 값을 설정할 수 있습니다.

      • Max-entries

        캐시에 보관해야 하는 항목의 제한을 정의합니다. 제공되지 않는 경우 기본값은 1000 입니다.

    • 경로

      보호할 경로를 지정합니다. 이 구성은 선택 사항입니다. 정의되지 않은 경우 정책 적용자는 Red Hat Single Sign-On에서 애플리케이션에 정의된 리소스를 가져와 모든 경로를 검색합니다. 여기서 이러한 리소스는 애플리케이션의 일부 경로를 나타내는 URIS 로 정의됩니다.

      • name

        지정된 경로와 연결할 서버의 리소스 이름입니다. 경로 와 함께 사용하는 경우 policy enforcer는 리소스의 URIS 속성을 무시하고 대신 제공한 경로를 사용합니다.

      • 경로

        (필수) 애플리케이션의 컨텍스트 경로에 상대적인 URI입니다. 이 옵션을 지정하면 정책 적용자가 서버에서 동일한 값이 있는 URI 를 사용하여 리소스를 쿼리합니다. 현재는 경로 일치에 대한 매우 기본적인 논리가 지원됩니다. 유효한 경로의 예는 다음과 같습니다.

        • Wildcards: /*
        • 접미사: /*.html
        • sub-paths: /path/*
        • 경로 매개변수: /resource/{id}
        • 정확한 일치: /resource
        • 패턴: /{version}/resource, /api/{version}/resource, /api/{version}/resource/*
      • 방법

        보호하는 HTTP 메서드(예: GET, POST, PATCH) 및 해당 메서드가 서버의 지정된 리소스의 범위와 연관되는 방법입니다.

        • method

          HTTP 메서드의 이름입니다.

        • scopes

          이 메서드와 연결된 범위가 포함된 문자열 배열입니다. 범위를 특정 방법과 연결할 때 보호되는 리소스(또는 경로)에 액세스하려는 클라이언트는 목록에 지정된 모든 범위에 대한 권한을 부여하는 RPT를 제공해야 합니다. 예를 들어, 범위 생성 으로 메서드 POST 를 정의하는 경우 RPT에는 경로에 POST를 수행할 때 생성 범위에 대한 액세스 권한을 부여하는 권한이 포함되어야 합니다.

        • scopes-enforcement-mode

          메서드와 연결된 범위에 대한 적용 모드를 참조하는 문자열입니다. 값은 모두 또는 임의의 값 일 수 있습니다. ALL 인 경우 해당 방법을 사용하여 리소스에 액세스하려면 정의된 모든 범위를 부여해야 합니다. 임의의 경우 해당 방법을 사용하여 리소스에 액세스하려면 하나 이상의 범위를 부여해야 합니다. 기본적으로 적용 모드는 모두 로 설정됩니다.

      • enforcement-mode

        정책을 적용하는 방법을 지정합니다.

        • ENFORCING

          (기본 모드) 지정된 리소스와 연결된 정책이 없는 경우에도 기본적으로 요청이 거부됩니다.

        • DISABLED
      • claim-information-point

        이러한 클레임을 정책에서 사용할 수 있도록 해결한 후 Red Hat Single Sign-On 서버로 푸시해야 하는 클레임 세트를 하나 이상 정의합니다. 자세한 내용은 클레임 정보 포인트를 참조하십시오.

    • lazy-load-paths

      어댑터에서 애플리케이션의 경로와 관련된 리소스에 대해 서버를 가져오는 방법을 지정합니다. true 인 경우 정책 적용자는 요청되는 경로와 함께 필요에 따라 리소스를 가져올 것입니다. 이 구성은 배포 중에 서버에서 모든 리소스를 가져오고 싶지 않거나( 경로가 제공되지 않은 경우) 하위 경로만 정의하고 필요에 따라 다른 리소스를 가져오려는 경우 유용합니다.

    • http-method-as-scope

      범위를 HTTP 메서드에 매핑하는 방법을 지정합니다. true 로 설정하면 정책 적용자가 현재 요청의 HTTP 메서드를 사용하여 액세스 권한이 부여되어야 하는지 확인합니다. 활성화하면 Red Hat Single Sign-On의 리소스가 보호하는 각 HTTP 방법을 나타내는 범위와 연결되어 있는지 확인합니다.

    • claim-information-point

      이러한 클레임을 정책에서 사용할 수 있도록 해결한 후 Red Hat Single Sign-On 서버로 푸시해야 하는 글로벌 클레임 세트를 하나 이상 정의합니다. 자세한 내용은 클레임 정보 포인트를 참조하십시오.

9.2. 클레임 정보 포인트

클레임 정보 포인트(CIP)는 정책에 대한 액세스 컨텍스트에 대한 자세한 정보를 제공하기 위해 클레임을 해결하고 이러한 클레임을 Red Hat Single Sign-On 서버로 푸시해야 합니다. 다음과 같은 다양한 소스의 클레임을 해결하기 위해 policy-enforcer에 대한 구성 옵션으로 정의할 수 있습니다.

  • HTTP 요청(parameters, headers, body 등)
  • 외부 HTTP 서비스
  • 구성에 정의된 정적 값
  • 클레임 정보 공급자 SPI를 구현한 기타 소스

Red Hat Single Sign-On 서버에 클레임을 푸시할 때 정책은 사용자가 누구인지뿐만 아니라 주어진 트랜잭션에 대해 누가, 무엇을, 언제, 어디에서, 어떤지, 어떤지, 언제, 어디서, 어떤지, 어떤지, 컨텍스트 및 콘텐츠를 고려하여 기본 결정을 내릴 수 있습니다. 컨텍스트 기반 권한 부여와 런타임 정보를 사용하여 세분화된 권한 결정을 지원하는 방법에 관한 것입니다.

9.2.1. HTTP 요청에서 정보 가져오기

다음은 HTTP 요청에서 클레임을 추출하는 방법을 보여주는 몇 가지 예입니다.

keycloak.json

"policy-enforcer": {
    "paths": [
      {
        "path": "/protected/resource",
        "claim-information-point": {
          "claims": {
            "claim-from-request-parameter": "{request.parameter['a']}",
            "claim-from-header": "{request.header['b']}",
            "claim-from-cookie": "{request.cookie['c']}",
            "claim-from-remoteAddr": "{request.remoteAddr}",
            "claim-from-method": "{request.method}",
            "claim-from-uri": "{request.uri}",
            "claim-from-relativePath": "{request.relativePath}",
            "claim-from-secure": "{request.secure}",
            "claim-from-json-body-object": "{request.body['/a/b/c']}",
            "claim-from-json-body-array": "{request.body['/d/1']}",
            "claim-from-body": "{request.body}",
            "claim-from-static-value": "static value",
            "claim-from-multiple-static-value": ["static", "value"],
            "param-replace-multiple-placeholder": "Test {keycloak.access_token['/custom_claim/0']} and {request.parameter['a']} "
          }
        }
      }
    ]
  }
Copy to Clipboard

9.2.2. 외부 HTTP 서비스에서 정보 가져오기

다음은 외부 HTTP 서비스에서 클레임을 추출하는 방법을 보여주는 몇 가지 예입니다.

keycloak.json

"policy-enforcer": {
    "paths": [
      {
        "path": "/protected/resource",
        "claim-information-point": {
          "http": {
            "claims": {
              "claim-a": "/a",
              "claim-d": "/d",
              "claim-d0": "/d/0",
              "claim-d-all": ["/d/0", "/d/1"]
            },
            "url": "http://mycompany/claim-provider",
            "method": "POST",
            "headers": {
              "Content-Type": "application/x-www-form-urlencoded",
              "header-b": ["header-b-value1", "header-b-value2"],
              "Authorization": "Bearer {keycloak.access_token}"
            },
            "parameters": {
              "param-a": ["param-a-value1", "param-a-value2"],
              "param-subject": "{keycloak.access_token['/sub']}",
              "param-user-name": "{keycloak.access_token['/preferred_username']}",
              "param-other-claims": "{keycloak.access_token['/custom_claim']}"
            }
          }
        }
      }
    ]
  }
Copy to Clipboard

9.2.3. 정적 클레임

keycloak.json

"policy-enforcer": {
    "paths": [
      {
        "path": "/protected/resource",
        "claim-information-point": {
          "claims": {
            "claim-from-static-value": "static value",
            "claim-from-multiple-static-value": ["static", "value"],
          }
        }
      }
    ]
  }
Copy to Clipboard

9.2.4. 클레임 정보 공급자 SPI

Claim Information Provider SPI는 개발자가 기본 제공 업체의 요구 사항을 해결하기에 충분하지 않은 경우 다른 클레임 정보 포인트를 지원하는 데 사용할 수 있습니다.

예를 들어 새 CIP 공급자를 구현하려면 애플리케이션 클래스 경로에 org.keycloak.adapters.authorization.ClaimanchorProviderFactory.Claim>-<ProviderFactoryClaim> -<Provider Provider 파일을 구현해야 하며, 애플리케이션 클래스 경로에 META-INF/services/org.keycloak.adapters.ClaimanchorProviderFactory 파일을 제공해야 합니다.

org.keycloak.adapters.authorization.Claim#177ProviderFactory 의 예:

public class MyClaimInformationPointProviderFactory implements ClaimInformationPointProviderFactory<MyClaimInformationPointProvider> {

    @Override
    public String getName() {
        return "my-claims";
    }

    @Override
    public void init(PolicyEnforcer policyEnforcer) {

    }

    @Override
    public MyClaimInformationPointProvider create(Map<String, Object> config) {
        return new MyClaimInformationPointProvider(config);
    }
}
Copy to Clipboard

모든 CIP 공급자는 위에서 정의한 MyClaimanchorProviderFactory.getName 메서드와 이름이 연결되어 있어야 합니다. name은 policy-enforcer 구성의 claim-point 섹션의 구성을 구현에 매핑하는 데 사용됩니다.

요청을 처리할 때 정책 적용자는 MyClaimanchorProviderFactory.create 메서드를 호출하여 MyClaim#177Provider의 인스턴스를 가져옵니다. 이 특정 CIP 공급자에 대해 정의된 모든 구성이 맵으로 전달됩니다(Claim-point를 통해).

Claim#177Provider의 예:

public class MyClaimInformationPointProvider implements ClaimInformationPointProvider {

    private final Map<String, Object> config;

    public MyClaimInformationPointProvider(Map<String, Object> config) {
        this.config = config;
    }

    @Override
    public Map<String, List<String>> resolve(HttpFacade httpFacade) {
        Map<String, List<String>> claims = new HashMap<>();

        // put whatever claim you want into the map

        return claims;
    }
}
Copy to Clipboard

9.3. 권한 부여 컨텍스트 가져오기

정책 시행이 활성화되면 org.keycloak.AuthorizationContext 를 통해 서버에서 얻은 권한을 사용할 수 있습니다. 이 클래스는 권한을 확보하고 특정 리소스 또는 범위에 대한 권한이 부여되었는지 여부를 확인하는 데 사용할 수 있는 여러 메서드를 제공합니다.

Servlet 컨테이너에서 권한 부여 컨텍스트 가져오기

    HttpServletRequest request = ... // obtain javax.servlet.http.HttpServletRequest
    KeycloakSecurityContext keycloakSecurityContext =
        (KeycloakSecurityContext) request
            .getAttribute(KeycloakSecurityContext.class.getName());
    AuthorizationContext authzContext =
        keycloakSecurityContext.getAuthorizationContext();
Copy to Clipboard
참고

KeycloakSecurityContext 를 얻는 방법에 대한 자세한 내용은 어댑터 구성을 참조하십시오. 위의 예제에서는 Red Hat Single Sign-On에서 지원하는 서블릿 컨테이너를 사용하여 애플리케이션을 실행할 때 컨텍스트를 가져오기에 충분해야 합니다.

권한 부여 컨텍스트를 사용하면 서버에서 결정하고 반환된 결정을 더 많이 제어할 수 있습니다. 예를 들어 리소스 또는 범위와 연결된 권한에 따라 항목이 숨겨져 있거나 표시되는 동적 메뉴를 빌드하는 데 사용할 수 있습니다.

if (authzContext.hasResourcePermission("Project Resource")) {
    // user can access the Project Resource
}

if (authzContext.hasResourcePermission("Admin Resource")) {
    // user can access administration resources
}

if (authzContext.hasScopePermission("urn:project.com:project:create")) {
    // user can create new projects
}
Copy to Clipboard

AuthorizationContext 는 Red Hat Single Sign-On Authorization Services의 주요 기능 중 하나입니다. 위의 예에서 보호되는 리소스가 이를 관리하는 정책과 직접 연결되지 않음을 확인할 수 있습니다.

RBAC(역할 기반 액세스 제어)를 사용하는 유사한 코드를 고려하십시오.

if (User.hasRole('user')) {
    // user can access the Project Resource
}

if (User.hasRole('admin')) {
    // user can access administration resources
}

if (User.hasRole('project-manager')) {
    // user can create new projects
}
Copy to Clipboard

두 예제 모두 동일한 요구 사항을 처리하지만 다른 방식으로 수행합니다. RBAC에서 역할은 해당 리소스에 대한 액세스 권한만 암시적으로 정의합니다. Red Hat Single Sign-On을 사용하면 RBAC, 특성 기반 액세스 제어(ABAC) 또는 기타 BAC 변형 사용 여부에 관계없이 리소스에 직접 중점을 둔 보다 관리 가능한 코드를 생성할 수 있습니다. 지정된 리소스 또는 범위에 대한 권한이 있거나 그렇지 않습니다.

이제 보안 요구 사항이 변경되었으며 프로젝트 관리자 외에도 PMO도 새 프로젝트를 만들 수 있다고 가정합니다.

보안 요구 사항이 변경되었지만 Red Hat Single Sign-On에서는 새 요구 사항을 해결하기 위해 애플리케이션 코드를 변경할 필요가 없습니다. 애플리케이션이 리소스 및 범위 식별자를 기반으로 하는 경우 권한 부여 서버에서 특정 리소스와 연결된 권한 또는 정책의 구성만 변경해야 합니다. 이 경우 프로젝트 리소스 및/또는 urn:project.com:project:create 와 연결된 권한 및 정책이 변경됩니다.

9.4. AuthorizationContext를 사용하여 Authorization Client Instance 가져오기

AuthorizationContext 는 애플리케이션에 구성된 Authorization Client API 에 대한 참조를 가져오는 데에도 사용할 수 있습니다.

    ClientAuthorizationContext clientContext = ClientAuthorizationContext.class.cast(authzContext);
    AuthzClient authzClient = clientContext.getClient();
Copy to Clipboard

정책으로 보호되는 리소스 서버는 권한 부여 서버에서 제공하는 API에 액세스해야 합니다. AuthzClient 인스턴스를 통해 리소스 서버는 리소스를 만들거나 프로그래밍 방식으로 특정 권한을 확인하기 위해 서버와 상호 작용할 수 있습니다.

9.5. JavaScript 통합

Red Hat Single Sign-On Server에는 정책 적용자가 보호하는 리소스 서버와 상호 작용하는 데 사용할 수 있는 JavaScript 라이브러리가 제공됩니다. 이 라이브러리는 Red Hat Single Sign-On JavaScript 어댑터를 기반으로 하며, 이를 통합하여 클라이언트가 Red Hat Single Sign-On 서버에서 권한을 얻을 수 있습니다.

웹 페이지에 다음 스크립트 태그를 포함하여 실행 중인 Red Hat Single Sign-On Server 인스턴스에서 이 라이브러리를 가져올 수 있습니다.

<script src="http://.../auth/js/keycloak-authz.js"></script>
Copy to Clipboard

이렇게 하면 다음과 같이 KeycloakAuthorization 인스턴스를 생성할 수 있습니다.

const keycloak = ... // obtain a Keycloak instance from keycloak.js library
const authorization = new KeycloakAuthorization(keycloak);
Copy to Clipboard

keycloak-authz.js 라이브러리는 다음 두 가지 주요 기능을 제공합니다.

  • UMA 보호 리소스 서버에 액세스하는 경우 권한 티켓을 사용하여 서버에서 권한을 얻습니다.
  • 리소스를 전송하고 애플리케이션이 액세스하려는 범위를 보내 서버에서 권한을 얻습니다.

두 경우 모두 라이브러리를 사용하면 리소스 서버와 Red Hat Single Sign-On 인증 서비스와 쉽게 상호 작용하여 클라이언트가 리소스 서버의 보호 리소스에 액세스하는 데 사용할 수 있는 권한을 통해 토큰을 가져올 수 있습니다.

9.5.1. UMA 보호 리소스 서버의 권한 부여 응답 처리

리소스 서버가 정책 적용자에 의해 보호되는 경우 전달자 토큰과 함께 전달된 권한에 따라 클라이언트 요청에 응답합니다. 일반적으로 보호된 리소스에 액세스할 수 있는 권한이 없는 전달자 토큰을 사용하여 리소스 서버에 액세스하려고 하면 리소스 서버는 401 상태 코드 및 WWW-Authenticate 헤더로 응답합니다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="${realm}",
    as_uri="https://${host}:${port}/auth/realms/${realm}",
    ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
Copy to Clipboard

자세한 내용은 UMA 권한 부여 프로세스를 참조하십시오.

클라이언트가 해야 하는 작업은 리소스 서버에서 반환한 WWW-Authenticate 헤더에서 권한 티켓을 추출하고 라이브러리를 사용하여 다음과 같이 권한 부여 요청을 보내는 것입니다.

// prepare a authorization request with the permission ticket
const authorizationRequest = {};
authorizationRequest.ticket = ticket;

// send the authorization request, if successful retry the request
Identity.authorization.authorize(authorizationRequest).then(function (rpt) {
    // onGrant
}, function () {
    // onDeny
}, function () {
    // onError
});
Copy to Clipboard

authorize 함수는 완전히 비동기식이며 서버로부터 알림을 수신하는 몇 가지 콜백 함수를 지원합니다.

  • OnGrant: 함수의 첫 번째 인수입니다. 권한 부여에 성공하고 서버가 요청된 권한이 있는 RPT를 반환하면 콜백에서 RPT를 수신합니다.
  • onDeny: 함수의 두 번째 인수입니다. 서버가 권한 부여 요청을 거부한 경우에만 호출됩니다.
  • OnError: 함수의 세 번째 인수입니다. 서버가 예기치 않게 응답한 경우에만 호출됩니다.

대부분의 애플리케이션에서는 onGrant 콜백을 사용하여 401 응답 후 요청을 다시 시도해야 합니다. 후속 요청에는 재시도를 위한 전달자 토큰으로 RPT가 포함되어야 합니다.

9.5.2. 인타이틀먼트 가져오기

keycloak-authz.js 라이브러리는 클라이언트가 액세스하려는 리소스와 범위를 제공하여 서버에서 RPT를 얻는 데 사용할 수 있는 인타이틀먼트 기능을 제공합니다.

예를 들어 사용자가 액세스할 수 있는 모든 리소스 및 범위에 대한 권한이 있는 RPT를 얻는 방법

authorization.entitlement('my-resource-server-id').then(function (rpt) {
    // onGrant callback function.
    // If authorization was successful you'll receive an RPT
    // with the necessary permissions to access the resource server
});
Copy to Clipboard

특정 리소스 및 범위에 대한 권한이 있는 RPT를 얻는 방법의 예

authorization.entitlement('my-resource-server', {
    "permissions": [
        {
            "id" : "Some Resource"
        }
    ]
}).then(function (rpt) {
    // onGrant
});
Copy to Clipboard

인타이틀먼트 기능을 사용하는 경우 액세스하려는 리소스 서버의 client_id 를 제공해야 합니다.

인타이틀먼트 기능은 완전히 비동기식이며 서버로부터 알림을 수신하는 몇 가지 콜백 함수를 지원합니다.

  • OnGrant: 함수의 첫 번째 인수입니다. 권한 부여에 성공하고 서버가 요청된 권한이 있는 RPT를 반환하면 콜백에서 RPT를 수신합니다.
  • onDeny: 함수의 두 번째 인수입니다. 서버가 권한 부여 요청을 거부한 경우에만 호출됩니다.
  • OnError: 함수의 세 번째 인수입니다. 서버가 예기치 않게 응답한 경우에만 호출됩니다.

9.5.3. 권한 부여 요청

인증인타이틀먼트 기능은 모두 권한 부여 요청 오브젝트를 수락합니다. 이 오브젝트는 다음 속성을 사용하여 설정할 수 있습니다.

  • 권한

    리소스 및 범위를 나타내는 오브젝트의 배열입니다. 예를 들면 다음과 같습니다.

    const authorizationRequest = {
       "permissions": [
           {
               "id" : "Some Resource",
               "scopes" : ["view", "edit"]
           }
       ]
    }
    Copy to Clipboard
  • metadata

    해당 속성이 서버에서 권한 부여 요청을 처리하는 방법을 정의하는 오브젝트입니다.

    • response_include_resource_name

      RPT 권한에 리소스 이름이 포함되어야 하는 경우 서버에 대한 부울 값입니다. false인 경우 리소스 식별자만 포함됩니다.

    • response_permissions_limit

      RPT에 있을 수 있는 권한 수에 대한 제한을 정의하는 정수 N입니다. rpt 매개변수와 함께 사용하면 마지막 N개의 요청된 권한만 RPT에 유지됩니다.

  • submit_request

    서버가 권한 티켓에서 참조하는 리소스 및 범위에 대한 권한 요청을 생성해야 하는지 여부를 나타내는 부울 값입니다. 이 매개변수는 UMA 권한 부여 프로세스의 일부로 티켓 매개변수와 함께 사용할 때만 적용됩니다.

9.5.4. RPT 얻기

라이브러리에서 제공하는 권한 부여 함수를 사용하여 이미 RPT를 받은 경우, 권한 부여 개체(이전에 표시된 기술 중 하나에 의해 초기화되었다고 가정함)에서 다음과 같이 RPT를 얻을 수 있습니다.

const rpt = authorization.rpt;
Copy to Clipboard

9.6. TLS/HTTPS 구성

서버가 HTTPS를 사용하는 경우 어댑터가 다음과 같이 구성되어 있는지 확인합니다.

keycloak.json

{
  "truststore": "path_to_your_trust_store",
  "truststore-password": "trust_store_password"
}
Copy to Clipboard

위의 구성을 통해 TLS/HTTPS를 인증 클라이언트로 사용할 수 있으므로 HTTPS 스키마를 사용하여 Red Hat Single Sign-On Server에 원격으로 액세스할 수 있습니다.

참고

Red Hat Single Sign-On Server 엔드포인트에 액세스할 때 TLS/HTTPS를 활성화하는 것이 좋습니다.

법적 공지

Copyright © 2021 Red Hat, Inc.
Apache License, 버전 2.0 (License")에 따라 라이센스가 부여되었으며 라이센스 준수를 제외하고 이 파일을 사용할 수 없습니다. 다음에서 라이센스 사본을 받을 수 있습니다.
관련 법률에서 요구하거나 서면으로 동의한 경우를 제외하고, 라이센스 하에 배포된 소프트웨어는 "AS IS" BASIS, skopeoOUT WARRANTIES OR CONDITIONS OF ANY KIND에 배포됩니다. 라이센스 아래의 특정 언어 관리 권한 및 제한 사항에 대한 라이선스를 참조하십시오.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat