SAML OpenSearch 대시보드 인증

SAML OpenSearch 대시보드 인증을 사용하면 기존 ID 공급자를 사용하여 Elasticsearch 6.7 OpenSearch 이상을 실행하는 OpenSearch Amazon Service 도메인에서 대시보드에 싱글 사인온 (SSO) 을 제공할 수 있습니다. SAML인증을 사용하려면 세분화된 액세스 제어를 활성화해야 합니다.

Amazon Cognito나 내부 사용자 데이터베이스를 통해 인증하는 대신 대시보드 인증을 사용하면 타사 ID 공급자를 사용하여 대시보드에 로그인하고SAML, 세분화된 액세스 제어를 관리하고, 데이터를 OpenSearch 검색하고, 시각화를 구축할 수 있습니다. OpenSearch 서비스는 Okta, Keycloak, Active Directory 페더레이션 서비스 (), Auth0 및 같이 SAML 2.0 표준을 사용하는 공급자를 지원합니다. ADFS AWS IAM Identity Center.

SAML대시보드 인증은 웹 브라우저를 통해 대시보드에 액세스하는 OpenSearch 용도로만 사용됩니다. SAML자격 증명으로는 OpenSearch 또는 대시보드에 직접 HTTP 요청할 수 없습니다. APIs

SAML구성 개요

이 설명서에서는 기존 ID 제공업체가 있고 어느 정도 익숙하다고 가정합니다. 정확한 공급자에 대한 세부 구성 단계는 제공할 수 없으며 OpenSearch 서비스 도메인에 대해서만 제공할 수 있습니다.

OpenSearch 대시보드 로그인 흐름은 다음 두 가지 형식 중 하나를 취할 수 있습니다.

OpenSearch 이 서비스는 SP 개시 및 IdP 개시 방식의 두 가지 싱글 사인온을 제공하지만 원하는 대시보드 로그인 URLs 흐름과 일치하는 로그인만 있으면 됩니다. OpenSearch

어떤 인증 유형을 사용하든 목표는 ID 공급자를 통해 로그인하여 사용자 이름 (필수) 과 백엔드 역할 (선택 사항이지만 권장됨) 이 포함된 SAML 어설션을 받는 것입니다. 이 정보를 통해 세분화된 액세스 제어를 통해 사용자에게 권한을 할당할 수 있습니다. SAML 외부 자격 증명 공급자의 백엔드 역할은 일반적으로 “역할” 또는 “그룹”이라고 합니다.

고려 사항

인증을 구성할 때 다음 사항을 고려하십시오. SAML

SAML도메인 인증 VPC

