Omnissa Connect는 애플리케이션에 조직의 보호된 리소스에 대한 위임된 보안 액세스를 제공할 수 있도록 OAuth 2.0을 사용합니다. Omnissa Connect는 애플리케이션 사용자가 액세스 권한을 부여하는 웹 애플리케이션 액세스 및 액세스 토큰이 애플리케이션에 직접 발행되는 서버 간 상호 작용을 지원합니다.
OAuth 2.0이란?
OAuth 2.0은 애플리케이션에 리소스에 대한 보안 액세스 권한 부여할 수 있는 권한 부여 프로토콜입니다. 클라이언트는 액세스 토큰을 통해 권한이 부여됩니다. 액세스 토큰에는 토큰이 액세스할 수 있는 리소스를 정의하는 범위가 있습니다. OAuth 2.0에 대한 자세한 내용은 https://tools.ietf.org/html/rfc6749에서 OAuth 규격을 참조하십시오.
Omnissa Connect에서 OAuth 2.0의 작동 방식
Omnissa Connect는 다양한 권한 부여 유형을 사용하는 애플리케이션 권한 부여를 지원합니다.
- 서버-서버 애플리케이션용 클라이언트 자격 증명
- 웹 애플리케이션용 인증 코드
- 네이티브/모바일 애플리케이션용 권한 코드 방식의 공개 클라이언트
OAuth 애플리케이션에 대한 위반 정책 설명서
OAuth 애플리케이션에 대한 액세스 위반 정책을 생성하는 방법에 대한 자세한 내용은 거버넌스 항목을 참조하십시오.
서버-서버 OAuth 애플리케이션 예시
Omnissa 서비스에 액세스할 수 있는 조직 소유자라고 가정해보겠습니다. 주식 거래에 도움이 되는 애플리케이션을 개발했습니다. 애플리케이션을 Trading 1.0이라고 부릅니다. 다른 Omnissa 서비스를 통해 관리되는 가상 시스템에서 애플리케이션을 실행하려고 하지만, 먼저 조직에서 스크립트를 호스팅하는 위치에 상주하는 API 및 자동화 스크립트를 사용하여 애플리케이션에 권한을 부여해야 합니다.
- Omnissa Connect에서 OAuth 2.0 애플리케이션을 생성합니다.
- 이 시나리오를 Trading 1.0 애플리케이션(Omnissa 관리 가상 머신에서 실행)을 Omnissa Connect(인증 서버)에 등록하는 것으로 생각하십시오.
- Connect의 ID 관리 > OAuth 애플리케이션 > 소유한 애플리케이션 탭에서 새 OAuth 애플리케이션 생성을 선택하고 일련의 단계를 진행하여 애플리케이션 생성을 시작합니다.
- 프로세스가 끝나면 Omnissa Connect가 클라이언트 암호와 클라이언트 ID를 포함하는 클라이언트 자격 증명을 발급합니다.
- 이러한 자격 증명을 자동화 스크립트 내의 API에 붙여넣어 Connect에서 액세스 토큰을 요청합니다.
- Connect에서 애플리케이션에 Omnissa Connect 조직에 대한 액세스 권한을 부여합니다.
- 등록된 애플리케이션인 Trading 1.0을 Omnissa Connect의 조직에 추가하여 액세스 권한을 부여합니다. 이 단계는 추가 과정의 마지막 단계입니다.
- 이렇게 추가하면 조직의 서비스와 리소스에 애플리케이션이 액세스할 수 있습니다.
- Trading 1.0 클라이언트 애플리케이션을 실행하면 권한 부여 서버인 Omnissa Connect에 액세스 토큰을 요청합니다.
- 권한이 부여되면 권한 부여 서버인 Omnissa Connect가 클라이언트 애플리케이션에 액세스 토큰을 전송하고 클라이언트 애플리케이션은 Omnissa 리소스에 대한 액세스를 요청할 수 있습니다.
OAuth 애플리케이션을 생성 및 관리할 수 있는 사람은?
소유자인 사용자 또는 개발자 역할(IGA 고급 기능)을 가진 멤버 사용자는 OAuth 애플리케이션을 생성하고 관리할 수 있습니다.
조직에 있는 다른 소유자가 생성하거나 추가한 OAuth 애플리케이션을 관리할 수도 있습니다.
서버-서버 - 클라이언트 자격 증명
애플리케이션이 사용자 권한 부여 없이 다른 서버에 직접 액세스해야 하는 경우에는 Connect에서 서버-서버 애플리케이션을 생성합니다. 이 옵션은 OAuth 2.0 클라이언트 자격 증명 부여 유형에 기반합니다. 이 흐름에서 애플리케이션은 OAuth 자격 증명을 사용하여 Omnissa Connect에서 액세스 토큰을 검색합니다.
범위 지정
범위 지정은 서버-서버 애플리케이션에서 특히 중요합니다. 범위는 클라이언트가 액세스할 수 있는 조직의 영역, 특히 조직에서의 역할, 서비스 종류와 권한 수준을 제어할 수 있도록 구현하는 방법을 제공합니다.
소유자는 원하는 조직에 서버-서버 애플리케이션을 추가할 수 있습니다. 따라서 많은 서비스에서 애플리케이션에 대한 광범위한 액세스 권한을 지정할 수 있지만, 결국 액세스 권한은 조직에 포함된 서비스에 의해 결정됩니다. 애플리케이션 범위에 포함된 서비스를 포함하지 않는 조직에 OAuth 애플리케이션을 추가하면 알림을 받게 됩니다.
사전 요구 사항
조직에서 OAuth 애플리케이션을 추가하고 관리하는 데 필요한 사용 권한이 있어야 합니다.
절차
- Omnissa Connect에 로그인하고 ID 관리 > OAuth 애플리케이션으로 이동합니다.
- 소유한 애플리케이션 탭을 선택하고 새 OAuth 애플리케이션 생성을 선택합니다.
- 서버-서버 애플리케이션을 선택하고 계속을 선택합니다.
- 이름과 설명을 입력하여 클라이언트를 등록합니다.
- 새 OAuth 애플리케이션의 액세스 토큰 TTL 값을 설정합니다.
액세스 토큰 TTL(Time to Live)은 액세스 토큰이 유효한 기간을 정의합니다.- 기본 액세스 토큰 TTL 시간은 30분입니다.
- 설정할 수 있는 최대 액세스 토큰 TTL 시간은 300분(5시간)입니다.
- 설정할 수 있는 최소 액세스 토큰 TTL 시간은 1분입니다.
- 범위를 정의합니다.
- 범위는 클라이언트가 액세스할 수 있는 조직의 영역, 특히 조직에서의 역할, 서비스 종류와 권한 수준을 제어할 수 있도록 구현하는 방법을 제공합니다.
- 생성을 선택하여 클라이언트 자격 증명을 생성합니다.
- OAuth 애플리케이션 생성됨 팝업 창에서 자격 증명을 복사하거나 JSON 파일을 다운로드하고 계속을 선택합니다.
- 자격 증명을 안전한 장소에 저장하는 것은 사용자의 책임입니다.
- 자동화 스크립트 내에서 애플리케이션의 인증 API에 자격 증명을 붙여넣거나 애플리케이션이 액세스 토큰을 검색하는 데 안전하게 사용할 수 있는 어딘가에 자격 증명 JSON 파일을 안전하게 저장합니다.
- 클라이언트 애플리케이션은 액세스 토큰의 유효성을 검사해야 합니다.
- 유효성 검사 후 애플리케이션은 이제 리소스에 액세스하기 위해 액세스 토큰을 요청할 수 있습니다.
- (선택 사항) Connect에서 애플리케이션을 활성 조직에 추가합니다.
- 이렇게 추가하면 Connect 조직의 서비스와 리소스에 애플리케이션이 액세스할 수 있습니다.
- 이 단계를 건너뛰고 나중에 이 조직 및 다른 조직에 애플리케이션을 추가할 수 있습니다.
웹 애플리케이션 - 인증 코드
애플리케이션이 서버에서 실행되고 사용자 권한 부여가 필요한 일반 웹 애플리케이션이면 Connect에서 웹 애플리케이션을 생성합니다. 이 옵션은 OAuth 2.0 인증 코드 부여 유형에 기반합니다.
이 흐름에서 사용자는 애플리케이션이 인증 코드를 검색하는 인증 요청 URL을 통해 리소스에 액세스하기 전에 애플리케이션에 권한을 부여합니다. 애플리케이션은 인증 코드를 Connect의 액세스 토큰과 교환합니다. 액세스 토큰을 사용하면 사용자가 애플리케이션을 통해 Omnissa 리소스에 액세스할 수 있습니다. 애플리케이션은 선택적으로 Connect에서 새로 고침 토큰을 검색할 수 있습니다.
사전 요구 사항
조직에서 OAuth 애플리케이션을 추가하고 관리하는 데 필요한 사용 권한이 있어야 합니다.
절차
- Omnissa Connect에 로그인하고 ID 관리 > OAuth 애플리케이션으로 이동합니다.
- 소유한 애플리케이션 탭을 선택하고 새 OAuth 애플리케이션 생성을 선택합니다.
- 웹/모바일 애플리케이션을 선택하고 계속을 선택합니다.
- 애플리케이션 세부 정보를 입력하여 애플리케이션을 등록합니다.
- 새 OAuth 애플리케이션의 이름과 설명을 입력합니다.
- 리디렉션 URI를 하나 이상 입력합니다.
- 사용자가 클라이언트에 권한을 부여한 후, 권한 부여 서버는 사용자를 클라이언트에서 액세스 토큰으로 지정한 URI로 다시 리디렉션합니다.
- URI를 둘 이상 추가하는 것이 가장 좋습니다.
- http://acme.com 형식을 사용하십시오.
- 액세스 토큰에 대한 시간 범위를 지정합니다.
- 기본 액세스 토큰 TTL(Time to Live) 설정은 30분입니다.
- 설정할 수 있는 최대값은 300분(5시간)입니다.
- 설정할 수 있는 최소값은 1분입니다.
- 액세스 토큰이 요청에 지속적으로 권한을 부여하도록 하려면 새로 고침 토큰 발행 확인란을 선택하고 새로 고침 토큰 TTL 값을 설정합니다.
- 기본 새로 고침 토큰 TTL은 30분입니다.
- 설정할 수 있는 최대값은 300분(5시간)입니다.
- 설정할 수 있는 최소값은 1분입니다.
- 범위를 정의합니다.
- 범위는 클라이언트가 액세스할 수 있는 조직의 영역, 특히 서비스 종류와 권한 수준을 제어할 수 있도록 구현하는 방법을 제공합니다.
- Open ID 확인란을 선택하여 애플리케이션을 인증하는 사용자에 대한 정보를 가져옵니다.
- 생성을 선택하여 클라이언트 자격 증명을 생성합니다.
- 자격 증명을 복사하거나 자격 증명을 포함하는 JSON 파일을 다운로드합니다.
- 자격 증명을 안전한 장소에 저장하는 것은 사용자의 책임입니다.
- Connect 클라이언트 자격 증명을 애플리케이션의 인증 API에 붙여넣거나, 애플리케이션이 안전하게 사용하여 Connect에서 액세스 토큰과 새로 고침 토큰을 가져올 수 있도록 자격 증명 JSON 파일을 안전한 위치에 저장합니다.
- 계속을 선택합니다.
모바일 애플리케이션 - 권한 코드 방식의 공개 클라이언트
네이티브 및 모바일 애플리케이션과 같은 공용 클라이언트는 클라이언트 암호의 기밀성을 유지할 수 없습니다. 모바일 애플리케이션에 OAuth 2.0을 사용하면 Omnissa Connect에서 애플리케이션 ID를 생성하고 **PKCE(코드 교환용 증명 키)**를 사용하여 추가적인 인증을 제공합니다.
PKCE는 클라이언트 암호를 사용하지 않는 공용 클라이언트를 보호하는 기술입니다. 자세한 내용은 https://datatracker.ietf.org/doc/html/rfc7636에서 OAuth 규격 Proof Key for Code Exchange by OAuth Public Clients를 참조하십시오.
이 흐름에서 사용자는 애플리케이션이 리소스에 접근하기 전에 애플리케이션을 승인하며, 권한 코드를 받기 위해 Connect에서 생성한 애플리케이션 ID를 포함한 권한 요청 URL을 사용해야 합니다. 애플리케이션은 인증 코드를 Connect의 액세스 토큰과 교환합니다. 액세스 토큰을 사용하면 사용자가 애플리케이션을 통해 Omnissa 리소스에 액세스할 수 있습니다. 애플리케이션은 선택적으로 Connect에서 새로 고침 토큰을 검색할 수 있습니다.
사전 요구 사항
이 조직에서 OAuth 애플리케이션을 추가하고 관리하는 데 필요한 사용 권한이 있어야 합니다.
절차
- Omnissa Connect에 로그인하고 ID 관리 > OAuth 애플리케이션으로 이동합니다.
- 소유한 애플리케이션 탭을 선택하고 새 OAuth 애플리케이션 생성을 선택합니다.
- 웹/모바일 애플리케이션을 선택하고 계속을 선택합니다.
- 애플리케이션 세부 정보를 입력하여 애플리케이션을 등록합니다.
- 새 OAuth 애플리케이션의 이름과 설명을 입력합니다.
- 리디렉션 URI를 하나 이상 입력합니다.
- 사용자가 클라이언트에 권한을 부여한 후, 권한 부여 서버는 사용자를 클라이언트에서 액세스 토큰으로 지정한 URI로 다시 리디렉션합니다.
- URI를 둘 이상 추가하는 것이 가장 좋습니다.
- http://acme.com 형식을 사용하십시오.
- 액세스 토큰에 대한 시간 범위를 지정합니다.
- 기본 액세스 토큰 TTL(Time to Live) 설정은 30분입니다.
- 설정할 수 있는 최대값은 300분(5시간)입니다.
- 설정할 수 있는 최소값은 1분입니다.
- 액세스 토큰이 요청에 지속적으로 권한을 부여하도록 하려면 새로 고침 토큰 발행을 선택하고 새로 고침 토큰 TTL 값을 설정합니다.
- 기본 새로 고침 토큰 TTL은 30분입니다.
- 설정할 수 있는 최대값은 300분(5시간)입니다.
- 설정할 수 있는 최소값은 1분입니다.
- 범위를 정의합니다.
- 범위는 클라이언트가 액세스할 수 있는 조직의 영역, 특히 서비스 종류와 권한 수준을 제어할 수 있도록 구현하는 방법을 제공합니다.
- Open ID 확인란을 선택하여 애플리케이션을 인증하는 사용자에 대한 정보를 가져옵니다.
- 생성을 선택하여 자격 증명을 생성합니다.
- 애플리케이션 ID를 복사하거나 애플리케이션 ID가 포함된 JSON 파일을 다운로드합니다.
- 이러한 자격 증명을 안전한 장소에 저장하는 것은 사용자의 책임입니다.
- 애플리케이션 ID를 애플리케이션의 인증 API에 넣거나, 애플리케이션이 안전하게 사용하여 Connect에서 액세스 토큰과 새로 고침 토큰을 가져올 수 있도록 애플리케이션 ID JSON 파일을 안전한 위치에 저장합니다.
- 계속을 선택합니다.
OAuth 2.0 애플리케이션을 관리하는 방법
소유자는 조직에서 OAuth 애플리케이션의 세부 정보를 생성하고 보고 수정합니다. 조직에 있는 다른 소유자가 생성하거나 추가한 OAuth 애플리케이션을 관리할 수도 있습니다. 소유자 역할을 맡고 있는 조직에서 생성된 애플리케이션에 대한 액세스 권한을 부여합니다.
| 원하는 작업 | 수행할 단계 |
|---|---|
| 조직에 액세스할 수 있는 OAuth 애플리케이션을 확인합니다. | - ID 관리 > OAuth 애플리케이션을 선택합니다. - 역할 할당된 애플리케이션 탭에서 조직에 대한 액세스 권한이 있는 다른 조직에서 생성된 애플리케이션을 봅니다. |
| 다른 조직에서 생성된 OAuth 애플리케이션을 추가합니다. | 1. ID 관리 > OAuth 애플리케이션을 선택한 다음, 역할 할당된 애플리케이션 탭을 선택합니다. 2. OAuth 애플리케이션 추가를 선택합니다. 3. 추가할 OAuth 애플리케이션을 식별하려면 애플리케이션 ID 입력 또는 조직으로 검색을 선택합니다. 4. 계속을 선택합니다. 5a. 해당 ID를 사용하여 OAuth 애플리케이션을 식별하도록 선택한 경우 OAuth 애플리케이션 ID를 입력하라는 메시지가 표시됩니다. 5b. OAuth 애플리케이션이 생성된 조직을 통해 해당 애플리케이션을 식별하도록 선택한 경우 먼저 드롭다운 메뉴에서 조직 이름을 선택한 다음 해당 조직에서 사용할 수 있는 OAuth 애플리케이션 목록에서 OAuth 애플리케이션을 선택하라는 메시지가 표시됩니다. 조직 드롭다운 메뉴에는 조직 소유자 액세스 권한이 있는 조직만 표시됩니다. 6. 애플리케이션 세부 정보를 검토하고 추가를 선택합니다. |
| 조직에 액세스할 수 있는 다른 조직에서 생성된 OAuth 애플리케이션을 제거합니다. | 1. ID 관리 > OAuth 애플리케이션을 선택한 다음, 역할 할당된 애플리케이션 탭을 선택합니다. 2. 표시되는 OAuth 애플리케이션 목록에서 조직에 액세스하지 못하게 하려는 애플리케이션을 선택합니다. 3. 제거를 선택합니다. |
| 조직에서 생성된 애플리케이션을 봅니다. | ID 관리 > OAuth 애플리케이션을 선택한 다음, 소유한 애플리케이션 탭을 선택합니다. 그러면 조직에서 생성된 모든 애플리케이션을 볼 수 있습니다. |
| 조직에서 새 OAuth 애플리케이션을 생성합니다. | 1. ID 관리 > OAuth 애플리케이션으로 이동하여 소유한 애플리케이션 탭을 선택합니다. 2. 새 OAuth 애플리케이션 생성을 선택합니다. 3. 추가할 애플리케이션 유형을 선택합니다. |
| 조직에서 생성된 OAuth 애플리케이션을 관리합니다. | ID 관리 > OAuth 애플리케이션을 선택한 다음, 소유한 애플리케이션 탭을 선택합니다. 관리하려는 애플리케이션을 선택합니다. - OAuth 애플리케이션을 수정하려면 편집을 선택합니다. 참고: 애플리케이션의 범위 지정을 변경하는 경우 변경 내용이 다른 조직에 있는 애플리케이션의 인스턴스에 포함되지 않습니다. 범위 지정을 업데이트하려면 소유자가 해당 조직에서 애플리케이션을 제거하고 다시 추가하거나, 업데이트된 범위 지정을 반영하도록 애플리케이션을 편집해야 합니다. - 애플리케이션을 제거하려면 삭제를 선택합니다. 참고: 이 작업은 되돌릴 수 없습니다. 이러한 클라이언트 자격 증명을 사용하는 모든 애플리케이션은 더 이상 보호된 리소스에 액세스할 수 없으며 자격 증명이 무효화됩니다. - 조직에서 생성되었지만 아직 조직에 대한 액세스 권한이 부여되지 않은 서버-서버 애플리케이션을 선택하고 역할 할당을 선택하여 추가합니다. 필요한 경우 애플리케이션 범위에서 허용하는 사용 가능한 조직 및 서비스 역할을 수정한 다음, 추가를 선택합니다. - 먼저 애플리케이션의 범위를 수정하려면 편집을 선택하고 조직 및 서비스 역할에 맞게 변경합니다. 준비가 되면 이 조직에 추가를 선택합니다. 참고: 웹/모바일 애플리케이션을 조직에 추가할 수 없습니다. |
애플리케이션 암호를 다시 생성할 수 있습니까?
예, 소유자는 조직에 있는 OAuth 애플리케이션의 애플리케이션 암호를 다시 생성할 수 있습니다. 이 기능은 OAuth 애플리케이션을 생성한 소유자가 더 이상 비즈니스 엔터프라이즈에 근무하지 않는 경우 애플리케이션을 계속 실행하려고 할 때 유용합니다.
OAuth 애플리케이션 대신 API 토큰 인증을 사용할 수 있습니까?
예, API가 인증 프로세스에서 사용자가 인증된 엔티티일 것을 요구하는 경우 API 토큰을 사용해야 합니다.
OAuth 애플리케이션과 API 토큰의 차이점은?
Omnissa Connect API와의 상호 작용에는 OAuth 애플리케이션과 API 토큰을 모두 사용할 수 있습니다. Connect의 이 IGA 기능에 대한 자세한 내용은 API 토큰을 참조하십시오.
중요: 서비스에 대한 자동화된 호출을 위해 서버-서버 유형의 OAuth 애플리케이션을 사용하려면 먼저 관련 API 설명서를 참조해야 합니다.
API 토큰은 조직의 사용자가 발행하며 사용자의 계정과 API 토큰을 생성한 조직과 연결됩니다. API 토큰은 토큰을 생성한 사용자만 관리할 수 있습니다.
조직의 사용자가 생성한 OAuth 애플리케이션은 서버-서버 상호 작용에서 엔티티로 작동하며 여러 조직에서 사용될 수 있습니다. OAuth 애플리케이션의 소유자는 애플리케이션을 생성한 조직이며, 개발자 역할이 있는 소유자 또는 멤버인 사용자가 관리할 수 있습니다. 역할 요청 관리에 대한 자세한 내용은 요청 항목을 참조하십시오.
OAuth 애플리케이션과 API 토큰을 모두 사용하여 API와 상호 작용하는 프로세스를 자동화할 수 있습니다. 차이점은 API 토큰은 사용자 계정을 액세스 토큰에 통합하지만 OAuth 애플리케이션은 사용자 계정 없이 인증을 수행한다는 것입니다. API 토큰 또는 OAuth 애플리케이션을 사용하여 API 호출을 수행하도록 선택하는 경우 상호 작용에 관련된 API 서비스의 특정 요구 사항을 고려해야 합니다.
일부 API는 사용자 계정이 인증된 엔터티여야 하지만 다른 API는 그렇지 않습니다. 예를 들어, Omnissa Connect에서 조직의 구독 정보를 가져오기 위해 API를 호출할 때, 서버-서버 유형의 OAuth 앱이나 API 토큰을 사용할 수 있습니다. 이는 사용자 자격 증명을 통한 인증이 필요하지 않고, 클라이언트 자격 증명으로도 API 서비스를 호출할 수 있기 때문입니다. 조직의 사용자가 API를 사용하여 암호를 업데이트하는 경우 API를 사용하려면 사용자가 인증 엔티티로 작동해야 합니다.
이 페이지가 도움이 되었나요?