Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
SAMLotentikasi untuk Dasbor OpenSearch
SAMLautentikasi untuk OpenSearch Dasbor memungkinkan Anda menggunakan penyedia identitas yang ada untuk menawarkan single sign-on (SSO) untuk Dasbor di domain OpenSearch Layanan Amazon yang berjalan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru. Untuk menggunakan SAML otentikasi, Anda harus mengaktifkan kontrol akses berbutir halus.
Daripada mengautentikasi melalui Amazon Cognito atau database pengguna internalSAML, autentikasi OpenSearch untuk Dasbor memungkinkan Anda menggunakan penyedia identitas pihak ketiga untuk masuk ke Dasbor, mengelola kontrol akses berbutir halus, mencari data, dan membangun visualisasi. OpenSearch Layanan mendukung penyedia yang menggunakan standar SAML 2.0, seperti Okta, Keycloak, Active Directory Federation Services (ADFS), Auth0, dan. AWS IAM Identity Center
SAMLotentikasi untuk Dasbor hanya untuk mengakses OpenSearch Dasbor melalui browser web. SAMLKredensi Anda tidak memungkinkan Anda membuat HTTP permintaan langsung ke OpenSearch atau Dasbor. APIs
SAMLikhtisar konfigurasi
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.
Alur login OpenSearch 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, masuk, dan memilih OpenSearch Dasbor dari direktori aplikasi.
OpenSearch Layanan menyediakan dua single sign-onURLs, SP-initiated dan IDP-initiated, tetapi Anda hanya memerlukan satu yang sesuai dengan alur login Dashboard yang Anda inginkan. OpenSearch
Terlepas dari jenis otentikasi yang Anda gunakan, tujuannya adalah untuk masuk melalui penyedia identitas Anda dan menerima SAML pernyataan yang berisi nama pengguna Anda (wajib) dan peran backend apa pun (opsional, tetapi disarankan). Informasi ini memungkinkan kontrol akses berbutir halus untuk menetapkan izin kepada pengguna. SAML Dalam penyedia identitas eksternal, peran backend biasanya disebut “peran” atau “grup”.
Pertimbangan
Pertimbangkan hal berikut saat Anda mengonfigurasi SAML otentikasi:
-
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 dapat mengaktifkan otentikasi. SAML
-
Jika Anda menggunakan penyeimbang beban jaringan denganSAML, Anda harus terlebih dahulu membuat endpoint kustom. Untuk informasi selengkapnya, lihat Membuat endpoint khusus untuk Amazon Service OpenSearch .
-
Kebijakan Kontrol Layanan (SCP) tidak akan berlaku atau dievaluasi jika tidak ada IAM identitas (seperti di SAML Amazon OpenSearch Tanpa Server & SAML dan otorisasi pengguna internal dasar untuk Layanan Amazon). OpenSearch
SAMLotentikasi untuk domain VPC
SAMLtidak memerlukan komunikasi langsung antara penyedia identitas Anda dan penyedia layanan Anda. Oleh karena itu, bahkan jika OpenSearch domain Anda di-host secara pribadiVPC, 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 SAML otentikasi, lihat dokumentasi Okta
Memodifikasi kebijakan akses domain
Sebelum mengonfigurasi SAML autentikasi, Anda harus memperbarui kebijakan akses domain agar SAML pengguna dapat mengakses domain. Jika tidak, Anda akan melihat kesalahan akses ditolak.
Kami merekomendasikan kebijakan akses domain berikut, yang menyediakan akses penuh ke subresource (/*
) pada domain:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
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 hanya mengizinkan akses dari subnet 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/*" } ] }
catatan
Kebijakan akses domain terbuka memerlukan kontrol akses berbutir 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 utama atau pengguna internal yang dikonfigurasi dengan kata sandi yang kuat, menjaga kebijakan tetap terbuka saat menggunakan kontrol akses berbutir halus mungkin dapat diterima dari sudut pandang keamanan. Untuk informasi selengkapnya, lihat Kontrol akses berbutir halus di Layanan Amazon OpenSearch .
Mengkonfigurasi otentikasi yang diprakarsai SP- atau IDP
Langkah-langkah ini menjelaskan cara mengaktifkan SAML otentikasi dengan otentikasi yang diprakarsai SP atau IDP untuk Dasbor. OpenSearch Untuk langkah tambahan yang diperlukan untuk mengaktifkan keduanya, lihat Mengonfigurasi otentikasi yang diprakarsai SP dan IDP.
Langkah 1: Aktifkan SAML otentikasi
Anda dapat mengaktifkan SAML otentikasi baik selama pembuatan domain, atau dengan memilih Tindakan, Edit konfigurasi keamanan pada domain yang ada. Langkah-langkah berikut sedikit berbeda tergantung pada mana yang Anda pilih.
Dalam konfigurasi domain, di bawah SAMLotentikasi untuk OpenSearch Dasbor/Kibana, pilih Aktifkan otentikasi. SAML
Langkah 2: Konfigurasikan penyedia identitas Anda
Lakukan langkah-langkah berikut tergantung pada saat Anda mengonfigurasi SAML otentikasi.
Jika Anda membuat domain baru
Jika Anda sedang dalam proses membuat domain baru, OpenSearch Layanan belum dapat menghasilkan ID entitas penyedia layanan atau SSOURLs. Penyedia identitas Anda memerlukan nilai-nilai ini untuk mengaktifkan SAML otentikasi dengan benar, tetapi hanya dapat dihasilkan setelah domain dibuat. Untuk mengatasi saling ketergantungan ini selama pembuatan domain, Anda dapat memberikan nilai sementara ke dalam konfigurasi iDP Anda untuk menghasilkan metadata yang diperlukan dan kemudian memperbaruinya setelah domain Anda aktif.
Jika Anda menggunakan titik akhir khusus, Anda dapat menyimpulkan apa yang URLs akan terjadi. Misalnya, jika titik akhir kustom Anda adalahwww.
, ID entitas penyedia layanan akan menjadicustom-endpoint
.comwww.
, IDP yang dimulai SSO URL akancustom-endpoint
.comwww.
, dan SP-dimulai akan. SSO URL 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 HTTP permintaan berbeda FQDN dari SAML permintaan. FQDN OpenSearchAdministrator perlu menyiapkan titik akhir kustom dan menyetel CNAME nilainya ke titik akhir tumpukan ganda jika Anda ingin masuk menggunakan titik akhir tumpukan ganda.
Jika Anda tidak menggunakan titik akhir kustom, Anda dapat memasukkan nilai sementara ke dalam iDP untuk menghasilkan metadata yang diperlukan, lalu memperbaruinya nanti setelah domain aktif.
Misalnya, dalam Okta, Anda dapat masuk https://
ke 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, silakan lihat Langkah 6: Perbarui IDP Anda URLs.temp-endpoint
.amazonaws.com
Jika Anda mengedit domain yang ada
Jika Anda mengaktifkan SAML autentikasi pada domain yang ada, salin ID entitas penyedia layanan dan salah satunya. SSO URLs Untuk panduan yang URL harus digunakan, lihatSAMLikhtisar konfigurasi.
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 Single sign on URL, tentukan SSOURL. Untuk Audiens URI (SP Entity ID), tentukan ID entitas SP.
Okta memiliki pengguna dan grup, bukan pengguna dan peran backend. Untuk Pernyataan Atribut Grup, kami sarankan Anda menambahkan role
ke bidang Nama dan ekspresi reguler .+
ke bidang Filter. Pernyataan ini memberi tahu penyedia identitas Okta untuk menyertakan semua grup pengguna di bawah role
bidang SAML pernyataan setelah pengguna mengautentikasi.
Di Pusat IAM Identitas, Anda menentukan ID entitas SP sebagai SAMLaudiens 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. XMLFile ini berisi informasi tentang penyedia, seperti TLS sertifikat, titik akhir masuk tunggal, dan ID entitas penyedia identitas.
Salin konten file metadata iDP dan tempelkan ke bidang Metadata dari iDP di konsol Layanan. OpenSearch Sebagai alternatif, pilih Impor dari XML file 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 SAML bidang
Setelah memasukkan metadata IDP, konfigurasikan bidang tambahan berikut dalam konsol Layanan: OpenSearch
-
ID entitas IDP — Salin nilai
entityID
properti 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”. -
SAMLnama pengguna SAML master dan peran backend master — Peran pengguna dan/atau backend yang Anda tentukan menerima izin penuh ke cluster, setara dengan pengguna master baru, tetapi hanya dapat menggunakan izin tersebut di dalam Dasbor. OpenSearch
Di Okta, misalnya, Anda mungkin memiliki pengguna
jdoe
yang termasuk dalam grupadmins
. Jika Anda menambahkanjdoe
ke bidang nama pengguna SAML utama, hanya pengguna yang menerima izin penuh. Jika Anda menambahkanadmins
ke bidang peran backend SAML master, setiap pengguna yang termasuk dalamadmins
grup akan menerima izin penuh.catatan
Isi SAML pernyataan harus sama persis dengan string yang Anda gunakan untuk nama pengguna SAML master dan SAML peran master. Beberapa penyedia identitas menambahkan awalan sebelum nama pengguna mereka, yang dapat menyebabkan ketidakcocokan hard-to-diagnose. Di antarmuka pengguna penyedia identitas, Anda mungkin melihat
jdoe
, tetapi SAML pernyataan mungkin berisi.auth0|jdoe
Selalu gunakan string dari SAML pernyataan.
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: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>
Langkah 5: (Opsional) Konfigurasikan pengaturan tambahan
Di bawah Pengaturan tambahan, konfigurasikan bidang opsional berikut:
-
Kunci subjek - Anda dapat membiarkan bidang ini kosong untuk menggunakan
NameID
elemen SAML pernyataan 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 atau.
role
group
Ini adalah situasi lain di mana alat seperti SAML-tracer dapat membantu. -
Waktu sesi untuk hidup - Secara default, OpenSearch Dasbor mengeluarkan pengguna 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 IDP Anda URLs
Jika Anda mengaktifkan SAML otentikasi saat membuat domain, Anda harus menentukan sementara URLs dalam IDP Anda untuk menghasilkan XML file metadata. Setelah status domain berubahActive
, Anda bisa mendapatkan yang benar URLs dan memodifikasi IDP Anda.
Untuk mengambilURLs, pilih domain dan pilih Tindakan, Edit konfigurasi keamanan. Di bawah SAMLotentikasi untuk OpenSearch Dasbor/Kibana, Anda dapat menemukan ID entitas penyedia layanan yang benar dan. SSO URLs Salin nilai dan gunakan untuk mengonfigurasi penyedia identitas Anda, menggantikan sementara URLs yang Anda berikan di langkah 2.
Langkah 7: Memetakan SAML pengguna ke peran
Setelah status domain Anda Aktif dan idP Anda dikonfigurasi dengan benar, navigasikan ke OpenSearch Dasbor.
-
Jika Anda memilih SP-initiated, navigasikan URL ke.
Untuk masuk ke penyewa tertentu secara langsung, Anda dapat menambahkandomain-endpoint
/_dashboards?security_tenant=
ke. URLtenant-name
-
Jika Anda memilih IDP-initiatedURL, navigasikan ke direktori aplikasi penyedia identitas Anda.
Dalam kedua kasus, masuk sebagai pengguna SAML utama atau pengguna yang termasuk dalam peran backend SAML master. 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 contoh permintaan 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 otentikasi yang diprakarsai SP dan IDP
Jika ingin mengonfigurasi autentikasi SP yang diinisiasi dan IDP yang diinisiasi Anda harus melakukannya melalui penyedia identitas. Misalnya, di Okta, Anda dapat melakukan langkah-langkah berikut:
-
Dalam SAML aplikasi Anda, buka Umum, SAMLpengaturan.
-
Untuk Single sign on URL, berikan IDP -initiated Anda. SSO URL Misalnya,
https://search-
.domain-hash
/_dashboards/_opendistro/_security/saml/acs/idpinitiated
-
Aktifkan Izinkan aplikasi ini untuk meminta lainnya SSO URLs.
-
Di bawah Requestable SSO URLs, tambahkan satu atau lebih SP -initiated. SSO URLs Misalnya,
https://search-
.domain-hash
/_dashboards/_opendistro/_security/saml/acs
Mengkonfigurasi SAML otentikasi ()AWS CLI
AWS CLI Perintah berikut memungkinkan SAML otentikasi untuk OpenSearch Dasbor pada domain yang ada:
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
"}}'
Anda harus melarikan diri dari 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 rinci tentang penggunaan AWS CLI, lihat Referensi AWS CLI Perintah.
Mengkonfigurasi SAML otentikasi (konfigurasi) API
Permintaan konfigurasi berikut API memungkinkan SAML otentikasi 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 melarikan diri dari 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 rinci tentang penggunaan konfigurasiAPI, lihat APIReferensi OpenSearch layanan.
SAMLpemecahan masalah
Kesalahan | Detail |
---|---|
|
Verifikasi bahwa Anda memberikan yang benar SSOURL(langkah 3) kepada penyedia identitas Anda. |
|
File metadata IDP Anda tidak sesuai dengan standar 2.0. SAML Periksa kesalahan menggunakan alat validasi. |
SAMLOpsi konfigurasi tidak terlihat di konsol. |
Perbarui ke perangkat lunak layanan terbaru. |
|
Kesalahan umum ini dapat terjadi karena berbagai alasan.
|
|
Anda berhasil mengautentikasi, tetapi nama pengguna dan peran backend apa pun dari SAML pernyataan tidak dipetakan ke peran apa pun dan karenanya tidak memiliki izin. Pemetaan ini peka huruf besar dan kecil. Administrator sistem Anda dapat memverifikasi konten SAML pernyataan Anda menggunakan alat seperti SAML-tracer
|
Browser Anda terus mengalihkan atau menerima HTTP 500 kesalahan saat mencoba mengakses OpenSearch Dasbor. |
Kesalahan ini dapat terjadi jika SAML pernyataan Anda berisi sejumlah besar peran dengan total 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, SAML pernyataan mendukung peran hingga 5000 karakter. |
Anda tidak dapat keluar dariADFS. |
ADFSmengharuskan semua permintaan logout ditandatangani, yang tidak didukung oleh OpenSearch Layanan. Hapus |
|
ID entitas dari IDP yang disediakan dalam metadata XML ke OpenSearch Layanan berbeda dari yang ada dalam respons. SAML Untuk memperbaikinya, pastikan mereka cocok. Aktifkan log Kesalahan Aplikasi CW di domain Anda untuk menemukan pesan kesalahan untuk men-debug masalah SAML integrasi. |
|
OpenSearch Layanan tidak dapat memverifikasi tanda tangan dalam SAML respons 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 metadata yang XML disediakan untuk OpenSearch Layanan melalui. AWS Management Console |
|
Bidang audiens dalam SAML respons 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 kustom, bidang audiens harus sesuai dengan titik akhir kustom Anda. Aktifkan log Kesalahan Aplikasi CW di domain Anda untuk menemukan pesan kesalahan untuk men-debug masalah SAML integrasi. |
Browser Anda menerima kesalahan HTTP 400 dengan |
Kesalahan ini umumnya terjadi jika Anda telah mengonfigurasi IDP yang dimulai URL dengan format. |
Tanggapan diterima di |
Bidang tujuan dalam SAML respons tidak cocok dengan salah satu URL format berikut:
Bergantung pada alur masuk yang Anda gunakan (dimulai SP atau dimulai IDP), masukkan bidang tujuan yang cocok dengan salah satu kolom. OpenSearch URLs |
Respons memiliki |
Anda menggunakan IDP yang diprakarsai URL untuk alur login yang diprakarsai SP. Gunakan URL SP-initiated sebagai gantinya. |
Menonaktifkan SAML otentikasi
Untuk menonaktifkan SAML otentikasi untuk OpenSearch Dasbor (konsol)
-
Pilih domain, Tindakan, dan Edit konfigurasi keamanan.
-
Hapus centang Aktifkan SAML otentikasi.
-
Pilih Simpan perubahan.
-
Setelah domain selesai diproses, verifikasi pemetaan peran kontrol akses berbutir halus dengan permintaan berikut:
GET _plugins/_security/api/rolesmapping
Menonaktifkan SAML otentikasi untuk Dasbor tidak menghapus pemetaan untuk nama pengguna SAML utama dan/atau 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
" ] }