기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # OpenSearch 대시보드에 대한 SAML 인증 OpenSearch 대시보드에 대한 SAML 인증을 사용하면 기존 자격 증명 공급자를 사용하여 OpenSearch 또는 Elasticsearch 6.7 이상을 실행하는 Amazon OpenSearch Service 도메인의 대시보드에 통합 인증(SSO)을 제공할 수 있습니다. SAML 인증을 사용하려면 [세분화된 액세스 제어](fgac.md)를 활성화해야 합니다. [Amazon Cognito](cognito-auth.md) 또는 [내부 사용자 데이터베이스](fgac.md#fgac-dashboards)를 통해 인증하는 대신 OpenSearch 대시보드에 대한 SAML 인증을 사용하면 타사 자격 증명 공급자를 사용하여 대시보드에 로그인하고 세분화된 액세스 제어를 관리하고 데이터를 검색하고 시각화를 구축할 수 있습니다. OpenSearch Service는 Okta, Keycloak, Active Directory Federation Services(ADFS), Auth0, 등 SAML 2.0 표준을 사용하는 공급자를 지원합니다 AWS IAM Identity Center. 대시보드에 대한 SAML 인증은 웹 브라우저를 통해 OpenSearch 대시보드에 액세스하는 용도로만 사용됩니다. SAML 자격 증명을 사용하면 OpenSearch 또는 Dashboards API에 직접 HTTP 요청을 할 수 *없습니다*. ## SAML 구성 개요 이 설명서에서는 기존 ID 제공업체가 있고 어느 정도 익숙하다고 가정합니다. OpenSearch Service 도메인의 경우에만 정확한 공급자에 대한 자세한 구성 단계를 제공할 수 없습니다. OpenSearch 대시보드 로그인 흐름은 다음 두 가지 형식 중 하나를 취할 수 있습니다. + **서비스 공급자(SP)가 시작됨**: Dashboards로 이동하면(예: `https://my-domain.us-east-1.es.amazonaws.com/_dashboards`), 로그인 화면으로 리디렉션됩니다. 로그인하면 자격 증명 공급자가 사용자를 Dashboards로 리디렉션합니다. + **ID 제공업체(idP)가 시작됨**: 자격 증명 공급자로 이동하여 로그인한 다음 애플리케이션 디렉터리에서 OpenSearch 대시보드를 선택합니다. OpenSearch Service는 SP가 시작한 URL과 IdP가 시작한 두 개의 통합 인증(SSO) URL을 제공하지만 원하는 OpenSearch 대시보드 로그인 흐름과 일치하는 URL만 있으면 됩니다. 사용하는 인증 유형과 관계없이 자격 증명 공급자를 통해 로그인하고 사용자 이름(필수) 및 [백엔드 역할](fgac.md#fgac-concepts)(선택 사항이지만 권장함)을 포함한 SAML 어설션을 받는 것이 목적입니다. 이 정보를 통해 [세분화된 액세스 제어](fgac.md)로 SAML 사용자에게 권한을 할당할 수 있습니다. 외부 자격 증명 공급자의 백엔드 역할은 일반적으로 “역할” 또는 “그룹”이라고 합니다. ## 고려 사항 SAML 인증을 구성할 때 다음 사항을 고려하세요. + IdP 메타데이터 파일의 크기 때문에 AWS 콘솔을 사용하여 SAML 인증을 구성할 것을 적극 권장합니다. + 도메인은 한 번에 하나의 Dashboards 인증 방법만 지원합니다. [OpenSearch 대시보드에 대한 Amazon Cognito 인증](cognito-auth.md)을 활성화한 경우 SAML 인증을 활성화하기 전에 이 기능을 먼저 비활성화해야 합니다. + SAML과 함께 Network Load Balancer를 사용하는 경우 먼저 사용자 지정 엔드포인트를 생성해야 합니다. 자세한 내용은 [Amazon OpenSearch Service에 대한 사용자 지정 엔드포인트 만들기](customendpoint.md) 단원을 참조하십시오. + 서비스 제어 정책(SCP)은 IAM이 아닌 자격 증명(Amazon OpenSearch Serverless의 SAML 및 SAML과 Amazon OpenSearch Service의 기본 내부 사용자 권한 부여)의 경우 적용되거나 평가되지 않습니다. ## VPC 도메인에 대한 SAML 인증 SAML은 ID 제공업체와 서비스 제공업체 간에 직접 통신이 필요하지 않습니다. 따라서 OpenSearch 도메인이 프라이빗 VPC 내에서 호스팅되는 경우에도 브라우저가 OpenSearch 클러스터 및 자격 증명 공급자 모두와 통신할 수 있는 한 SAML을 계속 사용할 수 있습니다. 브라우저는 본질적으로 자격 증명 공급자와 서비스 공급자 간의 중개자 역할을 수행합니다. SAML 인증 흐름을 설명하는 유용한 다이어그램은 [Okta 설명서](https://developer.okta.com/docs/concepts/saml/#planning-for-saml)를 참조하세요. ## 도메인 액세스 정책 수정 SAML 인증을 구성하기 전에 SAML 사용자가 도메인에 액세스할 수 있도록 도메인 액세스 정책을 업데이트해야 합니다. 그렇지 않으면 액세스 거부 오류가 표시됩니다. 도메인의 하위 리소스(`/*`)에 대한 전체 액세스를 제공하는 다음 [도메인 액세스 정책](ac.md#ac-types-resource)을 권장합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ 정책을 더 제한적으로 만들기 위해 정책에 IP 주소 조건을 추가할 수 있습니다. 이 조건은 지정된 IP 주소 범위 또는 서브넷으로만 액세스를 제한합니다. 예를 들어 다음 정책은 192.0.2.0/24 서브넷에서만 액세스를 허용합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ **참고** 개방형 도메인 액세스 정책을 사용하려면 도메인에서 세분화된 액세스 제어를 활성화해야 합니다. 그렇지 않으면 다음 오류가 표시됩니다. `To protect domains with public access, a restrictive policy or fine-grained access control is required.` 강력한 암호로 구성된 마스터 사용자 또는 내부 사용자가 있는 경우 세분화된 액세스 제어를 사용하는 동안 개방형 정책으로 유지해도 보안 관점에서 허용될 수 있습니다. 자세한 내용은 [Amazon OpenSearch Service에서 세분화된 액세스 제어](fgac.md) 단원을 참조하십시오. ## SP 및 IdP 시작 인증 구성 이 단계에서는 OpenSearch 대시보드에 대해 SP 시작 *또는* IdP 시작 인증으로 SAML 인증을 사용 설정하는 방법을 설명합니다. 둘 다 활성화하는 데 필요한 추가 단계는 [SP 및 IdP 시작 인증 모두 구성](#saml-idp-with-sp)을 참조하세요. ### 1단계: SAML 인증 활성화 도메인 생성 중에 또는 기존 도메인에서 **Actions**(작업), **Edit security configuration**(보안 구성 편집)을 선택하여 SAML 인증을 활성화할 수 있습니다. 다음 단계는 선택 사항에 따라 약간 다릅니다. 도메인 구성 내의 **SAML authentication for OpenSearch 대시보드/Kibana**(OpenSearch 대시보드/Kibana에 대한 SAML 인증) 아래에서 **Enable SAML authentication**(SAML 인증 활성화)을 선택합니다. ### 2단계: ID 제공업체 구성 SAML 인증을 구성하는 시기에 따라 다음 단계를 수행하세요. #### 새 도메인을 생성하는 경우 새 도메인을 생성하는 중이라면 OpenSearch Service는 아직 서비스 제공업체 엔터티 ID 또는 SSO URL을 생성할 수 없습니다. ID 제공업체에서 SAML 인증을 제대로 활성화하려면 이러한 값이 필요하지만 도메인이 생성된 후에만 해당 값을 생성할 수 있습니다. 도메인을 생성하는 동안 이러한 상호 종속성을 해결하기 위해 IdP 구성에 임시 값을 제공하여 필요한 메타데이터를 생성한 다음 도메인이 활성화되면 업데이트할 수 있습니다. [사용자 지정 엔드포인트](customendpoint.md)를 사용하는 경우 URL이 무엇인지 유추할 수 있습니다. 예를 들어 사용자 지정 엔드포인트가 `www.custom-endpoint.com`인 경우 서비스 제공업체 엔터티 ID는 `www.custom-endpoint.com`, IdP 시작 SSO URL은 `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated`, SP 시작 SSO URL은 `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs`이 됩니다. 도메인이 생성되기 전에 값을 사용하여 ID 제공업체를 구성할 수 있습니다. 예는 다음 단원을 참조하십시오. **참고** HTTP 요청의 FQDN이 SAML 요청의 FQDN과 다르므로 이중 스택 엔드포인트로 로그인할 수 없습니다. 이중 스택 엔드포인트를 사용하여 로그인하려는 경우 OpenSearch 관리자가 사용자 지정 엔드포인트를 설정하고 CNAME 값을 이중 스택 엔드포인트로 설정해야 합니다. 사용자 지정 엔드포인트를 사용하지 않는 경우 IdP에 **임시 값을 입력하여 필요한 메타데이터를 생성한 다음 나중에 도메인이 활성화된 후 업데이트할 수 있습니다. 예를 들어 Okta 내에서 **Single sign on URL**(Single Sign-On URL) 필드와 **Audience URI (SP Entity ID)**(대상 URI(SP 엔터티 ID)) 필드에 `https://temp-endpoint.amazonaws.com`을 입력하면 메타데이터를 생성할 수 있습니다. 그런 다음 도메인이 활성화되면 올바른 값을 OpenSearch Service에서 검색하고 Okta에서 업데이트할 수 있습니다. 지침은 [6단계: IdP URL 업데이트](#saml-update-urls) 섹션을 참조하세요. #### 기존 도메인을 편집하는 경우 기존 도메인에서 SAML 인증을 활성화하는 경우 서비스 제공업체 엔터티 ID와 SSO URL 중 하나를 복사합니다. 사용할 URL에 대한 지침은 [SAML 구성 개요](#saml-overview)을 참조하세요. ![\[Service provider entity ID and SSO URLs for SAML authentication configuration.\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/images/SAML.png) 값을 사용하여 ID 제공업체를 구성합니다. 이것이 프로세스의 가장 복잡한 부분이며 안타깝게도 용어와 단계는 공급자에 따라 크게 다릅니다. 공급자의 설명서를 참조하세요. 예를 들어 Okta에서는 SAML 2.0 웹 애플리케이션을 생성합니다. **Single sign on URL**(Single Sign-On URL)에 SSO URL을 지정합니다. **대상 Audience(SP 엔터티 ID)(Audience URI(SP Entity ID))**에 SP 엔티티 ID를 지정합니다. Okta에는 사용자 및 백엔드 역할이 아니라 사용자와 그룹이 있습니다. **Group Attribute Statements**(그룹 속성 문)의 경우 **Name**(이름) 필드에 `role`을 추가하고 **Filter**(필터) 필드에 정규식 `.+`를 추가하는 것이 좋습니다. 이 문은 Okta 자격 증명 공급자에 사용자가 인증한 후 SAML 어설션의 `role` 필드에서 모든 사용자 그룹을 포함하도록 지시합니다. IAM ID 센터에서 SP 엔티티 ID를 **Application SAML 대상**으로 지정합니다. 또한 다음과 같은 [속성 매핑](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html) `Subject=${user:subject}:format=unspecified` 및 `Role=${user:groups}:format=uri`을 지정해야 합니다. Auth0에서는 일반 웹 애플리케이션을 생성하고 SAML 2.0 추가 기능을 활성화합니다. Keycloak에서는 클라이언트를 생성합니다. ### 3단계: IdP 메타데이터 가져오기 자격 증명 공급자를 구성하면 IdP 메타데이터 파일이 생성됩니다. 이 XML 파일에는 TLS 인증서, 통합 인증 엔드포인트 및 자격 증명 공급자의 엔터티 ID와 같은 공급자에 대한 정보가 들어 있습니다. IdP 메타데이터 파일의 내용을 복사하여 OpenSearch Service 콘솔의 **IdP 메타데이터** 필드에 붙여넣습니다. 또는 **XML 파일에서 가져오기(Import from XML file)**를 선택하고 파일을 업로드합니다. 메타데이터 파일은 다음과 같아야 합니다. ``` tls-certificate urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ``` ### 4단계: SAML 필드 구성 IdP 메타데이터를 입력한 후 OpenSearch Service 콘솔 내에서 다음 추가 필드를 구성합니다. + **IdP entity ID**(IdP 엔터티 ID) – 메타데이터 파일에서 `entityID` 속성 값을 복사하여 이 필드에 붙여 넣습니다. 또한 많은 자격 증명 공급자는 사후 구성 요약의 일부로 이 값을 표시합니다. 일부 공급자는 이를 “발행자”라고 부릅니다. + **SAML master username**(SAML 마스터 사용자 이름) 및 **SAML master backend role**(SAML 마스터 백엔드 역할) – 지정한 사용자 및/또는 백엔드 역할은 [새 마스터 사용자](fgac.md#fgac-more-masters)와 동등한 클러스터에 대한 전체 권한을 받지만 OpenSearch 대시보드 내에서만 해당 권한을 사용할 수 있습니다. 예를 들어 Okta에는 `admins` 그룹에 속한 사용자 `jdoe`가 있을 수 있습니다. `jdoe`를 **SAML 마스터 사용자 이름** 필드에서 추가할 경우, 해당 사용자만 모든 권한을 받습니다. `admins`를 SAML 마스터 백엔드 역할 필드에 추가할 경우, `admins` 그룹에 속한 모든 사용자가 모든 권한을 받습니다. **참고** SAML 어설션의 내용은 SAML 마스터 사용자 이름 및 SAML 마스터 역할에 사용하는 문자열과 정확히 일치해야 합니다. 일부 자격 증명 공급자는 사용자 이름 앞에 접두사를 추가하여 진단하기 어려운 불일치가 발생할 수 있습니다. 자격 증명 공급자 사용자 인터페이스에 `jdoe`가 보일 수 있지만 SAML 어설션은 `auth0|jdoe`를 포함할 수 있습니다. SAML 어설션에서 항상 문자열을 사용합니다. 많은 자격 증명 공급자를 사용하면 구성 프로세스 중에 샘플 어설션을 볼 수 있으며 [SAML 추적기](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)와 같은 도구는 실제 어설션의 내용을 검사하고 문제를 해결하는 데 도움이 될 수 있습니다. 어설션은 다음과 같습니다. ``` idp-issuer username domain-endpoint urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport GroupName Match Matches regex ".+" (case-sensitive) ``` ### 5단계: (선택 사항) 추가 설정 구성 **Additional settings**(추가 설정)에서 다음 선택적 필드를 구성합니다. + **Subject key**(제목 키) - 사용자 이름에 대한 SAML 어설션의 `NameID` 요소를 사용하려면 이 필드를 비워 둡니다. 어설션에서 이 표준 요소를 사용하지 않고 사용자 이름을 사용자 지정 속성으로 포함하는 경우 여기에 해당 속성을 지정합니다. + **Roles key**(역할 키) - 백엔드 역할(권장)을 사용하려는 경우 이 필드에 어설션의 속성을 지정합니다(예: `role` 또는 `group`). 이것은 [SAML 추적기](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)와 같은 도구가 도움이 될 수 있는 또 다른 상황입니다. + **Session time to live**(세션 TTL(Time To Live)) - 기본적으로 OpenSearch 대시보드는 24시간 후에 사용자를 로그아웃합니다. 새 값을 지정하여 이 값을 60에서 1,440(24시간) 사이의 임의의 숫자로 구성할 수 있습니다. 구성에 만족하면 도메인을 저장합니다. ### 6단계: IdP URL 업데이트 [도메인을 생성하는 동안 SAML 인증을 활성화](#saml-configure-new)한 경우 XML 메타데이터 파일을 생성하기 위해 IdP 내에서 임시 URL을 지정해야 했습니다. 도메인 상태가 `Active`로 변경되면 올바른 URL을 가져오고 IdP를 수정할 수 있습니다. URL을 검색하려면 도메인을 선택하고 **Actions**(작업), **Edit security configuration**(보안 구성 편집)을 선택합니다. **SAML authentication for OpenSearch 대시보드/Kibana**(OpenSearch 대시보드/Kibana에 대한 SAML 인증)에서 올바른 서비스 제공업체 엔터티 ID와 SSO URL을 찾을 수 있습니다. 값을 복사하고 이를 사용하여 ID 제공업체를 구성하고 2단계에서 제공한 임시 URL을 바꿉니다. ### 7단계: 역할에 SAML 사용자 매핑 도메인 상태가 활성이고 IdP가 올바르게 구성되었으면 OpenSearch 대시보드로 이동하세요. + SP가 시작한 URL을 선택한 경우 `domain-endpoint/_dashboards`로 이동합니다. 특정 테넌트에 직접 로그인하려면 URL에 `?security_tenant=tenant-name`을 추가합니다. + IdP가 시작한 URL을 선택한 경우 자격 증명 공급자의 애플리케이션 디렉터리로 이동합니다. 두 경우 모두 SAML 마스터 사용자나 SAML 마스터 백엔드 역할에 속한 사용자로 로그인합니다. 7단계의 예제를 계속하려면 `jdoe` 또는 `admins` 그룹의 멤버로 로그인합니다. OpenSearch 대시보드가 로드된 후 **Security**(보안), **Roles**(역할)를 선택합니다. 그런 다음 다른 사용자가 OpenSearch 대시보드에 액세스할 수 있도록 [역할을 매핑](fgac.md#fgac-mapping)합니다. 예를 들어 신뢰할 수 있는 동료 `jroe`를 `all_access` 및 `security_manager` 역할에 매핑할 수 있습니다. 백엔드 역할 `analysts`를 `readall` 및`opensearch_dashboards_user` 역할에 매핑할 수도 있습니다. OpenSearch 대시보드 대신 API를 사용하려는 경우 다음 샘플 요청을 참조하세요. ``` PATCH _plugins/_security/api/rolesmapping [ { "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] } }, { "op": "add", "path": "/opensearch_dashboards_user", "value": { "backend_roles": ["analysts"] } } ] ``` ## SP 및 IdP 시작 인증 모두 구성 SP와 IdP가 시작한 인증을 모두 구성하려면 자격 증명 공급자를 통해 인증을 구성해야 합니다. 예를 들어 Okta에서 다음 단계를 수행할 수 있습니다. 1. SAML 애플리케이션 내에서 **General**(일반)의 **SAML settings**(SAML 설정)로 이동합니다. 1. **단일 인증 URL(Single sign on URL)**에서 *IdP* 시작 SSO URL을 제공합니다. 예를 들어 `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated`입니다. 1. **이 앱이 다른 SSO URL을 요청하도록 허용(Allow this app to request other SSO URLs)**을 사용 설정합니다. 1. **요청 가능한 SSO URL(Requestable SSO URLs)**에서 *SP* 시작 SSO URL을 하나 이상 추가합니다. 예를 들어 `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs`입니다. ## SAML 인증 구성(AWS CLI) 다음 AWS CLI 명령은 기존 도메인에서 OpenSearch Dashboards에 대한 SAML 인증을 활성화합니다. ``` aws opensearch update-domain-config \ --domain-name my-domain \ --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}' ``` 메타데이터 XML의 모든 따옴표와 줄 바꿈 문자를 이스케이프해야 합니다. 예를 들어, ``와 줄 바꿈 대신 `\n`을 사용합니다. AWS CLI사용에 대한 자세한 내용은 [AWS CLI 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/)를 참조하세요. ## SAML 인증 구성(구성 API) 구성 API에 대한 다음 요청은 기존 도메인의 OpenSearch 대시보드에 대한 SAML 인증을 활성화합니다. ``` POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config { "AdvancedSecurityOptions": { "SAMLOptions": { "Enabled": true, "MasterUserName": "my-idp-user", "MasterBackendRole": "my-idp-group-or-role", "Idp": { "EntityId": "entity-id", "MetadataContent": "metadata-content-with-quotes-escaped" }, "RolesKey": "optional-roles-key", "SessionTimeoutMinutes": 180, "SubjectKey": "optional-subject-key" } } } ``` 메타데이터 XML의 모든 따옴표와 줄 바꿈 문자를 이스케이프해야 합니다. 예를 들어, ``와 줄 바꿈 대신 `\n`을 사용합니다. 구성 API 사용에 대한 자세한 내용은 [OpenSearch Service API 참조](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html)를 확인하세요. ## SAML 문제 해결 | 오류 | 세부 정보 | | --- | --- | | 요청: '*/some/path*'는 허용되지 않습니다. | 자격 증명 공급자에게 올바른 [SSO URL](#saml-enable)(3단계)을 제공했는지 확인하세요. | | SAML을 활성화하려면 유효한 자격 증명 제공자 메타데이터 문서를 제공하세요. | IdP 메타데이터 파일이 SAML 2.0 표준을 준수하지 않습니다. 유효성 검사 도구를 사용하여 오류를 확인하세요. | | SAML 구성 옵션은 콘솔에 표시되지 않습니다. | 최신 [서비스 소프트웨어](service-software.md)로 업데이트하세요. | | SAML 구성 오류: SAML 구성을 검색하는 동안 문제가 발생했습니다. 설정을 확인하세요. | 이 일반 오류는 여러 가지 이유로 발생할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/saml.html) | | 역할 누락: 이 사용자에게 사용할 수 있는 역할이 없습니다. 시스템 관리자에게 문의하세요. | 성공적으로 인증되었지만 SAML 어설션의 사용자 이름 및 백엔드 역할은 어떤 역할에도 매핑되지 않으므로 권한이 없습니다. 이러한 매핑은 대/소문자를 구분합니다. [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)와 같은 도구를 사용하여 SAML 어설션의 콘텐츠를 확인하고 다음 요청을 사용하여 역할 매핑을 확인합니다. 
GET _plugins/_security/api/rolesmapping
| | 브라우저가 OpenSearch 대시보드에 액세스하려고 할 때 HTTP 500 오류를 지속해서 리디렉션하거나 수신합니다. | SAML 어설션에 총 1,500자 정도의 많은 역할이 포함된 경우 이러한 오류가 발생할 수 있습니다. 예를 들어 평균 길이가 20자인 80개의 역할을 전달하면 웹 브라우저에서 쿠키의 크기 제한을 초과할 수 있습니다. OpenSearch 버전 2.7부터 SAML 어설션은 최대 5000자의 역할을 지원합니다. | | ADFS에서 로그아웃할 수 없습니다. | ADFS에서는 OpenSearch Service가 지원하지 않는 모든 로그아웃 요청에 서명해야 합니다. OpenSearch Service가 자체 내부 로그아웃 메커니즘을 사용하도록 하려면 IdP 메타데이터 파일에서 ``를 제거합니다. | | `Could not find entity descriptor for __PATH__.` | 메타데이터 XML에서 OpenSearch Service에 제공된 IdP의 엔티티 ID가 SAML 응답의 엔티티 ID와 다릅니다. 이 문제를 해결하려면 두 항목이 일치하는지 확인하세요. 도메인에서 **CW 애플리케이션 오류 로그**를 활성화하여 SAML 수집 문제를 디버깅하는 데 필요한 오류 메시지를 찾으십시오. | | `Signature validation failed. SAML response rejected.` | OpenSearch Service는 메타데이터 XML에 제공된 IdP의 인증서를 사용하여 SAML 응답의 서명을 확인할 수 없습니다. 수동 오류이거나 IdP가 인증서를 교체한 것일 수 있습니다. AWS Management Console를 통해 OpenSearch Service에 제공된 메타데이터 XML에서 IdP의 최신 인증서를 업데이트합니다. | | `__PATH__ is not a valid audience for this response.` | SAML 응답의 대상 필드가 도메인 엔드포인트와 일치하지 않습니다. 이 오류를 해결하려면 SP 대상 필드를 도메인 엔드포인트와 일치하도록 업데이트하세요. 사용자 지정 엔드포인트를 활성화한 경우 대상 필드는 사용자 지정 엔드포인트와 일치해야 합니다. 도메인에서 **CW 애플리케이션 오류 로그**를 활성화하여 SAML 수집 문제를 디버깅하는 데 필요한 오류 메시지를 찾으십시오. | | 브라우저에 응답 내 `Invalid Request Id`과 함께 HTTP 400 오류가 수신됩니다. | 이 오류는 일반적으로 IdP에서 시작하는 URL을 `/_opendistro/_security/saml/acs` 형식으로 구성한 경우에 발생합니다. 대신 `/_opendistro/_security/saml/acs/idpinitiated` 형식으로 URL을 구성하세요. | | `__PATH__` 대신 `__PATH__`에서 응답을 받았습니다. | SAML 응답의 대상 필드가 다음 URL 형식 중 하나와 일치하지 않습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/saml.html) 사용하는 로그인 흐름(SP 시작 또는 IDP 시작)에 따라 OpenSearch URL 중 하나와 일치하는 대상 필드를 입력합니다. | | 응답에는 `InResponseTo` 속성이 있지만 `InResponseTo`은 예상되지 않았습니다. | SP에서 시작한 로그인 흐름에 IdP에서 시작한 URL을 사용하고 있습니다. SP에서 시작한 URL을 대신 사용하세요. | ## SAML 인증 비활성화 **OpenSearch 대시보드에 대한 SAML 인증을 비활성화하려면(콘솔)** 1. 도메인을 선택하고 [**작업(Actions)**], [**보안 구성 편집(Edit security configuration)**]을 선택합니다. 1. **SAML 인증 활성화(Enable SAML authentication)**를 선택 취소합니다. 1. **변경 사항 저장**을 선택합니다. 1. 도메인이 처리를 마친 후 다음 요청으로 세분화된 액세스 제어 역할 매핑을 확인합니다. ``` GET _plugins/_security/api/rolesmapping ``` Dashboards에 대한 SAML 인증을 비활성화하면 SAML 마스터 사용자 이름 및/또는 SAML 마스터 백엔드 역할에 대한 매핑을 제거하지 *않습니다*. 이러한 매핑을 제거하려면 내부 사용자 데이터베이스(활성화된 경우)를 사용하여 Dashboards에 로그인하거나 API를 사용하여 제거합니다. ``` PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] } ```