Mengintegrasikan broker ActiveMQ dengan LDAP - Amazon MQ
Integrasikan LDAP dengan ActiveMQPrasyaratMemulai dengan LDAPBagaimana LDAP integrasi bekerja

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengintegrasikan broker ActiveMQ dengan LDAP

penting

LDAPintegrasi tidak didukung untuk broker RabbitMQ.

Amazon MQ tidak mendukung sertifikat server yang dikeluarkan oleh CA pribadi.

Anda dapat mengakses broker ActiveMQ Anda menggunakan protokol berikut dengan diaktifkan: TLS

Amazon MQ menawarkan pilihan antara otentikasi ActiveMQ asli dan otentikasi dan LDAP otorisasi untuk mengelola izin pengguna. Untuk informasi tentang pembatasan yang berkaitan dengan nama pengguna dan kata sandi ActiveMQ, lihat Pengguna.

Untuk mengotorisasi pengguna dan grup ActiveMQ agar dapat bekerja dengan antrean dan topik, Anda harus mengedit konfigurasi broker. Amazon MQ menggunakan Plugin Autentikasi Sederhana ActiveMQ untuk membatasi baca dan tulis ke tujuan. Untuk informasi selengkapnya dan contoh tambahan, lihat Selalu konfigurasikan peta otorisasi dan authorizationEntry.

catatan

Saat ini, Amazon MQ tidak mendukung Autentikasi Sertifikat Klien.

Integrasikan LDAP dengan ActiveMQ

Anda dapat mengautentikasi pengguna Amazon MQ melalui kredenal yang disimpan di server protokol akses direktori ringan () Anda. LDAP Anda juga dapat menambahkan, menghapus, dan memodifikasi pengguna Amazon MQ serta menetapkan izin untuk topik juga antrean dari sana. Operasi manajemen seperti membuat, memperbarui, dan menghapus broker masih memerlukan IAM kredensi dan tidak terintegrasi dengannya. LDAP

Pelanggan yang ingin menyederhanakan dan memusatkan otentikasi dan otorisasi broker Amazon MQ mereka menggunakan server dapat menggunakan LDAP fitur ini. Menjaga semua kredensi pengguna di LDAP server menghemat waktu dan tenaga dengan menyediakan lokasi pusat untuk menyimpan dan mengelola kredensi ini.

Amazon MQ menyediakan LDAP dukungan menggunakan plugin Apache JAAS ActiveMQ. LDAPServer apa pun, seperti Microsoft Active Directory atau Open LDAP yang didukung oleh plugin juga didukung oleh Amazon MQ. Untuk informasi selengkapnya tentang plugin, lihat bagian Keamanan dalam dokumentasi ActiveMQ.

Selain pengguna, Anda dapat menentukan akses ke topik dan antrian untuk grup tertentu atau pengguna melalui server AndaLDAP. Anda melakukan ini dengan membuat entri yang mewakili topik dan antrian di LDAP server Anda dan kemudian menetapkan izin untuk pengguna atau grup tertentuLDAP. Anda kemudian dapat mengkonfigurasi broker untuk mengambil data otorisasi dari server. LDAP

Prasyarat

Sebelum Anda menambahkan LDAP dukungan ke broker Amazon MQ baru atau yang sudah ada, Anda harus menyiapkan akun layanan. Akun layanan ini diperlukan untuk memulai koneksi ke LDAP server dan harus memiliki izin yang benar untuk membuat koneksi ini. Akun layanan ini akan menyiapkan LDAP otentikasi untuk broker Anda. Setiap koneksi klien berturut-turut akan diautentikasi melalui koneksi yang sama.

Akun layanan adalah akun di LDAP server Anda, yang memiliki akses untuk memulai koneksi. Ini adalah LDAP persyaratan standar dan Anda harus memberikan kredensi akun layanan hanya sekali. Setelah koneksi diatur, semua koneksi klien future diautentikasi melalui LDAP server Anda. Kredensial akun layanan Anda disimpan dengan aman dalam bentuk terenkripsi, yang hanya dapat diakses oleh Amazon MQ.

Untuk mengintegrasikan dengan ActiveMQ, Directory Information Tree DIT () tertentu diperlukan di server. LDAP Untuk contoh ldif file yang dengan jelas menunjukkan struktur ini, lihat Mengimpor LDIF file berikut ke LDAP server di bagian Keamanan dari dokumentasi ActiveMQ.