SAMLID 공급자와 서비스 제공업체 간에 직접 통신할 필요가 없습니다. 따라서 OpenSearch 도메인이 VPC 사설에 호스팅되더라도 브라우저가 OpenSearch 클러스터 및 ID 제공자 모두와 통신할 수 있는 한 계속 사용할 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/*"
    }
  ]
}

SP 및 IdP 시작 인증 구성

이 단계에서는 대시보드에 대해 SP에서 시작한 SAML 인증 또는 IDP에서 시작한 인증을 사용하여 인증을 활성화하는 방법을 설명합니다. OpenSearch 둘 다 활성화하는 데 필요한 추가 단계는 SP 및 IdP 시작 인증 모두 구성을 참조하세요.

SAML1단계: 인증 활성화

도메인을 생성하는 동안 또는 작업, 기존 도메인의 보안 구성 편집을 선택하여 SAML 인증을 활성화할 수 있습니다. 다음 단계는 선택 사항에 따라 약간 다릅니다.

도메인 구성 내의 OpenSearch 대시보드/Kibana SAML 인증에서 인증 활성화를 선택합니다. SAML

2단계: ID 제공업체 구성

인증을 구성하는 시기에 따라 다음 단계를 수행하십시오. SAML

새 도메인을 생성하는 경우

새 도메인을 생성하는 중이라면 서비스는 아직 OpenSearch 서비스 제공업체 개체 ID 또는 를 생성할 수 없습니다 SSOURLs. ID 공급자가 SAML 인증을 제대로 활성화하려면 이러한 값이 필요하지만 도메인이 생성된 후에만 생성할 수 있습니다. 도메인을 생성하는 동안 이러한 상호 종속성을 해결하기 위해 IdP 구성에 임시 값을 제공하여 필요한 메타데이터를 생성한 다음 도메인이 활성화되면 업데이트할 수 있습니다.

사용자 지정 엔드포인트를 사용하는 경우 어떻게 URLs 될지 추론할 수 있습니다. 예를 들어 사용자 지정 엔드포인트가 인 경우 서비스 공급자 엔티티 ID는 www.custom-endpoint.com IdP 개시 IDwww.custom-endpoint.com, SP 개시 ID는 SSO URL SP 개시 ID가 SSO URL 됩니다www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated. www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs 도메인이 생성되기 전에 값을 사용하여 ID 제공업체를 구성할 수 있습니다. 예는 다음 단원을 참조하십시오.

사용자 지정 엔드포인트를 사용하지 않는 경우 IdP에 임시 값을 입력하여 필요한 메타데이터를 생성한 다음 나중에 도메인이 활성화된 후 업데이트할 수 있습니다.

예를 들어 Okta 내에서 싱글 사인온 URL 및 Audience URI (SP https://temp-endpoint.amazonaws.com Entity ID) 필드에 입력하여 메타데이터를 생성할 수 있습니다. 그러면 도메인이 활성화되면 OpenSearch Service에서 올바른 값을 검색하고 Okta에서 업데이트할 수 있습니다. 지침은 6단계: IdP 업데이트 URLs 단원을 참조하십시오.

기존 도메인을 편집하는 경우

기존 도메인에서 SAML 인증을 활성화하려면 서비스 제공업체 엔티티 ID와 그 중 하나를 복사하세요. SSO URLs 사용 지침은 URL 을 참조하십시오SAML구성 개요.

값을 사용하여 ID 제공업체를 구성합니다. 이것이 프로세스의 가장 복잡한 부분이며 안타깝게도 용어와 단계는 공급자에 따라 크게 다릅니다. 공급자의 설명서를 참조하세요.

예를 들어 Okta에서는 SAML 2.0 웹 애플리케이션을 만듭니다. 싱글 사인온의 URL 경우 를 지정합니다. SSO URL 대상 URI (SP 개체 ID) 의 경우 SP 개체 ID를 지정합니다.

Okta에는 사용자 및 백엔드 역할이 아니라 사용자와 그룹이 있습니다. Group Attribute Statements(그룹 속성 문)의 경우 Name(이름) 필드에 role을 추가하고 Filter(필터) 필드에 정규식 .+를 추가하는 것이 좋습니다. 이 명령문은 사용자가 인증한 후 SAML 어설션 role 필드 아래에 모든 사용자 그룹을 포함하도록 Okta ID 공급자에게 지시합니다.

IAMIdentity 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 제공자의 엔티티 ID 등 공급자에 대한 정보가 들어 있습니다.

IdP 메타데이터 파일의 내용을 복사하여 서비스 콘솔의 IdP의 메타데이터 필드에 붙여넣습니다. OpenSearch 또는 파일에서 가져오기를 선택하고 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 서비스 콘솔에서 다음과 같은 추가 필드를 구성합니다.

많은 ID 제공자를 통해 구성 프로세스 중에 샘플 어설션을 볼 수 있으며 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:NameID Format="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(추가 설정)에서 다음 선택적 필드를 구성합니다.

구성에 만족하면 도메인을 저장합니다.

6단계: IdP 업데이트 URLs

도메인을 생성할 때 SAML 인증을 활성화한 경우 XML 메타데이터 파일을 생성하려면 IdP URLs 내에 임시 도메인을 지정해야 했습니다. 도메인 상태가 로 Active 변경되면 올바른 IdP를 URLs 얻고 수정할 수 있습니다.

를 URLs 검색하려면 도메인을 선택하고 작업, 보안 구성 편집을 선택합니다. OpenSearch 대시보드/Kibana SAML 인증에서 올바른 서비스 공급자 엔티티 ID 및 를 찾을 수 있습니다. SSO URLs 값을 복사하고 이를 사용하여 ID 공급자를 구성하고 2단계에서 제공한 임시 URLs 값을 대체합니다.

7단계: SAML 사용자를 역할에 매핑

도메인 상태가 Active이고 IdP가 올바르게 구성되면 대시보드로 이동합니다 OpenSearch .

두 경우 모두 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 구성 (AWS CLI)

다음과 같습니다. AWS CLI 명령을 사용하면 기존 도메인의 OpenSearch 대시보드 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 예를 들어, <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문제 해결

GET _plugins/_security/api/rolesmapping

인증 비활성화 SAML