本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# OpenSearch Dashboards 的 SAML 身分驗證
<a name="saml"></a>

OpenSearch Dashboards 的 SAML 身分驗證可讓您使用現有身分提供者，以便在執行 OpenSearch 或 Elasticsearch 6.7 或更新版本的 Amazon OpenSearch Service 網域上提供 Dashboards 的單一登入 (SSO)。若要使用 SAML 身分驗證，您必須啟用[精細存取控制](fgac.md)。

不是透過 [Amazon Cognito](cognito-auth.md) 或[內部使用者資料庫](fgac.md#fgac-dashboards)進行身分驗證，OpenSearch Dashboards 的 SAML 身分驗證可讓您使用第三方身分提供者來登入 Dashboards、管理精細存取控制、搜尋您的資料，以及建置視覺效果。OpenSearch Service 支援使用 SAML 2.0 標準的提供者，例如 Okta、Keycloak、Active Directory Federation Services (ADFS)、Auth0 和 AWS IAM Identity Center。

Dashboards 的 SAML 身分驗證僅適用於透過 web 瀏覽器存取 OpenSearch Dashboards。您的 SAML 憑證*不能*讓您對 OpenSearch 或 Dashboards API 發出直接 HTTP 請求。

## SAML 組態概觀
<a name="saml-overview"></a>

本文件假設您擁有現有的身分提供者並且熟悉它。我們無法為您的確切供應商提供詳細的設定步驟，僅適用於您的 OpenSearch Service 網域。

OpenSearch Dashboards 登入流程可採用以下兩種形式之一：
+ **服務供應商 (SP) 已啟動**：您瀏覽至 Dashboards (例如 `https://my-domain.us-east-1.es.amazonaws.com/_dashboards`)，它會將您重新引導到登入畫面。登入後，身分提供者會將您重新引導至 Dashboards。
+ **身分提供者 (IdP) 已啟動**：瀏覽至身分提供者，登入並從應用程式目錄中選擇 OpenSearch Dashboards。

OpenSearch Service 提供兩個單一登入 URL，即 SP 啟動和 IdP 啟動，但您只需要一個，即符合您想要的 OpenSearch Dashboards 登入流程即可。

無論您使用哪種身分驗證類型，目標是透過身分提供者登入，並接收包含您的使用者名稱 (必要) 和任何[後端角色](fgac.md#fgac-concepts) (選用，但建議使用) 的 SAML 聲明。此資訊允許[精細存取控制](fgac.md)以便將許可指派給 SAML 使用者。在外部身分提供者中，後端角色通常稱為「角色」或「群組」。

## 考量事項
<a name="saml-considerations"></a>

設定 SAML 身分驗證時請考量下列事項：
+ 由於 IdP 中繼資料檔案的大小，強烈建議使用 AWS 主控台來設定 SAML 身分驗證。
+ 網域一次只支援一個 Dashboards 身分驗證方法。如果您啟用 [OpenSearch Dashboards 的 Amazon Cognito 身分驗證](cognito-auth.md)，則必須先將其停用才可啟用 SAML 身分驗證。
+ 如果您搭配 SAML 使用網路負載平衡器，您必須先建立自訂端點。如需詳細資訊，請參閱[為 Amazon OpenSearch Service 建立自訂端點](customendpoint.md)。
+ 在非 IAM 身分的情況下，服務控制政策 (SCP) 將不適用或評估 （例如 Amazon OpenSearch Serverless & SAML 中的 SAML 和 Amazon OpenSearch Service 的基本內部使用者授權）。

## VPC 網域的 SAML 身分驗證
<a name="saml-vpc"></a>

SAML 不需要身分提供者和服務供應商之間的直接通訊。因此，即使您的 OpenSearch 網域託管在私有 VPC 中，只要您的瀏覽器能夠與您的 OpenSearch 叢集和身分提供者通訊，則您仍可以使用 SAML。您的瀏覽器本質上充當身分提供者和服務供應商之間的媒介。如需有關解釋 SAML 身分驗證流程的實用圖表，請參閱 [Okta 文件](https://developer.okta.com/docs/concepts/saml/#planning-for-saml)。

## 修改網域存取政策
<a name="saml-domain-access"></a>

在設定 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 啟動的身分驗證
<a name="saml-enable-sp-or-idp"></a>

這些步驟說明如何透過 OpenSearch Dashboards 的 SP 啟動的*或* IdP 啟動的身分驗證來啟用 SAML 身分驗證。如需了解啟用兩者所需的額外步驟，請參閱[同時啟用 SP 和 IdP 啟動的身分驗證](#saml-idp-with-sp)。

### 步驟 1：啟用 SAML 身分驗證
<a name="saml-enable"></a>

您可以在網域建立期間啟用 SAML 身分驗證，或在現有網域上選擇 **Actions** (動作)、**Edit security configuration** (編輯安全組態)來啟用 SAML 身分驗證。根據您選擇的動作，以下步驟略有不同。

在網域組態中，於 **SAML authentication for OpenSearch Dashboards/Kibana** (OpenSearch Dashboards/Kibana 的 SAML 身分驗證) 下，選取 **Enable SAML authentication** (啟用 SAML 身分驗證)。

### 步驟 2：設定身分提供者
<a name="saml-configure-idp"></a>

根據設定 SAML 身分驗證的時間，執行下列步驟。

#### 如果您正在建立新網域
<a name="saml-configure-new"></a>

如果您正在建立新網域，OpenSearch Service 還無法產生服務提供者實體 ID 或 SSO URL。身分提供者需要這些值才能正確啟用 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`。在建立網域之前，您可以使用這些值來設定身分提供者。如需範例，請參閱下一區段。

**注意**  
您不能使用雙堆疊端點登入，因為 HTTP 請求的 FQDN 與 SAML 請求的 FQDN 不同。如果您想要使用雙堆疊端點登入，OpenSearch 管理員將需要設定自訂端點，並將 CNAME 值設定為雙堆疊端點。

如果您未使用自訂端點，可以在 IdP 中輸入*臨時*值以產生所需的中繼資料，然後在網域處於作用中後加以更新。

例如，在 Okta 中，您可以將 `https://temp-endpoint.amazonaws.com` 輸入 **Single sign on URL** (單一登入 URL) 和 **Audience URI (SP Entity ID)** (對象 URI (SP 實體 ID)) 欄位，如此可產生中繼資料。然後，在網域處於作用中狀態後，您可以從 OpenSearch Service 中擷取正確的值並在 Okta 中加以更新。如需說明，請參閱[步驟 6：更新 IdP URL](#saml-update-urls)。

#### 如果您正在編輯現有網域
<a name="saml-configure-existing"></a>

如果您要在現有網域上啟用 SAML 身分驗證，請複製服務提供者實體 ID 和其中一個 SSO URL。如需有關使用哪個 URL 的指引，請參閱 [SAML 組態概觀](#saml-overview)。

![\[Service provider entity ID and SSO URLs for SAML authentication configuration.\]](http://docs.aws.amazon.com/zh_tw/opensearch-service/latest/developerguide/images/SAML.png)


使用這些值來設定身分提供者。這是程序中最複雜的部分，不幸的是，術語和步驟因供應商而千差萬別。請咨詢供應商文件。

例如，在 Okta 中，您可以建立 SAML 2.0 Web 應用程式。對於 **Single sign on URL** (單一登入 URL)，指定 SSO URL。對於**對象 URI (SP 實體 ID)**，指定 SP 實體 ID。

Okta 擁有使用者和群組，而不是使用者和後端角色。對於 **Group Attribute Statements** (群組屬性陳述式)，我們建議將 `role` 新增至 **Name** (名稱) 欄位，將常規表達式 `.+` 新增至 **Filter** (篩選條件) 欄位。此陳述式會告訴 Okta 身分提供者在使用中身分驗證之後，包含 SAML 聲明 `role` 欄位下的所有使用者群組。

在 IAM Identity Center 中，您將 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 中，您可以建立一般 Web 應用程式並啟用 SAML 2.0 附加元件。在 Keycloak 中，您可以建立用戶端。

### 步驟 3：匯入 IdP 中繼資料
<a name="saml-import-metadata"></a>

設定身分提供者之後，會產生 IdP 中繼資料檔案。此 XML 檔案包含提供者的相關資訊，例如 TLS 憑證、單一登入端點以及身分提供者的實體 ID。

複製 IdP 中繼資料檔案內容，然後貼至 OpenSearch Service 主控台的 **Metadata from IdP** (來自 IdP 的中繼資料) 欄位。或者，選擇 **Import from XML file** (從 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 欄位
<a name="saml-configure-fields"></a>

輸入 IdP 中繼資料之後，請在 OpenSearch Service 主控台中設定下列其他欄位：
+ **IdP entity ID** (IdP 實體 ID) – 從中繼資料檔案中複製 `entityID` 屬性的值，然後貼至此欄位。許多身分提供者也會將此值顯示為組態後摘要的一部分。有些供應商稱之為「發行者」。
+ **SAML master username** (SAML 主要使用者名稱) 和 **SAML master backend role** (SAML 主要後端角色) – 您指定的使用者和/或後端角色會收到叢集完整許可，相當於[新主要使用者](fgac.md#fgac-more-masters)，但只能在 OpenSearch Dashboards 中使用這些許可。

  例如，在 Okta 中，您可能擁有屬於群組 `admins` 的使用者 `jdoe`。如果您將 `jdoe` 新增到 **SAML 主要使用者名稱**欄位，只有該使用者會收到完整許可。如果您將 `admins` 新增到 SAML 主要後端角色欄位中，屬於 `admins` 群組的任何使用者都會收到完整許可。
**注意**  
SAML 聲明的內容必須完全符合您用於 SAML 主要使用者名稱和 SAML 主要角色的字串。某些身分供應商會在其使用者名稱之前新增字首，這可能會導致難以診斷的不相符。在身分提供者使用者介面中，您可能會看到 `jdoe`，但 SAML 聲明可能包含 `auth0|jdoe`。永遠使用 SAML 聲明中的字串。

許多身分提供者可讓您在設定程序期間檢視範例聲明，諸如 [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/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：(選用) 設定其他設定
<a name="saml-additional-settings"></a>

在 **Additional settings** (其他設定) 下，設定下列選用欄位：
+ **Subject key** (主體金鑰)– 您可以將此欄位留空，將 SAML 聲明的 `NameID` 元素用於使用者名稱。如果您的聲明不使用此標準元素，而是將使用者名稱作為自訂屬性，請在此處指定該屬性。
+ **Roles key** (角色金鑰)– 如果您想要使用後端角色 (建議使用)，請在此欄位中從聲明中指定屬性，例如 `role` 或 `group`。這是 [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) 等工具可以提供協助的另一種情況。
+ **Session time to live** (工作階段存留時間) – 依預設，OpenSearch Dashboards 會在 24 小時後將使用者登出。您可以透過指定新值，將此值設定為 60 至 1,440 分鐘 (24 小時) 之間的任何數字。

如果您對於組態感到滿意，請儲存網域。

### 步驟 6：更新 IdP URL
<a name="saml-update-urls"></a>

如果您[在建立網域時啟用 SAML 身分驗證](#saml-configure-new)，則必須在 IdP 中指定臨時 URL，才能產生 XML 中繼資料檔案。網域狀態變更為 `Active` 後，您可以取得正確的 URL 並修改 IdP。

若要擷取 URL，請選取網域並選擇 **Actions** (動作)，**Edit security configuration** (編輯安全組態)。在 **SAML authentication for OpenSearch Dashboards/Kibana** (OpenSearch Dashboards/Kibana 的 SAML 身分驗證) 下，您可以找到正確的服務提供者實體 ID 和 SSO URL。複製這些值並使用其來設定身分提供者，取代您在步驟 2 中提供的臨時 URL。

### 步驟 7：將 SAML 使用者映射至角色
<a name="saml-map-users"></a>

當網域狀態為作用中且 IdP 的設定都正確無誤後，請瀏覽至 OpenSearch Dashboards。
+ 如果您選擇 SP 啟動的 URL，請導覽至 `domain-endpoint/_dashboards`。若要直接登入特定租用戶，您可以將 `?security_tenant=tenant-name` 附加至 URL。
+ 如果您選擇 IdP 啟動的 URL，請導覽至身分提供者的應用程式目錄。

在這兩種情況下，請以 SAML 主要使用者或屬於 SAML 主要後端角色的使用者身分登入。若要繼續步驟 7 的範例，請以 `jdoe` 或 `admins` 群組成員身分登入。

OpenSearch Dashboards 載入後，選擇 **Security** (安全性) 和 **Roles** (角色)。接著，[映射角色](fgac.md#fgac-mapping)以允許其他使用者存取 OpenSearch Dashboards。

例如，您可將信任的同事 `jroe` 映射到 `all_access` 和 `security_manager` 角色。您也可以將後端角色 `analysts` 映射到 `readall` 和 `opensearch_dashboards_user` 角色。

如果您偏好使用 API 而非 OpenSearch Dashboards，請參閱下列範例要求：

```
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 啟動的身分驗證
<a name="saml-idp-with-sp"></a>

如果您要設定 SP 和 IdP 啟動的身分驗證，則必須透過身分提供者進行設定。例如，在 Okta 中，您可以執行下列步驟：

1. 在您的 SAML 應用程式中，移至 **General** (一般)、**SAML settings** (SAML 設定)。

1. 對於 **Single sign on URL** (單一登入 URL)，提供 *IdP* 啟動的 SSO URL。例如 `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated`。

1. 啟用 **Allow this app to request other SSO URLs** (允許此應用程式請求其他 SSO URL)。

1. 在 **Requestable SSO URLs** (可請求的 SSO URL) 中，新增一個或多個 *SP* 啟動的 SSO URL。例如 `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs`。

## 設定 SAML 身分驗證 (AWS CLI)
<a name="saml-enable-cli"></a>

下列 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 中的所有引號和換行符號字元。例如，使用 `<KeyDescriptor use=\"signing\">\n`，而不是 `<KeyDescriptor use="signing">` 和換行符。如需有關使用 AWS CLI的詳細資訊，請參閱 [AWS CLI 命令參考](https://docs.aws.amazon.com/cli/latest/reference/)。

## 設定 SAML 身分驗證 (組態 API)
<a name="saml-enable-api"></a>

下列對組態 API 的請求會在現有網域上啟用 OpenSearch Dashboards 的 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 中的所有引號和換行符號字元。例如，使用 `<KeyDescriptor use=\"signing\">\n`，而不是 `<KeyDescriptor use="signing">` 和換行符。如需有關使用組態 API 的詳細資訊，請參閱 [OpenSearch Service API reference](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html) (OpenSearch Service API 參考)。

## SAML 疑難排解
<a name="saml-troubleshoot"></a>


| 錯誤 | 詳細資訊 | 
| --- | --- | 
| 您的請求：'*/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/zh_tw/opensearch-service/latest/developerguide/saml.html)  | 
|  缺少角色：此使用者沒有可用的角色，請聯絡您的系統管理員。  |  您已成功進行身分驗證，但 SAML 聲明中的使用者名稱和任何後端角色未映射至任何角色，因此沒有許可。這些映射區分大小寫。 您的系統管理員可以使用 SAML[-tracer 等工具驗證 SAML](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) 聲明的內容，然後使用下列請求檢查您的角色映射： <pre>GET _plugins/_security/api/rolesmapping</pre>  | 
|  當您嘗試存取 OpenSearch Dashboards 時，您的瀏覽器會持續重新引導或收到 HTTP 500 錯誤。  |  如果您的 SAML 聲明包含大量的角色，總計約 1,500 個字元，就會發生這些錯誤。例如，如果您傳遞 80 個角色，平均長度為 20 個字元，您可能會超過 web 瀏覽器中 Cookie 的大小限制。從 OpenSearch 2.7 版開始，SAML 聲明支援最多 5000 個字元的角色。  | 
|  您無法登出 ADFS。  |  ADFS 要求簽署所有登出請求，而 OpenSearch Service 不支援這些請求。從 IdP 中繼資料檔案中移除 `<SingleLogoutService />`，以強制 OpenSearch Service 使用自己的內部登出機制。  | 
|  `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 已輪換其憑證。在透過 提供給 OpenSearch Service 的中繼資料 XML 中，從 IdP 更新最新的憑證 AWS 管理主控台。  | 
|  `__PATH__ is not a valid audience for this response.`  |  SAML 回應中的對象欄位與網域端點不相符。若要修正此錯誤，請更新 SP 對象欄位以符合您的網域端點。如果您已啟用自訂端點，對象欄位應與自訂端點相符。在您的網域上啟用 **CW 應用程式錯誤日誌**，以尋找偵錯 SAML 整合問題的錯誤訊息。  | 
|  您的瀏覽器在回應`Invalid Request Id`中收到 HTTP 400 錯誤與 。  |  如果您已使用 格式設定 IdP 起始的 URL，則通常會發生此錯誤`<DashboardsURL>/_opendistro/_security/saml/acs`。反之，請以 格式設定 URL`<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated`。  | 
|  在 收到回應，`__PATH__`而不是 `__PATH__`。  |  SAML 回應中的目的地欄位不符合下列其中一個 URL 格式： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opensearch-service/latest/developerguide/saml.html) 根據您使用的登入流程 (SP 起始或 IdP 起始），在符合其中一個 OpenSearch URLs目的地欄位中輸入 。  | 
|  回應具有 `InResponseTo` 屬性，但`InResponseTo`預期不會。  |  您正在針對 SP 起始的登入流程使用 IdP 起始的 URL。請改用 SP 起始的 URL。  | 

## 停用 SAML 身分驗證
<a name="saml-disable"></a>

**若要停用 OpenSearch Dashboards (主控台) 的 SAML 身分驗證**

1. 選擇網域、**Actions** (動作) 和 **Edit security configuration** (編輯安全組態)。

1. 取消勾選 **Enable SAML authentication** (啟用 SAML 身分驗證)。

1. 選擇**儲存變更**。

1. 網域完成處理之後，請使用下列請求確認精細存取控制角色映射：

   ```
   GET _plugins/_security/api/rolesmapping
   ```

   停用 Dashboards 的 SAML 身分驗證*不會*移除 SAML 主要使用者名稱和/或 SAML 主要後端角色的映射。如果您要移除這些映射，請使用內部使用者資料庫 (如果已啟用) 登入 Dashboards，或使用 API 將其移除：

   ```
   PUT _plugins/_security/api/rolesmapping/all_access
   {
     "users": [
       "master-user"
     ]
   }
   ```