Memulai dengan LDAP

Untuk memulai, navigasikan ke konsol Amazon MQ dan pilih LDAPotentikasi dan otorisasi saat Anda membuat Amazon MQ baru atau mengedit instans broker yang ada.

Berikan informasi berikut tentang akun layanan:

  • Nama domain yang sepenuhnya memenuhi syarat Lokasi LDAP server tempat permintaan otentikasi dan otorisasi akan dikeluarkan.

    catatan

    Nama domain yang sepenuhnya memenuhi syarat dari LDAP server yang Anda berikan tidak boleh menyertakan protokol atau nomor port. Amazon MQ akan menambahkan nama domain yang sepenuhnya memenuhi syarat dengan protokol ldaps, dan akan menambahkan nomor port 636.

    Misalnya, jika Anda menyediakan domain yang memenuhi syarat berikut ini: example.com Amazon MQ akan mengakses LDAP server Anda menggunakan yang berikut URL ini: ldaps://example.com:636

    Agar host broker dapat berhasil berkomunikasi dengan LDAP server, nama domain yang sepenuhnya memenuhi syarat harus dapat diselesaikan secara publik. Untuk menjaga LDAP server tetap pribadi dan aman, batasi lalu lintas masuk dalam aturan masuk server untuk hanya mengizinkan lalu lintas yang berasal dari dalam broker. VPC

  • Nama pengguna akun layanan Nama pengguna yang dibedakan yang akan digunakan untuk melakukan ikatan awal ke LDAP server.

  • Kata sandi akun layanan Kata sandi pengguna yang melakukan ikatan awal.

Gambar berikut menyoroti tempat untuk memasukkan detail ini.

Tempat menentukan detail akun LDAP layanan.

Di bagian konfigurasi LDAP login, berikan informasi yang diperlukan berikut:

  • Basis Pengguna Nama yang dibedakan dari node di pohon informasi direktori (DIT) yang akan dicari pengguna.

  • Pencocokan LDAP Pencarian Pengguna Filter pencarian yang akan digunakan untuk menemukan pengguna di dalam fileuserBase. Nama pengguna klien akan diganti ke dalam placeholder {0} di filter pencarian. Untuk informasi selengkapnya, silakan lihat Autentikasi dan Otorisasi.

  • Basis Peran Nama node yang dibedakan dalam DIT yang akan dicari peran. Peran dapat dikonfigurasi sebagai entri LDAP grup eksplisit di direktori Anda. Entri peran umum dapat terdiri dari satu atribut untuk nama peran, seperti nama umum (CN), dan atribut lain, seperti member, dengan nilai yang mewakili nama khas atau nama pengguna yang termasuk dalam grup peran. Sebagai contoh, dengan unit organisasi, group, Anda dapat memberikan nama khas berikut: ou=group,dc=example,dc=com.

  • Pencocokan Pencarian LDAP Peran Filter penelusuran yang akan digunakan untuk menemukan peran dalam fileroleBase. Nama khas pengguna dicocokkan yang menurut userSearchMatching akan diganti ke dalam placeholder {0} di filter pencarian. Nama pengguna klien akan diganti dalam placeholder {1}. Misalnya, jika entri peran dalam direktori Anda menyertakan atribut bernama member, yang berisi nama pengguna untuk semua pengguna dalam peran tersebut, Anda dapat menyediakan filter pencarian berikut: (member:=uid={1}).

Gambar berikut menyoroti tempat untuk menentukan detail ini.

Tempat menentukan detail LDAP login.

Di bagian Pengaturan opsional, Anda dapat memberikan informasi opsional berikut:

  • Nama Peran Pengguna Nama LDAP atribut dalam entri direktori pengguna untuk keanggotaan grup pengguna. Dalam beberapa kasus, peran pengguna dapat diidentifikasi menurut nilai atribut dalam entri direktori pengguna. Opsi userRoleName memungkinkan Anda untuk memberikan nama bagi atribut ini. Sebagai contoh, mari kita pertimbangkan entri pengguna berikut:

    dn: uid=jdoe,ou=user,dc=example,dc=com
