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. 아키텍처
설계 관점에서 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. 리소스 관리
리소스 관리는 보호 대상을 정의하는 데 필요한 모든 단계를 포함합니다.
먼저 웹 애플리케이션 또는 하나 이상의 서비스 집합을 나타내는 보호하기 위해 Red Hat Single Sign-On을 지정해야 합니다. 리소스 서버에 대한 자세한 내용은 Terminology 를 참조하십시오.
리소스 서버는 Red Hat Single Sign-On 관리 콘솔을 사용하여 관리됩니다. 여기에서 등록된 클라이언트 애플리케이션을 리소스 서버로 활성화하고 보호하려는 리소스 및 범위 관리를 시작할 수 있습니다.
리소스는 웹 페이지, RESTFul 리소스, 파일 시스템의 파일, NodePort 등일 수 있습니다. 리소스 그룹(Java의 클래스처럼) 또는 단일 특정 리소스를 나타낼 수 있습니다.
예를 들어, 모든 뱅킹 계정을 나타내는 CloudEvent 계정 리소스가 있을 수 있으며 이를 사용하여 모든 뱅킹 계정에 공통적인 권한 부여 정책을 정의할 수 있습니다. 그러나 소유자만 일부 정보에 액세스하거나 작업을 수행할 수 있는 Alice 계정에 대한 특정 정책(고객에 속하는 리소스 인스턴스)을 정의할 수 있습니다.
리소스는 Red Hat Single Sign-On 관리 콘솔 또는 Protection API 를 사용하여 관리할 수 있습니다. 후자의 경우 리소스 서버는 리소스를 원격으로 관리할 수 있습니다.
범위는 일반적으로 리소스에서 수행할 수 있지만 이에 국한되지 않는 작업을 나타냅니다. 범위를 사용하여 리소스 내에서 하나 이상의 속성을 나타낼 수도 있습니다.
1.1.1.2. 권한 및 정책 관리
리소스 서버와 보호하려는 모든 리소스를 정의한 후에는 권한 및 정책을 설정해야 합니다.
이 프로세스에는 리소스를 관리하는 보안 및 액세스 요구 사항을 실제로 정의하는 데 필요한 모든 단계가 포함됩니다.
정책은 어떤 항목(리소스 또는 범위)에서 작업에 액세스하거나 실행하기 위해 충족해야 하는 조건을 정의하지만 보호 대상과 연결되지 않습니다. 이는 일반적이며 권한 또는 훨씬 더 복잡한 정책을 빌드하도록 재사용할 수 있습니다.
예를 들어 역할 "User Premium"으로 부여된 사용자만 리소스 그룹에 대한 액세스를 허용하려면 RBAC(역할 기반 액세스 제어)를 사용할 수 있습니다.
Red Hat Single Sign-On은 가장 일반적인 액세스 제어 메커니즘을 다루는 몇 가지 기본 제공 정책 유형(및 해당 정책 공급자)을 제공합니다. JavaScript를 사용하여 작성된 규칙을 기반으로 정책을 만들 수도 있습니다.
정책을 정의하면 권한 정의를 시작할 수 있습니다. 권한은 보호하려는 리소스와 결합됩니다. 여기에서 보호하려는 내용(리소스 또는 범위)과 권한을 부여하거나 거부하기 위해 만족해야 하는 정책을 지정합니다.
1.1.1.3. 정책 시행
정책 적용 에는 리소스 서버에 권한 결정을 실제로 적용하는 데 필요한 단계가 포함됩니다. 권한 부여 서버와 통신할 수 있는 리소스 서버에서 Policy Enforcement Point 또는 PEP를 활성화하고, 권한 부여 데이터를 요청하고, 서버에서 반환된 결정 및 권한에 따라 보호 리소스에 대한 액세스를 제어하도록 함으로써 달성됩니다.
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의 권한 티켓 발급은 전체 승인 프로세스에서 중요한 부분입니다. 후속 섹션에 설명된 대로 클라이언트에서 요청하는 권한을 나타내며 서버로 전송된 권한 및 요청 범위와 연결된 권한 및 정책을 평가하는 동안 부여된 모든 권한이 있는 최종 토큰을 가져옵니다.
추가 리소스
