버전 10.4.2부터 VMware Cloud Director를 테넌트 인식 ID 제공자 프록시 서버로 사용할 수 있습니다.
VMware Cloud Director가 OAuth 2.0 OpenID Connect 표준을 사용하여 ID 제공자 프록시 서버로 구성된 경우 신뢰 당사자는 VMware Cloud Director에 알려진 사용자의 테넌트 인식 인증에 VMware Cloud Director를 사용할 수 있습니다. OpenID Connect 표준에 대한 자세한 내용은 OpenID Connect Core 1.0을 참조하십시오.
ID 제공자 프록시 서버인 VMware Cloud Director는 클라이언트 애플리케이션(신뢰 당사자)과 ID 제공자 간의 중개자 역할을 하며 실제 인증을 제공자 또는 테넌트가 사용하는 각 인증 메커니즘에 위임합니다.
시스템 관리자는 VMware Cloud Director와 통합되는 신뢰 당사자를 구성한 다음, 개별 테넌트의 사용자가 VMware Cloud Director를 ID 제공자 프록시로 사용하는 것을 허용하도록 설정할 수 있습니다.
인증 흐름
VMware Cloud Director와의 통합은 OAuth 2.0 OIDC 권한 부여 코드 흐름 표준을 통해 구현됩니다. 자세한 내용은권한 부여 코드 흐름을 사용한 인증을 참조하십시오.
신뢰 당사자가 사용자를 VMware Cloud Director로 리디렉션할 때 기존 클라이언트 세션이 없으면 로그인하려는 조직 또는 제공자 포털을 먼저 식별하여 VMware Cloud Director에 로그인하라는 메시지가 사용자에게 표시됩니다. 사용자는 구성된 인증 메커니즘을 통해 인증하며, 여기에는 외부 ID 제공자로의 추가 리디렉션이 포함될 수 있습니다. 사용자의 브라우저가 기존 VMware Cloud Director 사용자 세션을 감지하는 경우 인증 흐름은 SSO 환경을 제공하며 재인증에는 사용자 상호 작용이 필요하지 않습니다. 프로세스가 성공적으로 완료되면 VMware Cloud Director는 액세스 토큰과 ID 토큰을 반환합니다. 흐름의 일부로 발급된 권한 부여 코드는 5분 동안 유효합니다. 액세스 토큰은 5분간 유효하며 ID 토큰은 1시간 동안 유효합니다.
VMware Cloud Director는 새로 고침 토큰을 반환하지 않습니다.
UI 포털에 액세스하거나 정기적인 VMware Cloud Director API 호출을 수행하기 위한 인증 성공 시 VMware Cloud Director가 반환하는 액세스 토큰을 사용할 수 없습니다.
- ID 토큰 세부 정보
-
VMware Cloud Director가 반환하는 ID 토큰에는 다음과 같은 OpenID 표준 클레임 및 VMware Cloud Director 특정 클레임이 포함됩니다.
클레임
설명
at_hash
(OpenID 표준 클레임) 액세스 토큰 해시 값.
sub
(OpenID 표준 클레임) UUID형식의 VMware Cloud Director의
userId
.iss
(OpenID 표준 클레임) VMware Cloud Director의 공개 주소.
preferred_username
(OpenID 표준 클레임) VMware Cloud Director에서 사용자의 사용자 이름
nonce
(OpenID 표준 클레임) 클라이언트 세션을 ID 토큰과 연결하고 재생 공격을 완화하는 데 사용되는 문자열 값. 처음에 신뢰 당사자 요청에 포함된 경우에만 존재합니다.
aud
(OpenID 표준 클레임) 이 토큰의 대상. 값은 신뢰 당사자를 요청하는 클라이언트 ID입니다.
azp
(OpenID 표준 클레임) 토큰에 대한 권한이 부여된 당사자. 값은 신뢰 당사자의 클라이언트 ID입니다. 이 값은
aud
클레임과 동일합니다.name
(OpenID 표준 클레임) 사용자의 전체 이름(VMware Cloud Director에 알려진 경우).
phone_number
(OpenID 표준 클레임) 사용자의 전화번호(VMware Cloud Director에 알려진 경우).
exp
(OpenID 표준 클레임) 만료 시간. ID 토큰이 처리에 허용되지 않는 시간입니다.
iat
(OpenID 표준 클레임) ID 토큰이 발급된 시간.
email
(OpenID 표준 클레임) 사용자의 이메일 주소(VMware Cloud Director에 알려진 경우)
roles
(VMware Cloud Director 사용자 지정 클레임) VMware Cloud Director에서 사용자가 갖는 역할의 이름 어레이.
groups
(VMware Cloud Director 사용자 지정 클레임) VMware Cloud Director에서 사용자가 속한 그룹의 이름 어레이.
org_name
(VMware Cloud Director 사용자 지정 클레임) 사용자가 로그인한 조직의 이름.
org_display_name
(VMware Cloud Director 사용자 지정 클레임) 조직의 표시 이름.
org_id
(VMware Cloud Director 사용자 지정 클레임) UUID 형식의 조직 ID.
- OpenID 요청 범위
-
OpenID 요청 범위는 액세스 토큰에 대해 요청된 권한을 지정하는 데 사용됩니다.
범위 값
설명.
openid
필수. OpenID 표준 범위입니다.
profile
OpenID 표준 범위입니다. 최종 사용자 기본 프로파일 클레임에 대한 액세스를 요청합니다.
email
OpenID 표준 범위입니다. 최종 사용자 이메일 주소 클레임에 대한 액세스를 요청합니다.
groups
OpenID 표준 범위입니다. 사용자가 VMware Cloud Director에 속한 그룹에 대한 액세스를 요청합니다.
phone
OpenID 표준 범위입니다. 사용자 전화번호 클레임에 대한 액세스를 요청합니다.
vcd_idp
VMware Cloud Director 특정 범위.
roles
,groups
,org_name
,org_display_name
및org_id
와 같은 VMware Cloud Director 사용자 지정 클레임에 대한 액세스를 요청합니다. - 끝점
-
VMware Cloud Director에서 반환된 액세스 토큰을 사용하여
hostname/oidc/UserInfo
끝점에서 인증된 사용자에 대한 클레임을 검색할 수 있습니다. 자세한 내용은 UserInfo 끝점을 참조하십시오.잘 알려진 구성 URL
hostname/oidc/.well-known/openid-configuration
에서 JWKS 끝점을 포함한 제공자 구성 값과 OIDC 프록시 구성에 필요한 기타 끝점 및 범위에 대한 정보를 검색할 수 있습니다. OIDC 프록시 일반 설정 보기의 내용을 참조하십시오.
VMware Cloud Director ID 제공자 프록시에 대한 토큰 교환 액세스
VMware Cloud Director의 ID 제공자 프록시 기능과의 프로그래밍 방식 통합은 아래에 설명된 토큰 교환 흐름을 통해 사용할 수 있습니다. 이 흐름에는 VMware Cloud Director UI가 포함되지 않으며 스크립팅된 액세스(예: CLI)에 적합합니다.
직접 로그인하거나 API 토큰을 사용하여 VMware Cloud Director JWT를 가져옵니다.
POST 요청을 실행합니다.
POST hostname/oidc/oauth2/token
요청 본문에 대해
x-www-form-urlencoded
를 선택합니다.요청 본문에 다음 매개 변수를 포함합니다.
{ "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer", "assertion": "VMware_Cloud_Director JWT", "client_id": "Relying_party_ID", "scope": "openid profile email phone groups vcd_idp", }
응답은 OIDC 및 VMware Cloud Director 클레임이 포함된 ID 토큰과
hostname/oidc/UserInfo
끝점에서 인증된 사용자에 대한 클레임을 검색하는 데 사용할 수 있는 액세스 토큰을 둘 다 반환합니다.
인코딩된 ID 토큰 예:
eyJhbGciOiJSUzI1NiIsInR5NDg4SI6I................4dHnbU1RQ6Y9Yohgw
디코딩된 ID 토큰 예:
{ "at_hash": "1AA1aAA1AAAAAAaAA1A11a", "sub": "111111111-1111-1111-1111-11111111", "roles": [ "Organization Administrator" ], "iss": "https://hostname/oidc", "groups": [ "ALL USERS" ], "preferred_username": "testuser@vcd-ms1", "nonce": "ab123acab", "aud": "33333333-3333-3333-3333-33333333333", "azp": "22222222-2222-2222-2222-22222222", "org_id": "12345678-1234-1234-1234-123456789abc", "org_display_name": "oidcorg", "name": "test user", "phone_number": " ", "exp": 1111111111, "org_name": "oidcorg", "iat": 1111111111, "email": "[email protected]" }
사용자 정보 응답 예:
{ "sub": "111111111-1111-1111-1111-11111111", "preferred_username": "administrator", "name": "administrator user", "email": "[email protected]", "phone_number": "0 (111) 222-3333", "roles": [ "system administrator" ], "groups": [], "org_name": "system", "org_display_name": "System Organization", "org_id": "12345678-1234-1234-1234-123456789abc" }
다중 사이트 고려 사항
다중 사이트 배포에서 각 사이트는 단일 ID 제공자 서버로 작동합니다.
쌍으로 구성된 사이트는 페더레이션된 ID 서버 지원을 제공하지 않습니다. 즉, 로그인 프로세스 중에 ID 제공자 프록시로 작동하는 사이트에 속하지 않은 테넌트가 다중 사이트 배포의 다른 사이트에 대한 조직 선택을 통해 로그인하려고 하면 로그인이 실패합니다.