objectClass: user
uid: jdoe
sn: jane
cn: Jane Doe
mail: j.doe@somecompany.com
memberOf: role1
userPassword: password

    Untuk memberikanuserRoleName yang benar bagi contoh di atas, Anda akan menentukan atribut memberOf. Jika autentikasi berhasil, pengguna ditetapkan peran role1.

  • Nama Peran Atribut nama grup dalam entri peran yang nilainya adalah nama peran tersebut. Misalnya, Anda dapat menentukan cn untuk entri grup nama umum. Jika autentikasi berhasil, pengguna ditetapkan nilai atribut cn untuk setiap entri peran tempat mereka menjadi anggota.

  • Subpohon Pencarian Pengguna Mendefinisikan ruang lingkup untuk permintaan pencarian LDAP pengguna. Jika benar, ruang lingkup diatur untuk mencari seluruh subpohon di bawah simpul yang ditentukan menurut userBase.

  • Subpohon Pencarian Peran Mendefinisikan ruang lingkup untuk kueri LDAP penelusuran peran. Jika benar, ruang lingkup diatur untuk mencari seluruh subpohon di bawah simpul yang ditentukan menurut roleBase.

Gambar berikut menyoroti tempat untuk menentukan pengaturan opsional ini.

Optional settings for LDAP attributes and search scope in role search matching.

Bagaimana LDAP integrasi bekerja

Anda bisa memikirkan integrasi dalam dua kategori utama: struktur untuk autentikasi, dan struktur untuk otorisasi.

Autentikasi

Untuk autentikasi, kredensial klien harus valid. Kredensi ini divalidasi terhadap pengguna di basis pengguna di server. LDAP

Basis pengguna yang dipasok ke broker ActiveMQ harus menunjuk ke node di DIT mana pengguna disimpan di server. LDAP Misalnya, jika Anda menggunakan AWS Managed Microsoft AD, dan Anda memiliki komponen domain,, dan corp examplecom, dan di dalamnya Anda memiliki unit organisasi corp danUsers, Anda akan menggunakan yang berikut ini sebagai basis pengguna Anda:

OU=Users,OU=corp,DC=corp,DC=example,DC=com

Broker ActiveMQ akan mencari di DIT lokasi ini untuk pengguna untuk mengotentikasi permintaan koneksi klien ke broker.

Lokasi untuk mencari pengguna

Karena kode sumber ActiveMQ meng-hardcode nama atribut untuk pengguna menjadi uid, Anda harus memastikan bahwa setiap pengguna telah menetapkan atribut ini. Untuk lebih sederhana, Anda dapat menggunakan nama pengguna koneksi pengguna. Untuk informasi selengkapnya, lihat kode sumber activemq dan Mengonfigurasi pemetaan ID di Pengguna dan Komputer Direktori Aktif untuk versi Windows Server 2016 (dan berikutnya).

Untuk mengaktifkan akses konsol ActiveMQ bagi pengguna tertentu, pastikan mereka merupakan anggota grup amazonmq-console-admins.

Otorisasi

Untuk otorisasi, basis pencarian izin ditentukan dalam konfigurasi broker. Otorisasi dilakukan dengan basis per tujuan (atau wildcard, set tujuan) melalui elemen cachedLdapAuthorizationMap, yang ditemukan dalam file konfigurasi activemq.xml broker. Untuk informasi selengkapnya, lihat Modul LDAPOtorisasi Cache.

catatan

Untuk dapat menggunakan cachedLDAPAuthorizationMap elemen dalam file activemq.xml konfigurasi broker Anda, Anda harus memilih opsi LDAPOtentikasi dan Otorisasi saat membuat konfigurasi melalui AWS Management Console, atau mengatur authenticationStrategyproperti LDAP saat membuat konfigurasi baru menggunakan Amazon MQ. API

Anda harus memberikan tiga atribut berikut sebagai bagian dari elemen cachedLDAPAuthorizationMap:

  • queueSearchBase

  • topicSearchBase

  • tempSearchBase

penting

Agar informasi sensitif tidak langsung ditempatkan ke file konfigurasi broker, Amazon MQ memblokir atribut berikut dari agar tidak digunakan dalam cachedLdapAuthorizationMap:

  • connectionURL

  • connectionUsername

  • connectionPassword

Saat Anda membuat broker, Amazon MQ mengganti nilai yang Anda berikan melalui AWS Management Console, atau di ldapServerMetadataproperti API permintaan Anda, untuk atribut di atas.

