OpenSearch Dashboards 的 SAML 身分驗證 - Amazon OpenSearch Service

OpenSearch Dashboards 的 SAML 身分驗證

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

不是透過 Amazon Cognito內部使用者資料庫進行身分驗證,OpenSearch Dashboards 的 SAML 身分驗證可讓您使用第三方身分供應商來登入 Dashboards、管理精細存取控制、搜尋您的資料,以及建置視覺效果。OpenSearch Service 支援使用 SAML 2.0 標準的供應商,例如 Okta、Keycloak、Active Directory Federation Services (ADFS) 和 Auth0。

注意

從 OpenSearch Service 到第三方供應商的請求並不會使用服務供應商憑證明確加密。

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

SAML 組態概觀

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

Dashboards 登入流程可採用以下兩種形式之一:

  • 服務供應商 (SP) 已啟動:您瀏覽至 Dashboards (例如 https://my-domain.us-east-1.es.amazonaws.com/_dashboards),它會將您重新引導到登入畫面。登入後,身分供應商會將您重新引導至 Dashboards。

  • 身分供應商 (IdP) 已啟動:瀏覽至身分供應商,登入並從應用程式目錄中選擇 Dashboards。

OpenSearch Service 提供兩個單一登入 URL,即 SP 啟動和 IdP 啟動,但您只需要一個,即符合您想要的 Dashboards 登入流程即可。如果您要設定 SP 和 IdP 啟動的身分驗證,則必須透過身分供應商進行設定。例如,在 Okta 中,您可以啟用允許此應用程式請求其他 SSO URL,然後新增一個或更多個 IdP 啟動的 SSO URL。

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

注意

您無法從其服務提供的值中變更 SSO URL,因此 Dashboards 的 SAML 身分驗證不支援代理伺服器。

VPC 中執行的網域的 SAML 身分驗證

SAML 不需要您的身分供應商和服務供應商之間的直接通訊。因此,即使您的 OpenSearch 網域託管在私有 VPC 中,只要您的瀏覽器能夠與您的 OpenSearch 叢集和身分供應商通訊,則您仍可以使用 SAML。您的瀏覽器本質上充當身分供應商和服務供應商之間的媒介。如需有關解釋 SAML 身分驗證流程的實用圖表,請參閲 Okta 文件

啟用 SAML 身分驗證

您只能在現有網域上啟用 OpenSearch Dashboards 的 SAML 身分驗證,而不能在建立新網域時啟用。由於 IdP 中繼資料檔案的大小,我們強烈建議使用 AWS 主控台。

網域一次只支援一個 Dashboards 身分驗證方法。如果您擁有 OpenSearch Dashboards 的 Amazon Cognito 身分驗證,則必須先停用才可啟用 SAML。

若要啟用 Dashboards (主控台) 的 SAML 身分驗證

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

  2. 選擇 Enable SAML authentication (啟用 SAML 身分驗證)。

  3. 請記下服務供應商實體 ID 和兩個 SSO URL。您只需要其中一個 SSO URL。如需準則,請參閱SAML 組態概觀

    提示

    如果您稍後啟用網域的自訂端點,這些 URL 會變更。在此情況下,您必須更新 IdP。

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

    例如,在 Okta 中,您可以建立「SAML 2.0 Web 應用程式」。對於單一登入 URL,指定您在步驟 3 中選擇的 SSO URL。對於對象 URI (SP 實體 ID),指定 SP 實體 ID。

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

    在 Auth0 中,您可以建立「一般 Web 應用程式」,然後啟用 SAML 2.0 附加元件。在 Keycloak 中,建立一個「用戶端」。

  5. 設定身分供應商之後,它會產生 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>
  6. 從中繼資料檔案中複製 entityID 屬性的值,然後貼至 OpenSearch Service 主控台的 IdP entity ID (IdP 實體 ID) 欄位。許多身分供應商也會將此值顯示為組態後摘要的一部分。有些供應商稱之為「發行者」。

  7. 提供 SAML 主要使用者名稱和/或一個 SAML 主要後端角色。此使用者名稱和/或後端角色會收到叢集的完整許可,相當於新主要使用者,但只能在 Dashboards 中使用這些許可。

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

    SAML 聲明的內容必須完全符合您用於 SAML 主要使用者名稱和/或 SAML 主要角色的字串。某些身分供應商會在其使用者名稱之前新增字首,這可能會導致難以診斷的不相符。在身分供應商使用者介面中,您可能會看到 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/_plugins/_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>
  8. (選用) 展開 Additional settings (其他設定)

  9. Subject key (主體金鑰) 欄位留空,將 SAML 聲明的 NameID 元素用於使用者名稱。如果您的聲明不使用此標準元素,而是將使用者名稱作為自訂屬性,請在此處指定該屬性。

    如果您想要使用後端角色 (建議使用),請在 Role key (角色金鑰) 欄位中從聲明中指定屬性,例如 rolegroup。這是 SAML-tracer 等工具可以提供協助的另一種情況。

  10. 依預設,OpenSearch 儀表板會在 24 小時後登出使用者。您可以指定 Session time to live (工作階段存留時間),將此值設定為 60 至 1,440 分鐘 (24 小時)。

  11. 選擇 Save changes (儲存變更)。網域會進入大約一分鐘的處理狀態,在此期間無法使用 Dashboards。

  12. 網域完成處理後,開啟 Dashboards。

    • 如果您選擇 SP 啟動的 URL,請導覽至 domain-endpoint/_dashboards/

    • 如果您選擇 IdP 啟動的 URL,請導覽至身分供應商的應用程式目錄。

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

  13. Dashboards 載入後,選擇 Security (安全性) 和 Roles (角色)。

  14. 映射角色以允許其他使用者存取 Dashboards。

    例如,您可將信任的同事 jroe 映射到 all_accesssecurity_manager 角色。您也可以將後端角色 analysts 映射到 readallkibana_user 角色。

    如果您偏好使用 API 而非 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": "/kibana_user", "value": { "backend_roles": ["analysts"] } } ]

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 中的所有引號和換行符號字元。例如,使用 <KeyDescriptor use=\"signing\">\n,而不是 <KeyDescriptor use="signing"> 和換行符。如需有關使用 AWS CLI 的詳細資訊,請參閱 AWS CLI 命令參考

組態 API 請求範例

下列對組態 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 的詳細資訊,請參閱Amazon OpenSearch Service 的組態 API 參考

SAML 疑難排解

錯誤 詳細資訊

您的請求:'/some/path' 不允許。

確認您為身分供應商提供了正確的 SSO URL (步驟 3)。

請提供有效的身分供應商中繼資料文件以啟用 SAML。

您的 IdP 中繼資料檔案不符合 SAML 2.0 標準。使用驗證工具檢查錯誤。

SAML 組態選項在主控台中不可見。

更新至最新服務軟體

SAML 組態錯誤:擷取 SAML 組態時發生錯誤,請檢查您的設定。

此一般性錯誤的發生原因很多。

  • 檢查您是否為身分供應商提供了正確的 SP 實體 ID 和 SSO URL。

  • 重新產生 IdP 中繼資料檔案,並驗證 IdP 實體 ID。在 AWS 主控台中新增任何已更新的中繼資料。

  • 請確認您的網域存取政策允許存取 OpenSearch Dashboards 和 _plugins/_security/*。一般而言,對於使用精細存取控制的網域,我們建議使用開放式存取政策。

  • 如需設定 SAML 的步驟,請參閱身分供應商的文件。

缺少角色:此使用者沒有可用的角色,請聯絡您的系統管理員。

您已成功進行身分驗證,但 SAML 聲明中的使用者名稱和任何後端角色未映射至任何角色,因此沒有許可。這些映射區分大小寫。

透過以下呼叫,使用 SAML-tracer 等工具和您的角色映射來確認 SAML 聲明的內容:

GET _plugins/_security/api/rolesmapping

當您嘗試存取 OpenSearch Dashboards 時,您的瀏覽器會持續重新引導或收到 HTTP 500 錯誤。

如果您的 SAML 聲明包含大量的角色,總計約 1,500 個字元,就會發生這些錯誤。例如,如果您傳遞 80 個角色,平均長度為 20 個字元,您可能會超過 web 瀏覽器中 Cookie 的大小限制。

您無法登出 ADFS。

ADFS 要求簽署所有登出請求,而 OpenSearch Service 不支援這些請求。從 IdP 中繼資料檔案中移除 <SingleLogoutService />,以強制 OpenSearch Service 使用自己的內部登出機制。

停用 SAML 身分驗證

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

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

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

  3. 選擇 Save changes (儲存變更)。

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

    GET _plugins/_security/api/rolesmapping

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

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