기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
SAML OpenSearch 대시보드에 대한 인증
SAML OpenSearch Dashboards 인증을 사용하면 기존 자격 증명 공급자를 사용하여 OpenSearch 또는 Elasticsearch 6.7 이상을 실행하는 Amazon OpenSearch Service 도메인의 Dashboards에 대한 Single Sign-On(SSO)을 제공할 수 있습니다. SAML 인증을 사용하려면 세분화된 액세스 제어 를 활성화해야 합니다.
OpenSearch Dashboards SAML 인증은 Amazon Cognito 또는 내부 사용자 데이터베이스를 통해 인증하는 대신 타사 자격 증명 공급자를 사용하여 대시보드에 로그인하고, 세분화된 액세스 제어를 관리하고, 데이터를 검색하고, 시각화를 구축할 수 있습니다. OpenSearch 서비스는 Okta, Keycloak, Active Directory Federation Services(ADFS), Auth0 및 와 같은 SAML 2.0 표준을 사용하는 공급자를 지원합니다 AWS IAM Identity Center.
SAML 대시보드 인증은 웹 브라우저를 통해 OpenSearch 대시보드에 액세스하는 경우에만 적용됩니다. SAML 자격 증명으로 인해 OpenSearch 또는 대시보드에 직접 HTTP 요청할 수 없습니다APIs.
SAML 구성 개요
이 설명서에서는 기존 ID 제공업체가 있고 어느 정도 익숙하다고 가정합니다. 정확한 공급자에 대한 자세한 구성 단계는 제공할 수 없으며 OpenSearch 서비스 도메인에 대해서만 제공할 수 있습니다.
OpenSearch 대시보드 로그인 흐름은 다음 두 가지 형식 중 하나를 취할 수 있습니다.
-
서비스 공급자(SP)가 시작됨: Dashboards로 이동하면(예:
https://), 로그인 화면으로 리디렉션됩니다. 로그인하면 자격 증명 공급자가 사용자를 Dashboards로 리디렉션합니다.my-domain.us-east-1.es.amazonaws.com/_dashboards -
자격 증명 공급자(IdP ) 시작됨: 자격 증명 공급자로 이동하여 로그인한 다음 애플리케이션 디렉터리에서 OpenSearch 대시보드를 선택합니다.
OpenSearch 서비스는 URLsSP 시작 및 IdP 시작의 두 가지 Single Sign-On을 제공하지만 원하는 OpenSearch Dashboards 로그인 흐름과 일치하는 로그인 흐름만 필요합니다.
사용하는 인증 유형에 관계없이 목표는 자격 증명 공급자를 통해 로그인하고 사용자 이름(필수)과 백엔드 역할(선택 사항이지만 권장됨)이 포함된 SAML어설션을 수신하는 것입니다. 이 정보를 통해 세분화된 액세스 제어를 통해 SAML 사용자에게 권한을 할당할 수 있습니다. 외부 자격 증명 공급자의 백엔드 역할은 일반적으로 “역할” 또는 “그룹”이라고 합니다.
고려 사항
SAML 인증을 구성할 때 다음 사항을 고려하세요.
-
IdP 메타데이터 파일의 크기로 인해 콘솔을 AWS 사용하여 SAML 인증을 구성하는 것이 좋습니다.
-
도메인은 한 번에 하나의 Dashboards 인증 방법만 지원합니다. OpenSearch 대시보드에 대한 Amazon Cognito 인증을 활성화한 경우 인증을 활성화하려면 먼저 SAML 해당 인증을 비활성화해야 합니다.
-
에서 네트워크 로드 밸런서를 사용하는 경우 먼저 사용자 지정 엔드포인트를 생성SAML해야 합니다. 자세한 내용은 Amazon OpenSearch Service에 대한 사용자 지정 엔드포인트 만들기 단원을 참조하십시오.
-
비IAM 자격 증명(Amazon OpenSearch Serverless SAML 및 Amazon OpenSearch ServiceSAML에 대한 기본 내부 사용자 권한 부여)의 경우 서비스 제어 정책(SCP)이 적용되거나 평가되지 않습니다.
SAML VPC 도메인에 대한 인증
SAML 는 자격 증명 공급자와 서비스 공급자 간의 직접 통신이 필요하지 않습니다. 따라서 OpenSearch 도메인이 프라이빗 내에서 호스팅되더라도 브라우저VPC가 OpenSearch 클러스터 및 자격 증명 공급자와 통신할 수 있는 SAML 한 를 사용할 수 있습니다. 브라우저는 본질적으로 자격 증명 공급자와 서비스 공급자 간의 중개자 역할을 수행합니다. SAML 인증 흐름을 설명하는 유용한 다이어그램은 Okta 설명서
도메인 액세스 정책 수정
SAML 인증을 구성하기 전에 사용자가 도메인에 액세스할 수 있도록 도메인 SAML 액세스 정책을 업데이트해야 합니다. 그렇지 않으면 액세스 거부 오류가 표시됩니다.
도메인의 하위 리소스(/*)에 대한 전체 액세스를 제공하는 다음 도메인 액세스 정책을 권장합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
정책을 더 제한적으로 만들기 위해 정책에 IP 주소 조건을 추가할 수 있습니다. 이 조건은 지정된 IP 주소 범위 또는 서브넷으로만 액세스를 제한합니다. 예를 들어 다음 정책은 192.0.2.0/24 서브넷에서만 액세스를 허용합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "domain-arn/*" } ] }
참고
개방형 도메인 액세스 정책을 사용하려면 도메인에서 세분화된 액세스 제어를 활성화해야 합니다. 그렇지 않으면 다음 오류가 표시됩니다.
To protect domains with public access, a restrictive policy or fine-grained
access control is required.
강력한 암호로 구성된 마스터 사용자 또는 내부 사용자가 있는 경우 세분화된 액세스 제어를 사용하는 동안 개방형 정책으로 유지해도 보안 관점에서 허용될 수 있습니다. 자세한 내용은 Amazon OpenSearch Service에서 세분화된 액세스 제어 단원을 참조하십시오.
SP 및 IdP 시작 인증 구성
이 단계에서는 OpenSearch Dashboards에 대한 SP 시작 또는 IdP 시작 SAML 인증을 사용하여 인증을 활성화하는 방법을 설명합니다. 둘 다 활성화하는 데 필요한 추가 단계는 SP 및 IdP 시작 인증 모두 구성을 참조하세요.
1단계: SAML 인증 활성화
도메인 생성 중에 또는 기존 도메인에서 작업 , 보안 구성 편집을 선택하여 SAML 인증을 활성화할 수 있습니다. 다음 단계는 선택 사항에 따라 약간 다릅니다.
도메인 구성의 SAML OpenSearch Dashboards/Kibana 인증에서 SAML 인증 활성화를 선택합니다.
2단계: ID 제공업체 구성
SAML 인증을 구성하는 시기에 따라 다음 단계를 수행합니다.
새 도메인을 생성하는 경우
새 도메인을 생성하는 경우 OpenSearch 서비스는 아직 서비스 공급자 엔터티 ID 또는 SSO 를 생성할 수 없습니다URLs. 자격 증명 공급자가 SAML 인증을 제대로 활성화하려면 이러한 값이 필요하지만 도메인이 생성된 후에만 생성할 수 있습니다. 도메인을 생성하는 동안 이러한 상호 종속성을 해결하기 위해 IdP 구성에 임시 값을 제공하여 필요한 메타데이터를 생성한 다음 도메인이 활성화되면 업데이트할 수 있습니다.
사용자 지정 엔드포인트 를 사용하는 경우 URLs가 무엇인지 추론할 수 있습니다. 예를 들어 사용자 지정 엔드포인트가 인 경우 www.서비스 공급자 엔터티 ID는 custom-endpoint.comwww.이고, IdP 시작SSOURL은 이고custom-endpoint.comwww., SP 시작SSOURL은 입니다custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiatedwww.. 도메인이 생성되기 전에 값을 사용하여 ID 제공업체를 구성할 수 있습니다. 예는 다음 단원을 참조하십시오.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs
참고
요청FQDN의 이 HTTP 요청FQDN의 와 다르기 때문에 듀얼 스택 엔드포인트로 로그인할 수 없습니다SAML. 듀얼 스택 엔드포인트를 사용하여 로그인하려면 OpenSearch 관리자가 사용자 지정 엔드포인트를 설정하고 CNAME 값을 듀얼 스택 엔드포인트로 설정해야 합니다.
사용자 지정 엔드포인트를 사용하지 않는 경우 IdP에 임시 값을 입력하여 필요한 메타데이터를 생성한 다음 나중에 도메인이 활성화된 후 업데이트할 수 있습니다.
예를 들어 Okta 내에서 https:// Single Sign on URL 및 AudienceURI(SP Entity ID) 필드에 를 입력하여 메타데이터를 생성할 수 있습니다. 그런 다음 도메인이 활성화되면 OpenSearch 서비스에서 올바른 값을 검색하고 Okta에서 업데이트할 수 있습니다. 지침은 6단계: IdP 업데이트 URLs 단원을 참조하십시오.temp-endpoint.amazonaws.com
기존 도메인을 편집하는 경우
기존 도메인에서 SAML 인증을 활성화하는 경우 서비스 공급자 엔터티 ID와 중 하나를 복사합니다SSOURLs. 사용할 항목에 대한 지침은 섹션을 참조URL하세요SAML 구성 개요.
값을 사용하여 ID 제공업체를 구성합니다. 이것이 프로세스의 가장 복잡한 부분이며 안타깝게도 용어와 단계는 공급자에 따라 크게 다릅니다. 공급자의 설명서를 참조하세요.
예를 들어 Okta에서는 SAML 2.0 웹 애플리케이션을 생성합니다. Single Sign on URL의 경우 SSO 를 지정합니다URL. 대상URI(SP 엔터티 ID)에 SP 엔터티 ID를 지정합니다.
Okta에는 사용자 및 백엔드 역할이 아니라 사용자와 그룹이 있습니다. Group Attribute Statements(그룹 속성 문)의 경우 Name(이름) 필드에 role을 추가하고 Filter(필터) 필드에 정규식 .+를 추가하는 것이 좋습니다. 이 문은 Okta 자격 증명 공급자에 사용자가 인증한 후 어SAML설션 role 필드 아래에 모든 사용자 그룹을 포함하도록 지시합니다.
IAM Identity Center에서 SP 엔터티 ID를 애플리케이션 SAML 대상 로 지정합니다. 또한 다음과 같은 속성 매핑 Subject=${user:subject}:format=unspecified 및 Role=${user:groups}:format=uri을 지정해야 합니다.
Auth0에서는 일반 웹 애플리케이션을 생성하고 SAML 2.0 추가 기능을 활성화합니다. Keycloak에서는 클라이언트를 생성합니다.
3단계: IdP 메타데이터 가져오기
자격 증명 공급자를 구성하면 IdP 메타데이터 파일이 생성됩니다. 이 XML 파일에는 TLS 인증서, Single Sign-On 엔드포인트 및 자격 증명 공급자의 엔터티 ID와 같은 공급자에 대한 정보가 포함되어 있습니다.
IdP 메타데이터 파일의 내용을 복사하여 OpenSearch 서비스 콘솔의 IdP에서 메타데이터 필드에 붙여 넣습니다. 또는 XML 파일에서 가져오기를 선택하고 파일을 업로드합니다. 메타데이터 파일은 다음과 같아야 합니다.
<?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>tls-certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/> </md:IDPSSODescriptor> </md:EntityDescriptor>
4단계: SAML 필드 구성
IdP 메타데이터를 입력한 후 OpenSearch 서비스 콘솔 내에서 다음과 같은 추가 필드를 구성합니다.
-
IdP entity ID(IdP 엔터티 ID) – 메타데이터 파일에서
entityID속성 값을 복사하여 이 필드에 붙여 넣습니다. 또한 많은 자격 증명 공급자는 사후 구성 요약의 일부로 이 값을 표시합니다. 일부 공급자는 이를 “발행자”라고 부릅니다. -
SAML 마스터 사용자 이름 및 SAML 마스터 백엔드 역할 - 지정한 사용자 및/또는 백엔드 역할은 새 마스터 사용자 와 동등한 클러스터에 대한 전체 권한을 받지만 OpenSearch 대시보드 내에서만 해당 권한을 사용할 수 있습니다.
예를 들어 Okta에는
admins그룹에 속한 사용자jdoe가 있을 수 있습니다. SAML 마스터 사용자 이름 필드에jdoe를 추가하는 경우 해당 사용자만 전체 권한을 받습니다. SAML 마스터 백엔드 역할 필드에admins를 추가하면admins그룹에 속한 모든 사용자에게 전체 권한이 부여됩니다.참고
어SAML설션의 내용은 SAML 마스터 사용자 이름 및 SAML 마스터 역할에 사용하는 문자열과 정확히 일치해야 합니다. 일부 자격 증명 공급자는 사용자 이름 앞에 접두사를 추가하여 hard-to-diagnose 불일치를 일으킬 수 있습니다. 자격 증명 공급자 사용자 인터페이스에는 가 표시될 수 있지만
jdoeSAML어설션에는 이 포함될 수 있습니다auth0|jdoe. 항상 SAML어설션의 문자열을 사용합니다.
많은 자격 증명 공급자가 구성 프로세스 중에 샘플 어설션을 볼 수 있게 해주며, SAML-tracer
<?xml version="1.0" encoding="UTF-8"?> <saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer> <saml2:Subject> <saml2:NameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_dashboards/_opendistro/_security/saml/acs"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z"> <saml2:AudienceRestriction> <saml2:Audience>domain-endpoint</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive) </saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion>
5단계: (선택 사항) 추가 설정 구성
Additional settings(추가 설정)에서 다음 선택적 필드를 구성합니다.
-
제목 키 - 이 필드를 비워 두고 사용자 이름에 대한 어SAML설션
NameID요소를 사용할 수 있습니다. 어설션에서 이 표준 요소를 사용하지 않고 사용자 이름을 사용자 지정 속성으로 포함하는 경우 여기에 해당 속성을 지정합니다. -
Roles key(역할 키) - 백엔드 역할(권장)을 사용하려는 경우 이 필드에 어설션의 속성을 지정합니다(예:
role또는group). 이는 SAML-tracer와 같은 도구가 도움이 될 수 있는 또 다른 상황입니다. -
세션 라이브 시간 - 기본적으로 OpenSearch Dashboards는 24시간 후에 사용자를 로그아웃합니다. 새 값을 지정하여 이 값을 60에서 1,440(24시간) 사이의 임의의 숫자로 구성할 수 있습니다.
구성에 만족하면 도메인을 저장합니다.
6단계: IdP 업데이트 URLs
도메인 생성 중에 SAML 인증을 활성화한 경우 XML 메타데이터 파일을 생성하려면 IdP URLs 내에서 임시 를 지정해야 했습니다. 도메인 상태가 로 변경되면 올바른 를 가져오URLs고 IdP 를 수정할 Active수 있습니다.
를 검색하려면 도메인을 선택하고 작업 , 보안 구성 편집 URLs을 선택합니다. SAML OpenSearch Dashboards/Kibana 인증에서 올바른 서비스 공급자 엔터티 ID 및 SSO 를 찾을 수 있습니다URLs. 값을 복사하고 사용하여 자격 증명 공급자를 구성하고 2단계에서 제공한 임시 값을 대체URLs합니다.
7단계: 역할에 SAML 사용자 매핑
도메인 상태가 활성이고 IdP가 올바르게 구성되면 OpenSearch 대시보드로 이동합니다.
-
SP 시작 을 선택한 경우 로 URL이동합니다
domain-endpoint/_dashboards?security_tenant=에 추가할 수 있습니다URL.tenant-name -
IdP 시작 을 선택한 경우 자격 증명 공급자의 애플리케이션 디렉터리로 URL이동합니다.
두 경우 모두 SAML 마스터 사용자 또는 SAML 마스터 백엔드 역할에 속한 사용자로 로그인합니다. 7단계의 예제를 계속하려면 jdoe 또는 admins 그룹의 멤버로 로그인합니다.
OpenSearch 대시보드가 로드되면 보안 , 역할 을 선택합니다. 그런 다음 역할을 매핑하여 다른 사용자가 OpenSearch 대시보드에 액세스할 수 있도록 허용합니다.
예를 들어 신뢰할 수 있는 동료 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에서 다음 단계를 수행할 수 있습니다.
-
SAML 애플리케이션 내에서 일반 , SAML 설정 으로 이동합니다.
-
Single Sign on URL의 경우 IdP 시작 SSO 을 제공합니다URL. 예:
https://search-.domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated -
이 앱이 다른 SSO 를 요청하도록 허용URLs을 활성화합니다.
-
요청 가능 SSO URLs에서 SP가 시작한 SSO 을 하나 이상 추가합니다URLs. 예:
https://search-.domain-hash/_dashboards/_opendistro/_security/saml/acs
SAML 인증 구성(AWS CLI)
다음 AWS CLI 명령은 기존 도메인에서 OpenSearch 대시보드에 대한 SAML 인증을 활성화합니다.
aws opensearch update-domain-config \ --domain-namemy-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. 예를 들어, <KeyDescriptor use="signing">와 줄 바꿈 대신 <KeyDescriptor use=\"signing\">\n을 사용합니다. 사용에 대한 자세한 내용은 AWS CLI 명령 참조를 AWS CLI참조하세요.
SAML 인증 구성(구성API)
구성에 대한 다음 요청은 기존 도메인에서 OpenSearch 대시보드에 대한 SAML 인증을 API 활성화합니다.
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. 예를 들어, <KeyDescriptor use="signing">와 줄 바꿈 대신 <KeyDescriptor use=\"signing\">\n을 사용합니다. 구성 사용에 대한 자세한 내용은 OpenSearch 서비스 API 참조를 API참조하세요.
SAML 문제 해결
| 오류 | Details |
|---|---|
|
자격 증명 제공업체에 올바른 SSO URL (3단계)를 제공했는지 확인합니다. |
|
|
IdP 메타데이터 파일이 SAML 2.0 표준을 준수하지 않습니다. 유효성 검사 도구를 사용하여 오류를 확인하세요. |
|
SAML 구성 옵션은 콘솔에 표시되지 않습니다. |
최신 서비스 소프트웨어로 업데이트하세요. |
|
|
이 일반 오류는 여러 가지 이유로 발생할 수 있습니다.
|
|
|
성공적으로 인증되었지만 어SAML설션의 사용자 이름과 백엔드 역할은 어떤 역할에도 매핑되지 않으므로 권한이 없습니다. 이러한 매핑은 대/소문자를 구분합니다. 시스템 관리자는 SAML-tracer
|
|
브라우저는 OpenSearch 대시보드에 액세스하려고 할 때 지속적으로 HTTP 리디렉션되거나 500개의 오류를 수신합니다. |
이러한 오류는 SAML어설션에 총 약 1,500자의 많은 역할이 포함된 경우 발생할 수 있습니다. 예를 들어 평균 길이가 20자인 80개의 역할을 전달하면 웹 브라우저에서 쿠키의 크기 제한을 초과할 수 있습니다. OpenSearch 버전 2.7부터 SAML어설션은 최대 5,000자의 역할을 지원합니다. |
|
에서 로그아웃할 수 없습니다ADFS. |
ADFS 에서는 모든 로그아웃 요청에 서명하도록 요구하며, OpenSearch 서비스에서는 지원하지 않습니다. IdP 메타데이터 파일 |
|
|
XML OpenSearch 서비스에 대한 메타데이터에 제공된 IdP의 엔터티 ID가 SAML 응답의 엔터티 ID와 다릅니다. 이 문제를 해결하려면 두 항목이 일치하는지 확인하세요. 도메인에서 CW Application Error 로그를 활성화하여 SAML 통합 문제를 디버깅하는 오류 메시지를 찾습니다. |
|
|
OpenSearch 서비스에서 메타데이터 에 제공된 IdP의 인증서를 사용하여 SAML 응답의 서명을 확인할 수 없습니다XML. 수동 오류이거나 IdP가 인증서를 교체한 것일 수 있습니다. 를 통해 OpenSearch 서비스에 XML 제공된 메타데이터의 IdP에서 최신 인증서를 업데이트합니다 AWS Management Console. |
|
|
SAML 응답의 대상 필드가 도메인 엔드포인트와 일치하지 않습니다. 이 오류를 해결하려면 SP 대상 필드를 도메인 엔드포인트와 일치하도록 업데이트하세요. 사용자 지정 엔드포인트를 활성화한 경우 대상 필드는 사용자 지정 엔드포인트와 일치해야 합니다. 도메인에서 CW Application Error 로그를 활성화하여 SAML 통합 문제를 디버깅하는 오류 메시지를 찾습니다. |
|
브라우저가 응답 |
이 오류는 일반적으로 형식으로 IdP -initiatedURL를 구성한 경우에 발생합니다 |
|
|
SAML 응답의 대상 필드가 다음 URL 형식 중 하나와 일치하지 않습니다.
사용하는 로그인 흐름(SP 시작 또는 IdP 시작)에 따라 중 하나와 일치하는 대상 필드에 를 입력합니다 OpenSearch URLs. |
|
응답에는 |
SP 시작 로그인 흐름에 URL 대해 IdP 시작을 사용 중입니다. URL 대신 SP 시작을 사용합니다. |
SAML 인증 비활성화
OpenSearch 대시보드에 대한 SAML 인증을 비활성화하려면(콘솔)
-
도메인을 선택하고 [작업(Actions)], [보안 구성 편집(Edit security configuration)]을 선택합니다.
-
SAML 인증 활성화 를 선택 취소합니다.
-
Save changes(변경 사항 저장)를 선택합니다.
-
도메인이 처리를 마친 후 다음 요청으로 세분화된 액세스 제어 역할 매핑을 확인합니다.
GET _plugins/_security/api/rolesmapping대시보드에 대한 SAML 인증을 비활성화해도 SAML 마스터 사용자 이름 및/또는 SAML 마스터 백엔드 역할에 대한 매핑은 제거되지 않습니다. 이러한 매핑을 제거하려면 내부 사용자 데이터베이스(활성화된 경우)를 사용하여 대시보드에 로그인하거나 API를 사용하여 제거합니다.
PUT _plugins/_security/api/rolesmapping/all_access{ "users": [ "master-user" ] }