Hal berikut mendemonstrasikan contoh kerja cachedLdapAuthorizationMap.

<authorizationPlugin>
    <map>
        <cachedLDAPAuthorizationMap
            queueSearchBase="ou=Queue,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            topicSearchBase="ou=Topic,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            tempSearchBase="ou=Temp,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            refreshInterval="300000"
            legacyGroupMapping="false"
        />
    </map>
</authorizationPlugin>

Nilai-nilai ini mengidentifikasi lokasi di DIT mana izin untuk setiap jenis tujuan ditentukan. Jadi untuk contoh di atas dengan AWS Managed Microsoft AD, menggunakan komponen domain yang sama dari corpexample,com, dan, Anda akan menentukan unit organisasi bernama destination berisi semua jenis tujuan Anda. Dalam OU tersebut, Anda akan membuat satu untuk queues, satu untuk topics, dan satu untuk tujuan temp.

Ini berarti bahwa basis pencarian antrian Anda, yang menyediakan informasi otorisasi untuk tujuan jenis antrian, akan memiliki lokasi berikut di: DIT

OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
Lokasi basis pencarian antrean.

Demikian pula, aturan izin untuk topik dan tujuan sementara akan ditempatkan pada tingkat yang sama di: DIT 

OU=Topic,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
OU=Temp,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

Dalam OU untuk setiap jenis tujuan (antrean, topik, sementara), baik wildcard atau nama tujuan tertentu dapat disediakan. Misalnya, untuk memberikan aturan otorisasi untuk semua antrian yang dimulai dengan awalan. DEMO EVENTS.$., Anda dapat membuat OU berikut:

OU=DEMO.EVENTS.$,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
catatan

OU DEMO.EVENTS.$ berada di dalam OU Queue.

Untuk info selengkapnya tentang wildcard di ActiveMQ, lihat Wildcard

Untuk memberikan aturan otorisasi untuk antrian tertentu, seperti. DEMO MYQUEUE, tentukan sesuatu seperti berikut:

OU=DEMO.MYQUEUE,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
Aturan otorisasi untuk antrean tertentu

Grup Keamanan

Dalam setiap OU yang mewakili tujuan atau wildcard, Anda harus membuat tiga grup keamanan. Seperti semua izin di ActiveMQ, ini adalah izin baca/tulis/admin. Untuk informasi selengkapnya tentang hal yang dapat dilakukan pengguna dengan setiap izin tersebut, lihat Keamanan dalam dokumentasi ActiveMQ.

Anda harus memberi nama grup keamanan ini read, write, dan admin. Dalam setiap grup keamanan ini, Anda dapat menambahkan pengguna atau grup, yang kemudian akan memiliki izin untuk melakukan tindakan terkait. Anda memerlukan grup keamanan ini untuk setiap rangkaian tujuan wildcard atau tujuan individual.

Grup keamanan
catatan

Ketika Anda membuat grup admin, konflik akan muncul dengan nama grup. Konflik ini terjadi karena aturan pra-Windows 2000 lama tidak mengizinkan grup untuk berbagi nama yang sama, bahkan jika grup berada di lokasi yang berbeda dari. DIT Nilai di dalam kotak teks pra-Windows 2000 tidak berdampak pada penyiapan, tetapi harus unik secara global. Untuk menghindari konflik ini, Anda dapat menambahkan sufiks uuid ke setiap grup admin.

Ini adalah citra saya.

Menambahkan pengguna ke grup keamanan admin untuk tujuan tertentu akan memungkinkan pengguna untuk membuat dan menghapus topik tersebut. Menambahkannya ke grup keamanan read akan memungkinkan mereka untuk membaca dari tujuan, dan menambahkannya ke grup write akan memungkinkan mereka untuk menulis ke tujuan.

Selain menambahkan pengguna individu ke izin grup keamanan, Anda juga dapat menambahkan seluruh grup. Namun, karena ActiveMQ meng-hardcode atribut nama untuk grup, Anda harus memastikan bahwa grup yang ingin Anda tambahkan memiliki kelas objek groupOfNames, seperti yang ditampilkan dalam kode sumber activemq.

Untuk melakukannya, ikuti proses yang seperti uid bagi pengguna. Lihat Mengonfigurasi pemetaan ID di Pengguna dan Komputer Direktori Aktif untuk versi Windows Server 2016 (dan berikutnya).