SAML 組態概觀考量事項 VPC 網域的 SAML 身分驗證修改網域存取政策設定 SP 或 IdP 啟動的身分驗證同時設定 SP 和 IdP 啟動的身分驗證設定 SAML 身分驗證 (AWS CLI)設定 SAML 身分驗證 (組態 API)SAML 疑難排解停用 SAML 身分驗證

適用於儀表板的 SAML 驗證 OpenSearch

OpenSearch 儀表板的 SAML 身份驗證可讓您使用現有的身分供應商為執行 OpenSearch 或 Elasticsearch 6.7 或更新版本的 Amazon OpenSearch 服務網域上的儀表板提供單一登入 (SSO)。若要使用 SAML 身分驗證，您必須啟用精細存取控制。

儀表板適用的 SAML 身分驗證可讓您使用第三方身分識別提供者登入 OpenSearch 儀表板、管理精細的存取控制、搜尋資料以及建立視覺效果，而不是透過 Amazon Cognito 或內部使用者資料庫進行驗證。 OpenSearch 服務支援使用 SAML 2.0 標準的提供者，例如 Okta、鍵盤遮罩、作用中目錄聯合服務 (ADFS)、Auth0 和. AWS IAM Identity Center

儀表板的 SAML 驗證僅適用於透過 Web 瀏覽器存取 OpenSearch 儀表板。您的 SAML 認證不允許您直接向 OpenSearch 或儀表板 API 發出 HTTP 要求。

SAML 組態概觀

本文件假設您擁有現有的身分提供者並且熟悉它。我們無法針對您的 OpenSearch 服務網域，提供您確切的提供者的詳細設定步驟。

OpenSearch 儀表板登入流程可採用以下兩種形式之一：

