Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Otentikasi SAML untuk Dasbor OpenSearch
Otentikasi SAML untuk OpenSearch Dasbor memungkinkan Anda menggunakan penyedia identitas yang ada untuk menawarkan sistem masuk tunggal (SSO) untuk Dasbor di domain OpenSearch Layanan Amazon yang berjalan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru. Untuk menggunakan autentikasi SAML, Anda harus mengaktifkan Kontrol akses detail.
Alih-alih mengotentikasi melalui Amazon Cognito atau database pengguna internal, otentikasi SAML untuk OpenSearch Dasbor memungkinkan Anda menggunakan penyedia identitas pihak ketiga untuk masuk ke Dasbor, mengelola kontrol akses yang halus, mencari data Anda, dan membuat visualisasi. OpenSearch Layanan mendukung penyedia yang menggunakan standar SAML 2.0, seperti Okta, Keycloak, Microsoft Entra ID, Active Directory Federation Services (ADFS), Auth0, dan. AWS IAM Identity Center
Otentikasi SAML untuk Dasbor hanya untuk mengakses OpenSearch Dasbor melalui browser web. KredenSIAL SAML Anda tidak memungkinkan Anda membuat permintaan HTTP langsung ke API Das OpenSearch bor atau.
Gambaran umum konfigurasi SAML
Dokumentasi ini mengasumsikan bahwa Anda memiliki penyedia identitas yang ada dan beberapa keakraban dengannya. Kami tidak dapat memberikan langkah-langkah konfigurasi terperinci untuk penyedia Anda yang tepat, hanya untuk domain OpenSearch Layanan Anda.
Alu OpenSearch r login dasbor dapat mengambil salah satu dari dua bentuk:
-
Penyedia layanan (SP) dimulai: Anda menavigasi ke Dasbor (misalnya,
https://), yang mengarahkan Anda ke layar login. Setelah Anda masuk, penyedia identitas mengarahkan Anda ke Dasbor.my-domain.us-east-1.es.amazonaws.com/_dashboards -
Penyedia identitas (IdP) dimulai: Anda menavigasi ke penyedia identitas Anda, masuk, dan memilih OpenSearch Dasbor dari direktori aplikasi.
OpenSearch Layanan menyediakan dua URL masuk tunggal, SP-initiated dan IdP-initiated, tetapi Anda hanya perlu satu yang sesuai dengan alur login Dasbor yang Anda OpenSearch inginkan.
Apa pun jenis autentikasi yang Anda gunakan, tujuannya adalah untuk login melalui penyedia identitas dan menerima pernyataan SAML yang berisi nama pengguna Anda (wajib) dan peran backend (opsional, tetapi direkomendasikan). Informasi ini memungkinkan kontrol akses detail untuk menetapkan izin bagi pengguna SAML. Dalam penyedia identitas eksternal, peran backend biasanya disebut “peran” atau “grup”.
Pertimbangan-pertimbangan
Pertimbangkan hal berikut saat Anda mengonfigurasi otentikasi SAML:
-
Karena ukuran file metadata IdP, kami sangat menyarankan menggunakan AWS konsol untuk mengonfigurasi otentikasi SAML.
-
Domain hanya mendukung satu metode otentikasi Dasbor pada satu waktu. Jika Anda mengaktifkan otentikasi Amazon Cognito untuk OpenSearch Dasbor, Anda harus menonaktifkannya sebelum mengaktifkan otentikasi SAML.
-
Jika Anda menggunakan penyeimbang beban jaringan dengan SAML, Anda harus terlebih dahulu membuat titik akhir khusus. Untuk informasi selengkapnya, lihat Membuat endpoint khusus untuk Amazon Service OpenSearch.
-
Kebijakan Kontrol Layanan (SCP) tidak akan berlaku atau dievaluasi dalam kasus identitas non-IAM (seperti SAML di Amazon OpenSearch Serverless & SAML dan otorisasi pengguna internal dasar untuk Layanan Amazon). OpenSearch
Otentikasi SAML untuk domain VPC
SAML tidak memerlukan komunikasi langsung antara penyedia identitas Anda dan penyedia layanan Anda. Oleh karena itu, meskipun OpenSearch domain Anda di-host dalam VPC pribadi, Anda masih dapat menggunakan SAML selama browser Anda dapat berkomunikasi dengan OpenSearch cluster dan penyedia identitas Anda. Browser Anda pada dasarnya bertindak sebagai perantara antara penyedia identitas Anda dan penyedia layanan Anda. Untuk diagram berguna yang menjelaskan alur otentikasi SAML, lihat dokumentasi Okta.
Memodifikasi kebijakan akses domain
Sebelum mengonfigurasi otentikasi SAML, Anda harus memperbarui kebijakan akses domain untuk mengizinkan pengguna SAML mengakses domain. Jika tidak, Anda akan melihat kesalahan akses ditolak.
Kami merekomendasikan kebijakan akses domain berikut, yang menyediakan akses penuh ke subresource (/*) pada domain:
Untuk membuat kebijakan lebih ketat, Anda dapat menambahkan kondisi alamat IP ke kebijakan. Kondisi ini membatasi akses hanya ke rentang alamat IP atau subnet yang ditentukan. Misalnya, kebijakan berikut mengizinkan akses hanya dari 192.0.2. 0/24subnet:
catatan
Kebijakan akses domain terbuka memerlukan kontrol akses halus untuk diaktifkan di domain Anda, jika tidak, Anda akan melihat kesalahan berikut:
To protect domains with public access, a restrictive policy or fine-grained
access control is required.
Jika Anda memiliki pengguna master atau pengguna internal yang dikonfigurasi dengan kata sandi yang kuat, menjaga kebijakan tetap terbuka saat menggunakan kontrol akses yang halus mungkin dapat diterima dari sudut pandang keamanan. Untuk informasi selengkapnya, lihat Fine-grained kontrol akses di OpenSearch Layanan Amazon.
Mengkonfigurasi SP- atau IdP-initiated otentikasi
Langkah-langkah ini menjelaskan cara mengaktifkan otentikasi SAML dengan SP-initiated atau IdP-initiated otentikasi untuk OpenSearch Dasbor. Untuk langkah tambahan yang diperlukan untuk mengaktifkan keduanya, lihat Mengon figurasi SP- dan IdP-initiated otentikasi.
Langkah 1: Aktifkan otentikasi SAML
Anda dapat mengaktifkan otentikasi SAML baik selama pembuatan domain, atau dengan memilih Tind akan, Edit konfigurasi keamanan pada domain yang ada. Langkah-langkah berikut sedikit berbeda tergantung mana yang Anda pilih.
Dalam konfigurasi domain, di bawah Otentikasi SAML untuk OpenSearch Dashboards/Kibana, pilih Aktifkan otentikasi SAML.
Langkah 2: Konfigurasikan penyedia identitas Anda
Lakukan langkah-langkah berikut tergantung kapan Anda mengonfigurasi otentikasi SAML.
Jika Anda membuat domain baru
Jika Anda sedang dalam proses membuat domain baru, OpenSearch Layanan belum dapat membuat ID entitas penyedia layanan atau URL SSO. Penyedia identitas Anda memerlukan nilai-nilai ini untuk mengaktifkan otentikasi SAML dengan benar, tetapi nilai-nilai tersebut hanya dapat dibuat setelah domain dibuat. Untuk mengatasi interdependensi ini selama pembuatan domain, Anda dapat memberikan nilai sementara ke dalam konfigurasi IdP untuk menghasilkan metadata yang diperlukan dan kemudian memperbaruinya setelah domain Anda aktif.
Jika Anda menggunakan titik akhir khusus, Anda dapat menyimpulkan seperti apa URL-nya. Misalnya, jika titik akhir kustom Anda adalahwww., ID entitas penyedia layanan akan menjadicustom-endpoint.comwww., URL IdP-initiated SSO akancustom-endpoint.comwww., dan URL SS SP-initiated O akan menjadi. custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiatedwww. Anda dapat menggunakan nilai untuk mengonfigurasi penyedia identitas Anda sebelum domain dibuat. Lihat bagian selanjutnya untuk contoh.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs
catatan
Anda tidak dapat masuk dengan titik akhir tumpukan ganda karena FQDN permintaan HTTP berbeda dari FQDN permintaan SAML. OpenSearchAdministrator perlu menyiapkan titik akhir khusus dan menetapkan nilai CNAME ke titik akhir tumpukan ganda jika Anda ingin masuk menggunakan titik akhir tumpukan ganda.
Jika Anda tidak menggunakan titik akhir khusus, Anda dapat memasukkan nilai sementara ke IdP untuk menghasilkan metadata yang diperlukan, lalu memperbaruinya nanti setelah domain aktif.
Misalnya, dalam Okta, Anda dapat memasukkan https:// ke dalam bidang Single sign on URL dan Audience URI (SP Entity ID), yang memungkinkan Anda menghasilkan metadata. Kemudian, setelah domain aktif, Anda dapat mengambil nilai yang benar dari OpenSearch Layanan dan memperbaruinya di Okta. Untuk petunjuk, lihat Langkah 6: Perbarui URL IdP Anda.temp-endpoint.amazonaws.com
Jika Anda mengedit domain yang sudah ada
Jika Anda mengaktifkan otentikasi SAML pada domain yang ada, salin ID entitas penyedia layanan dan salah satu URL SSO. Untuk panduan tentang URL mana yang akan digunakan, lihatGambaran umum konfigurasi SAML.
Gunakan nilai untuk mengonfigurasi penyedia identitas Anda. Bagian ini merupakan proses yang paling rumit, dan sayangnya, terminologi dan langkah-langkah sangat bervariasi berdasarkan penyedia. Baca dokumentasi dari penyedia Anda.
Di Okta, misalnya, Anda membuat aplikasi web SAML 2.0. Untuk URL tanda tangan tunggal, tentukan URL SSO. Untuk URI audiens (ID Entitas SP, tentukan ID entitas SP.
Okta memiliki pengguna dan grup, bukan pengguna dan peran backend. Untuk Pernyataan Atribut Grup, sebaiknya tambahkan role ke bidang Nama dan ekspresi regul .+ er ke bidang Filter. Pernyataan ini memberi tahu penyedia identitas Okta untuk memasukkan semua grup pengguna pada bidang role dari penegasan SAML setelah pengguna mengautentikasi.
Di Pusat Identitas IAM, Anda menentukan ID entitas SP sebagai audiens SAML Aplikasi. Anda juga perlu menentukan pemetaan atribut berikut: Subject=${user:subject}:format=unspecified dan. Role=${user:groups}:format=uri
Di Auth0, Anda membuat aplikasi web biasa dan mengaktifkan add-on SAML 2.0. Di Keycloak, Anda membuat klien.
Langkah 3: Impor metadata IdP
Setelah Anda konfigurasi, penyedia identitas akan menghasilkan file metadata IdP. File XML ini berisi informasi tentang penyedia, seperti sertifikat TLS, titik akhir masuk tunggal, dan ID entitas penyedia identitas.
Salin isi file metadata IdP dan tempelkan ke kolom Metadata dari IdP di konsol OpenSearch Layanan. Sebagai alternatif, pilih Impor dari file XML dan unggah file. File metadata harus terlihat seperti ini:
<?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>
Langkah 4: Konfigurasikan bidang SAML
Setelah Anda memasukkan metadata IdP Anda, konfigurasikan bidang tambahan berikut dalam konsol OpenSearch Layanan:
-
ID entitas IdP — Salin nilai
entityIDproperti dari file metadata Anda dan tempelkan ke bidang ini. Banyak penyedia identitas juga menampilkan nilai ini sebagai bagian dari ringkasan pasca-konfigurasi. Beberapa penyedia menyebutnya “penerbit”.catatan
Nilai ID Entitas IdP harus dalam format URL (misalnya,
https://idp.example.com/...). Non-URL nilai seperti string biasa (misalnya, "JumpCloud“) akan menyebabkan kesalahan 500. -
Nama pengguna master SAML dan peran backend master SAML — Peran and/or backend pengguna yang Anda tentukan menerima izin penuh ke cluster, setara dengan pengguna master baru, tetapi hanya dapat menggunakan izin tersebut dalam Dasbor. OpenSearch
Di Okta, misalnya, Anda mungkin memiliki pengguna
jdoeyang termasuk dalam grupadmins. Jika Anda menambahkanjdoeke bidang Nama pengguna utama SAML, hanya pengguna yang akan menerima izin penuh. Jika Anda menambahkanadminske bidang peran backend master SAML, setiap pengguna yang termasuk dalamadminsgrup menerima izin penuh.catatan
Isi pernyataan SAML harus sama persis dengan string yang Anda gunakan untuk nama pengguna master SAML dan peran master SAML. Beberapa penyedia identitas menambahkan prefiks sebelum nama pengguna mereka,dan hal ini dapat menyebabkan ketidakcocokan yang sulit didiagnosis. Di antarmuka pengguna penyedia identitas, Anda mungkin melihat
jdoe, tetapi penegasan SAML mungkin berisiauth0|jdoe. Selalu gunakan string dari penegasan SAML.
Banyak penyedia identitas memungkinkan Anda melihat pernyataan sampel selama proses konfigurasi, dan alat seperti 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>
Langkah 5: (Opsional) Konfigurasikan pengaturan tambahan
Di bawah Pengaturan tambahan, konfigurasikan bidang opsional berikut:
-
Kunci subjek — Anda dapat membiarkan bidang ini kosong untuk menggunakan
NameIDelemen pernyataan SAML untuk nama pengguna. Jika penegasan Anda tidak menggunakan elemen standar ini dan sebagai gantinya menyertakan nama pengguna sebagai atribut kustom, tentukan atribut di sini. -
Kunci peran — Jika Anda ingin menggunakan peran backend (disarankan), tentukan atribut dari pernyataan di bidang ini, seperti
roleatau.groupIni adalah situasi lain di mana alat seperti SAML-tracerdapat membantu. -
Waktu sesi untuk live — Secara default, OpenSearch Dashboard membuat pengguna keluar setelah 24 jam. Anda dapat mengonfigurasi nilai ini ke angka apa pun antara 60 dan 1.440 (24 jam) dengan menentukan nilai baru.
Setelah Anda puas dengan konfigurasi Anda, simpan domain.
Langkah 6: Perbarui URL IdP Anda
Jika Anda mengaktifkan otentikasi SAML saat membuat domain, Anda harus menentukan URL sementara dalam IdP Anda untuk menghasilkan file metadata XML. Setelah status domain berubah menjadiActive, Anda bisa mendapatkan URL yang benar dan memodifikasi IdP Anda.
Untuk mengambil URL, pilih domain dan pilih Tindakan , Edit konfigurasi keamanan. Di bawah Otentikasi SAML untuk OpenSearch Dashboards/Kibana, Anda dapat menemukan ID entitas penyedia layanan dan URL SSO yang benar. Salin nilai dan gunakan untuk mengonfigurasi penyedia identitas Anda, menggantikan URL sementara yang Anda berikan pada langkah 2.
Langkah 7: Petakan pengguna SAML ke peran
Setelah status domain Anda Aktif dan IdP Anda dikonfigurasi dengan benar, navigasikan ke OpenSearch Dasbor.
-
Jika Anda memilih SP-initiated URL, navigasikan ke
. Untuk masuk ke penyewa tertentu secara langsung, Anda dapat menambahkandomain-endpoint/_dashboards?security_tenant=ke URL.tenant-name -
Jika Anda memilih IdP-initiated URL, navigasikan ke direktori aplikasi penyedia identitas Anda.
Dalam kedua kasus, login sebagai pengguna utama SAML atau pengguna yang termasuk dalam peran backend utama SAML. Untuk melanjutkan contoh dari langkah 7, login sebagai jdoe atau anggota grup admins.
Setelah OpenSearch Dasbor dimuat, pilih Keamanan, Peran. Kemudian, petakan peran untuk memungkinkan pengguna lain mengakses OpenSearch Dasbor.
Misalnya, Anda dapat memetakan rekan Anda yang tepercaya jroe ke peran all_access dan security_manager. Anda juga dapat memetakan peran backend analysts ke peran readall dan opensearch_dashboards_user.
Jika Anda lebih suka menggunakan API daripada OpenSearch Dasbor, lihat permintaan sampel berikut:
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"] } } ]
Mengkonfigurasi SP- dan IdP-initiated otentikasi
Jika Anda ingin mengonfigurasi SP- dan IdP-initiated otentikasi, Anda harus melakukannya melalui penyedia identitas Anda. Misalnya, di Okta, Anda dapat melakukan langkah-langkah berikut:
-
Dalam aplikasi SAML Anda, buka Umum, pengaturan SAML.
-
Untuk URL masuk tunggal, berikan URL SSO yang di prakarsai IdP Anda. Misalnya,
https://search-.domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated -
Aktif kan Izinkan aplikasi ini untuk meminta URL SSO lainnya.
-
Di bawah URL SSO yang dapat diminta, tambahkan satu atau beberapa URL SSO yang diprakar sai SP. Misalnya,
https://search-.domain-hash/_dashboards/_opendistro/_security/saml/acs
Mengkonfigurasi otentikasi SAML (AWS CLI)
Per AWS CLI intah berikut mengaktifkan otentikasi SAML untuk OpenSearch Dasbor pada domain yang ada:
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"}}'
Anda harus mengeluarkan semua tanda kutip dan karakter baris baru dalam XML metadata. Misalnya, gunakan <KeyDescriptor use=\"signing\">\n sebagai ganti <KeyDescriptor
use="signing"> dan pemisah baris. Untuk informasi detail cara menggunakan AWS CLI, lihat Referensi Perintah AWS CLI.
Mengkonfigurasi otentikasi SAML (API konfigurasi)
Permintaan berikut ke API konfigurasi mengaktifkan otentikasi SAML untuk OpenSearch Dasbor pada domain yang ada:
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" } } }
Anda harus mengeluarkan semua tanda kutip dan karakter baris baru dalam XML metadata. Misalnya, gunakan <KeyDescriptor use=\"signing\">\n sebagai ganti <KeyDescriptor
use="signing"> dan pemisah baris. Untuk informasi terperinci tentang penggunaan API konfigurasi, lihat referensi API OpenSearch Layanan.
Memecahkan masalah SAML
| Kesalahan | Rincian |
|---|---|
|
Verifikasi bahwa Anda telah memberikan URL SSO yang benar (langkah 3) ke penyedia identitas. |
|
|
File metadata IdP Anda tidak sesuai dengan standar SAML 2.0. Periksa kesalahan menggunakan alat validasi. |
|
Opsi konfigurasi SAML tidak terlihat di konsol. |
Perbarui ke perangkat lunak layanan terbaru. |
|
|
Kesalahan umum ini dapat terjadi karena berbagai alasan.
|
|
|
Anda berhasil diautentikasi, tetapi nama pengguna dan setiap peran backend dari penegasan SAML tidak dipetakan ke peran apa pun sehingga tidak memiliki izin. Pemetaan ini peka huruf besar dan kecil. Administrator sistem Anda dapat memverifikasi konten pernyataan SAML Anda menggunakan alat seperti SAML-tracer
|
|
Browser Anda terus mengalihkan atau menerima kesalahan HTTP 500 saat mencoba mengakses OpenSearch Dasbor. |
Kesalahan ini dapat terjadi jika penegasan SAML berisi peran yang berjumlah sekitar 1.500 karakter. Misalnya, jika Anda meneruskan 80 peran dengan panjang rata-rata adalah 20 karakter, Anda mungkin melebihi batas ukuran cookie di peramban web Anda. Dimulai dengan OpenSearch versi 2.7, pernyataan SAML mendukung peran hingga 5000 karakter. |
|
Anda tidak dapat keluar dari ADFS. |
ADFS mengharuskan semua permintaan logout ditandatangani, yang tidak OpenSearch didukung Layanan. Hapus |
|
|
ID entitas IdP yang disediakan dalam metadata XML ke OpenSearch Layanan berbeda dari yang ada di respons SAML. Untuk memperbaikinya, pastikan mereka cocok. Akti fkan log Kesalahan Aplikasi CW di domain Anda untuk menemukan pesan kesalahan untuk men-debug masalah integrasi SAML. |
|
|
OpenSearch Layanan tidak dapat memverifikasi tanda tangan dalam respons SAML menggunakan sertifikat IdP yang disediakan dalam metadata XML. Ini bisa berupa kesalahan manual, atau IdP Anda telah memutar sertifikatnya. Perbarui sertifikat terbaru dari IdP Anda dalam XML metadata yang disediakan untuk OpenSearch Layanan melalui. Konsol Manajemen AWS |
|
|
Bidang audiens dalam respons SAML tidak cocok dengan titik akhir domain. Untuk memperbaiki kesalahan ini, perbarui bidang audiens SP agar sesuai dengan titik akhir domain Anda. Jika Anda telah mengaktifkan titik akhir khusus, bidang audiens harus sesuai dengan titik akhir kustom Anda. Akti fkan log Kesalahan Aplikasi CW di domain Anda untuk menemukan pesan kesalahan untuk men-debug masalah integrasi SAML. |
|
Browser Anda menerima kesalahan HTTP 400 |
Kesalahan ini umumnya terjadi jika Anda telah mengonfigurasi IdP-initiated URL dengan format |
|
Jawabannya diterima sebagai |
Bidang tujuan dalam respons SAML tidak cocok dengan salah satu format URL berikut:
Bergantung pada alur login yang Anda gunakan (SP-initiated atau IdP-initiated), masukkan bidang tujuan yang cocok dengan salah satu OpenSearch URL. |
|
Respons memiliki |
Anda menggunakan IdP-initiated URL untuk alur SP-initiated login. Gunakan SP-initiated URL sebagai gantinya. |
Mengaktifkan autentikasi SAML
Untuk menonaktifkan otentikasi SAML untuk OpenSearch Dasbor (konsol)
-
Pilih domain, Tind akan, dan Edit konfigurasi keamanan.
-
Hapus tanda centang pada opsi Aktifkan autentikasi SAML.
-
Pilih Simpan perubahan.
-
Setelah domain selesai diproses, verifikasi pemetaan peran kontrol akses yang halus dengan permintaan berikut:
GET _plugins/_security/api/rolesmappingMenonaktifkan otentikasi SAML untuk Dasbor tidak menghapus pemetaan untuk nama pengguna and/or master SAML peran backend master SAML. Jika Anda ingin menghapus pemetaan ini, masuk ke Dasbor menggunakan database pengguna internal (jika diaktifkan), atau gunakan API untuk menghapusnya:
PUT _plugins/_security/api/rolesmapping/all_access{ "users": [ "master-user" ] }