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 Access 및 UMA 사양을 참조하십시오.