服務供應商 (SP) 已啟動：您瀏覽至 Dashboards (例如 https://my-domain.us-east-1.es.amazonaws.com/_dashboards)，它會將您重新引導到登入畫面。登入後，身分提供者會將您重新引導至 Dashboards。
已啟動身分識別提供者 (IdP)：您導覽至身分識別提供者、登入，然後從應用程式目錄中選擇 OpenSearch 儀表板。

OpenSearch 服務提供兩個單一登入 URL，分別是 SP 起始和 IDP 起始，但您只需要符合所 OpenSearch 需儀表板登入流程的 URL。

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

考量事項

設定 SAML 身分驗證時請考量下列事項：

由於 IdP 中繼資料檔案的大小，我們強烈建議使用 AWS 主控台來設定 SAML 身分驗證。
網域一次只支援一個 Dashboards 身分驗證方法。如果您已啟用適用於 OpenSearch 儀表板的 Amazon Cognito 身份驗證，則必須先停用它，然後才能啟用 SAML 身份驗證。
如果您將網路負載平衡器與 SAML 搭配使用，則必須先建立自訂端點。如需詳細資訊，請參閱為亞馬遜 OpenSearch 服務創建自定義端點。

VPC 網域的 SAML 身分驗證

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 服務中的精細訪問控制。

設定 SP 或 IdP 啟動的身分驗證

這些步驟說明如何針對儀表板啟用 SP 起始或 IDP 起始驗證來啟用 SAML 驗證。 OpenSearch 如需了解啟用兩者所需的額外步驟，請參閱同時啟用 SP 和 IdP 啟動的身分驗證。

步驟 1：啟用 SAML 身分驗證

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

在網域組態中的 OpenSearch 儀表板 /Kibana 的 SAML 驗證下，選取「啟用 SAML 驗證」。

步驟 2：設定身分提供者

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

如果您正在建立新網域

如果您正在建立新網域， OpenSearch 服務尚無法產生服務提供者實體 ID 或 SSO URL。身分提供者需要這些值才能正確啟用 SAML 身分驗證，但只有在建立網域之後才能產生這些值。若要在網域建立期間處理此相互依存性，您可以在 IdP 組態中提供臨時值，以產生必要的中繼資料，然後在網域處於作用中狀態時加以更新。

如果您使用的是自訂端點，則可以推斷 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。在建立網域之前，您可以使用這些值來設定身分提供者。如需範例，請參閱下一區段。

如果您未使用自訂端點，可以在 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 身分驗證，請複製服務提供者實體 ID 和其中一個 SSO URL。如需有關使用哪個 URL 的指引，請參閱 SAML 組態概觀。

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

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

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

在 IAM 身分中心中，您可以將 SP 實體識別碼指定為應用程式 SAML 對象。您還需要指定下列屬性對應：Subject=${user:name}和Role=${user:groups}。

在 Auth0 中，您可以建立一般網頁應用程式並啟用 SAML 2.0 附加元件。在 KeyCloak 中，您可以建立用戶端。

步驟 3：匯入 IdP 中繼資料

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

複製 IdP 中繼資料檔案的內容，並將其貼到 OpenSearch 服務主控台的「來自 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 欄位

輸入 IdP 中繼資料之後，請在 OpenSearch 服務主控台中設定下列其他欄位：

IdP entity ID (IdP 實體 ID) – 從中繼資料檔案中複製 entityID 屬性的值，然後貼至此欄位。許多身分提供者也會將此值顯示為組態後摘要的一部分。有些供應商稱之為「發行者」。
SAML 主要使用者名稱和 SAML 主要後端角色 — 您指定的使用者和/或後端角色會接收叢集的完整權限，相當於新的主要使用者，但只能在儀表板中 OpenSearch 使用這些權限。

例如，在 Okta 中，您可能擁有屬於群組 admins 的使用者 jdoe。如果您將 jdoe 新增到 SAML 主要使用者名稱欄位，只有該使用者會收到完整許可。如果您將 admins 新增到 SAML 主要後端角色欄位中，屬於 admins 群組的任何使用者都會收到完整許可。

注意
SAML 聲明的內容必須完全符合您用於 SAML 主要使用者名稱和 SAML 主要角色的字串。有些身分識別提供者會在其使用者名稱前加上前置詞，這可能會造成 hard-to-diagnose 不相符。在身分提供者使用者介面中，您可能會看到 jdoe，但 SAML 聲明可能包含 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: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 (其他設定) 下，設定下列選用欄位：

Subject key (主體金鑰)– 您可以將此欄位留空，將 SAML 聲明的 NameID 元素用於使用者名稱。如果您的聲明不使用此標準元素，而是將使用者名稱作為自訂屬性，請在此處指定該屬性。
Roles key (角色金鑰)– 如果您想要使用後端角色 (建議使用)，請在此欄位中從聲明中指定屬性，例如 role 或 group。這是 SAML-tracer 等工具可以提供協助的另一種情況。
工作階段存留時間 — 依預設， OpenSearch 儀表板會在 24 小時後將使用者登出。您可以透過指定新值，將此值設定為 60 至 1,440 分鐘 (24 小時) 之間的任何數字。

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

步驟 6：更新 IdP URL

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

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

步驟 7：將 SAML 使用者映射至角色

一旦您的網域狀態為作用中且 IdP 設定正確，請瀏覽至 [ OpenSearch 儀表板]。

如果您選擇 SP 啟動的 URL，請導覽至 domain-endpoint/_dashboards。若要直接登入特定租用戶，您可以將 ?security_tenant=tenant-name 附加至 URL。
如果您選擇 IdP 啟動的 URL，請導覽至身分提供者的應用程式目錄。

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

載入 OpenSearch 儀表板後，選擇安全性，角色。然後，對應角色以允許其他使用者存取 OpenSearch 儀表板。

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

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


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 應用程式中，移至 General (一般)、SAML settings (SAML 設定)。
對於 Single sign on URL (單一登入 URL)，提供 IdP 啟動的 SSO URL。例如 https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated。
啟用 Allow this app to request other SSO URLs (允許此應用程式請求其他 SSO URL)。
在 Requestable SSO URLs (可請求的 SSO URL) 中，新增一個或多個 SP 啟動的 SSO URL。例如 https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs。

設定 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\">\n，而不是 <KeyDescriptor use="signing"> 和換行符。若要取得有關使用的詳細資訊 AWS CLI，請參閱《AWS CLI 指令參考》。

設定 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 中的所有引號和換行符號字元。例如，使用 <KeyDescriptor use=\"signing\">\n，而不是 <KeyDescriptor use="signing"> 和換行符。如需使用設定 API 的詳細資訊，請參閱OpenSearch 服務 API 參考資料。

SAML 疑難排解

錯誤	詳細資訊
`您的請求：'/some/path' 不允許。`	確認您為身分提供者提供了正確的 SSO URL (步驟 3)。
`請提供有效的身分提供者中繼資料文件以啟用 SAML。`	您的 IdP 中繼資料檔案不符合 SAML 2.0 標準。使用驗證工具檢查錯誤。
SAML 組態選項在主控台中不可見。	更新至最新服務軟體。
`SAML 組態錯誤：擷取 SAML 組態時發生錯誤，請檢查您的設定。`	此一般性錯誤的發生原因很多。檢查您是否為身分提供者提供了正確的 SP 實體 ID 和 SSO URL。重新產生 IdP 中繼資料檔案，並驗證 IdP 實體 ID。在 AWS 主控台中新增任何已更新的中繼資料。確認您的網域存取原則允許存取 OpenSearch 儀表板和`_plugins/_security/*`. 一般而言，對於使用精細存取控制的網域，我們建議使用開放式存取政策。如需設定 SAML 的步驟，請參閱身分提供者的文件。
`缺少角色：此使用者沒有可用的角色，請聯絡您的系統管理員。`	您已成功進行身分驗證，但 SAML 聲明中的使用者名稱和任何後端角色未映射至任何角色，因此沒有許可。這些映射區分大小寫。您的系統管理員可以使用 SAML 追蹤器等工具來驗證 SAML 宣告的內容，然後使用下列要求來檢查角色對應： `GET _plugins/_security/api/rolesmapping`
您的瀏覽器會在嘗試存取 OpenSearch 儀表板時持續重新導向或接收 HTTP 500 錯誤。	如果您的 SAML 聲明包含大量的角色，總計約 1,500 個字元，就會發生這些錯誤。例如，如果您傳遞 80 個角色，平均長度為 20 個字元，您可能會超過 web 瀏覽器中 Cookie 的大小限制。從 2.7 OpenSearch 版開始，SAML 宣告支援最多 5000 個字元的角色。
您無法登出 ADFS。	ADFS 要求簽署所有登出要求，哪些 OpenSearch 服務不支援。`<SingleLogoutService />`從 IdP 中繼資料檔案中移除，以強制 OpenSearch 服務使用自己的內部登出機制。
`Could not find entity descriptor for __PATH__.`	要 OpenSearch 服務的中繼資料 XML 中提供的 IdP 實體識別碼與 SAML 回應中的實體識別碼不同。要解決此問題，請確保它們匹配。啟用網域上的 CW 應用程式錯誤記錄檔，以尋找錯誤訊息以偵錯 SAML 整合問題。
`Signature validation failed. SAML response rejected.`	OpenSearch 服務無法使用中繼資料 XML 中提供的 IdP 憑證來驗證 SAML 回應中的簽章。這可能是手動錯誤，或者您的 IdP 已輪換其證書。透過提供給 OpenSearch 服務的中繼資料 XML 中，從您的 IdP 更新最新的 AWS Management Console憑證。
`__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 格式之一不相符： `<DashboardsURL>/_opendistro/_security/saml/acs` `<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated`. 根據您使用的登入流程 (SP 起始或 IDP 起始)，在符合其中一個 URL 的目的地欄位中輸入。 OpenSearch
響應具有`InResponseTo`屬性，而沒`InResponseTo`有預期。	您正在為 SP 起始的登入流程使用 IDP 起始的 URL。請改用 SP 起始的 URL。

停用 SAML 身分驗證

若要停用 OpenSearch 儀表板 (主控台) 的 SAML 驗證

選擇網域、Actions (動作) 和 Edit security configuration (編輯安全組態)。
取消勾選 Enable SAML authentication (啟用 SAML 身分驗證)。
選擇儲存變更。
網域完成處理之後，請使用下列請求確認精細存取控制角色映射：
```
GET _plugins/_security/api/rolesmapping
```
停用 Dashboards 的 SAML 身分驗證不會移除 SAML 主要使用者名稱和/或 SAML 主要後端角色的映射。如果您要移除這些映射，請使用內部使用者資料庫 (如果已啟用) 登入 Dashboards，或使用 API 將其移除：
```
PUT _plugins/_security/api/rolesmapping/all_access
{
  "users": [
    "master-user"
  ]
}
```

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

使用 OpenSearch 服務管理的 VPC 端點

用於儀表板的 Amazon Cognito 份 OpenSearch