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
curl -X GET \
http://${host}:${port}/my-resource-server/resource/1bfdfe78-a4e1-4c2d-b142-fc92b75b986f
리소스 서버는 권한 티켓이
있는 클라이언트에 다시 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"
HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="${realm}",
as_uri="https://${host}:${port}/auth/realms/${realm}",
ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
권한 티켓은 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}
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}
Red Hat Single Sign-On 평가 프로세스에서 사용 권한 발급을 초래하는 경우 권한이 연결된 RPT를 발행합니다.
Red Hat Single Sign-On은 RPT로 클라이언트에 응답
HTTP/1.1 200 OK Content-Type: application/json ... { "access_token": "${rpt}", }
HTTP/1.1 200 OK
Content-Type: application/json
...
{
"access_token": "${rpt}",
}
서버의 응답은 다른 권한 부여 유형을 사용하는 경우 토큰 끝점의 다른 응답과 동일합니다. 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" }
HTTP/1.1 403 Forbidden
Content-Type: application/json
...
{
"error": "access_denied",
"error_description": "request_denied"
}
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" }
HTTP/1.1 403 Forbidden
Content-Type: application/json
...
{
"error": "access_denied",
"error_description": "request_denied"
}
이러한 응답은 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"
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"
submit_request
매개변수를 사용하는 경우 Red Hat Single Sign-On은 액세스가 거부된 각 리소스에 대한 권한 요청을 유지합니다. 리소스 소유자가 생성되면 계정을 확인하고 권한 요청을 관리할 수 있습니다.
이 기능은 사용자가 다른 사용자에게 해당 리소스에 대한 액세스 권한을 요청할 수 있는 요청
액세스 버튼으로 생각할 수 있습니다.
8.3.3. 사용자 리소스에 대한 액세스 관리
사용자는 Red Hat Single Sign-On 사용자 계정 서비스를 사용하여 리소스에 대한 액세스를 관리할 수 있습니다. 이 기능을 활성화하려면 먼저 해당 영역에 대해 User-Managed Access를 활성화해야 합니다.
절차
- 관리 콘솔에 로그인합니다.
- 메뉴에서 CloudEvent Settings 을 클릭합니다.
사용자 관리 액세스 를 ON 으로 전환합니다.
메뉴 옵션에서 My Resources 를 클릭합니다. 다음 옵션을 사용하여 페이지가 표시됩니다.
승인이 필요한권한 요청 관리
이 섹션에는 승인을 기다리는 모든 권한 요청 목록이 포함되어 있습니다. 이러한 요청은 특정 리소스에 대한 액세스를 요청하는 당사자(사용자)에 연결됩니다. 사용자는 이러한 요청을 승인하거나 거부할 수 있습니다.
내 리소스관리
이 섹션에는 사용자가 소유한 모든 리소스 목록이 포함되어 있습니다. 사용자는 보다 자세한 내용을 위해 리소스를 클릭하고 다른 사용자와 리소스를 공유할 수 있습니다.
나와 공유되는 리소스관리
이 섹션에는 사용자와 공유하는 모든 리소스 목록이 포함되어 있습니다.
승인 대기 중인 요청관리
이 섹션에는 다른 사용자 또는 리소스 소유자의 승인을 기다리는 사용자가 보낸 권한 요청 목록이 포함되어 있습니다.
변경할 특정 리소스를 클릭하면 다음 페이지가 표시됩니다.
이 페이지에서는 다음 옵션을 제공합니다.
이 리소스에 대한 액세스 권한이 있는 role관리
이 섹션에는 이 리소스에 액세스할 수 있는 사용자 목록이 포함되어 있습니다. 사용자는
Revoke
버튼을 클릭하거나 특정권한
을 제거하여 액세스를 취소할 수 있습니다.다른 사용자와 리소스 공유
다른 사용자의 사용자 이름 또는 이메일을 입력하면 사용자가 리소스를 공유하고 액세스 권한을 부여하려는 권한을 선택할 수 있습니다.