OAuth 2.0은 보호된 리소스에 대한 액세스를 제어하기 위한 권한 부여 프레임워크입니다. 이 점을 감안하면 모든 배포에서 중요한 첫 단계는 사용 가능한 리소스가 무엇이고 어떤 클라이언트가 액세스할 필요가 있는지 확인하는 것입니다.

REST API 호출을 실행할 때 OAuth 2.0을 사용할 클라이언트와 이들이 액세스해야 하는 API 엔드포인트를 결정해야 합니다.

REST 역할 및 로컬 사용자를 포함하여 기존 ONTAP ID 정의를 검토해야 합니다. OAuth 2.0을 구성하는 방법에 따라 이러한 정의를 액세스 결정에 사용할 수 있습니다.

OAuth 2.0 인증을 점진적으로 구현할 수도 있지만 각 인증 서버에 대한 글로벌 플래그를 설정하여 모든 REST API 클라이언트를 OAuth 2.0으로 즉시 이동할 수도 있습니다. 따라서 자체 포함된 범위를 만들 필요 없이 기존 ONTAP 구성을 기반으로 액세스 결정을 내릴 수 있습니다.

권한 부여 서버는 액세스 토큰을 발행하고 관리 정책을 시행함으로써 OAuth 2.0 배포에서 중요한 역할을 수행합니다.

하나 이상의 인증 서버를 선택하여 설치해야 합니다. 범위를 정의하는 방법을 비롯하여 ID 공급자의 구성 옵션 및 절차를 숙지하는 것이 중요합니다. Microsoft Entra ID를 비롯한 일부 인증 서버는 이름 대신 UUID를 사용하여 그룹을 나타냅니다.

ONTAP는 인증 서버의 인증서를 사용하여 클라이언트가 제공하는 서명된 액세스 토큰의 유효성을 검사합니다. 이렇게 하려면 ONTAP에서 루트 CA 인증서와 모든 중간 인증서가 필요합니다. ONTAP와 함께 사전 설치되어 있을 수 있습니다. 그렇지 않은 경우 설치해야 합니다.

인증 서버가 방화벽 뒤에 있는 경우 프록시 서버를 사용하도록 ONTAP를 구성해야 합니다.

클라이언트 인증 및 권한 부여에는 몇 가지 측면을 고려해야 합니다.

상위 수준에서는 권한 부여 서버에서 정의된 자체 포함 범위를 정의하거나 역할 및 사용자를 비롯한 기존 로컬 ONTAP ID 정의를 사용할 수 있습니다.

ONTAP ID 정의를 사용하는 경우 다음을 포함하여 적용할 항목을 결정해야 합니다.

액세스 토큰의 유효성을 ONTAP에서 로컬로 검사할지, 아니면 자체 검사를 통해 인증 서버에서 검사할지 결정해야 합니다. 또한 새로 고침 간격과 같이 고려해야 할 여러 관련 값도 있습니다.

높은 수준의 보안이 필요한 환경에서는 MTL을 기반으로 보내기 제한 액세스 토큰을 사용할 수 있습니다. 이렇게 하려면 각 클라이언트에 대한 인증서가 필요합니다.

UUID를 사용하여 그룹을 나타내는 인증 서버를 사용하는 경우 그룹 이름 및 연결된 역할에 매핑하는 방법을 계획해야 합니다.

다음을 비롯한 모든 ONTAP 인터페이스를 통해 OAuth 2.0을 관리할 수 있습니다.

클라이언트 응용 프로그램은 권한 부여 서버에서 직접 액세스 토큰을 요청해야 합니다. 허가 유형을 포함하여 이 작업을 수행하는 방법을 결정해야 합니다.

몇 가지 ONTAP 구성 작업을 수행해야 합니다.

인증 구성에 따라 로컬 ONTAP 식별 처리를 사용할 수 있습니다. 이 경우 REST 역할 및 사용자 정의를 검토하고 정의해야 합니다. 또한 인증 서버에 따라 UUID 값을 기반으로 하는 관리 그룹이 포함될 수도 있습니다.

핵심 ONTAP 구성을 수행하는 데 필요한 주요 단계는 다음과 같습니다.