Belajar LDAP - LDAP Proxy & Gateway Patterns
Membahas pola proxy dan gateway LDAP: kasus penggunaan load balancing dan caching, OpenLDAP sebagai proxy dengan back-ldap, penggabungan direktori lewat meta backend, jembatan ke database relasional dengan back-sql, hingga pertimbangan performa dan failover.
#Pendahuluan
Pada episode 22, kalian mengenal Active Directory sebagai server LDAP dan cara mengintegrasikannya dengan Linux. Episode 23 ini menaikkan level arsitektur: LDAP proxy dan gateway. Tidak semua aplikasi bisa langsung berbicara ke banyak direktori — AD di satu sisi, OpenLDAP di sisi lain, atau bahkan database SQL. Proxy LDAP menyatukan semuanya di belakang satu endpoint, sehingga aplikasi tetap memakai satu LDAP URL sederhana.
#Kapan Kalian Butuh Proxy LDAP
Sebuah proxy LDAP duduk di antara klien dan server direktori sesungguhnya. Klien hanya melihat proxy; proxy yang berurusan dengan kompleksitas di belakangnya. Kasus penggunaannya beragam:
- Load balancing — mendistribusikan search dan bind ke beberapa server di belakangnya.
- Caching layer — menyimpan hasil search populer agar mengurangi beban direktori sumber.
- Protocol translation — menormalkan akses ke direktori dengan karakteristik berbeda.
- Access control gateway — menegakkan kebijakan akses di satu titik sebelum mencapai direktori.
- Multi-backend aggregation — menyatukan beberapa direktori menjadi satu namespace virtual.
Skenario paling umum di dunia nyata: organisasi yang punya AD dan OpenLDAP sekaligus, atau yang punya beberapa OpenLDAP berbeda, ingin menampilkan semuanya sebagai satu direktori tunggal ke aplikasi.
#OpenLDAP sebagai Proxy: back-ldap
OpenLDAP punya backend back-ldap yang membuat instance slapd berperan sebagai proxy murni: menerima request dari klien dan meneruskannya ke server LDAP lain.
Konfigurasi proxy dengan back-ldap:
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: ldap
olcSuffix: dc=example,dc=com
olcDbURI: ldap://ldap01.example.com
olcDbBindDN: cn=proxy,ou=system,dc=example,dc=com
olcDbBindPW: secret
olcDbStartTLS: starttlsolcSuffix menentukan namespace yang dilayani proxy, dan olcDbURI menunjuk server target. Proxy bisa memakai akun bind sendiri untuk operasi tertentu, atau meneruskan identitas klien asli tergantung mode yang dipilih.
#Rebind dan Proxy Authentication
Ada beberapa strategi identitas di proxy:
- Bind as proxy — semua operasi memakai akun proxy tunggal; identitas klien tidak diteruskan.
- Rebind-as-user — proxy meneruskan kredensial klien ke server target, sehingga kebijakan server target tetap berlaku.
- Bind as proxy + ACL lokal — proxy meneruskan dengan akun proxy, lalu menegakkan otorisasi sendiri lewat ACL.
Rebind-as-user adalah pola yang paling transparan secara keamanan, karena audit tetap berlangsung di server target dengan identitas asli user. Konfigurasinya dengan olcRebindAsUser: yes. Kelemahannya: proxy harus menangani password klien di memori, sehingga TLS wajib diaktifkan antara klien dan proxy.
#Meta Backend: Menggabungkan Direktori
Jika back-ldap adalah proxy ke satu server, back-meta adalah proxy ke banyak server sekaligus — membentuk virtual directory. Proxy menerima search dan mendistribusikannya ke semua atau sebagian backend berdasarkan base dan filter.
dn: olcDatabase=meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: meta
olcSuffix: dc=example,dc=com
dn: olcDatabase={1}meta,cn=config
objectClass: olcMetaConfig
olcDbURI: "ldap://openldap.example.com/dc=internal,dc=example,dc=com"
olcDbURI: "ldap://dc01.example.com/dc=external,dc=example,dc=com"Dengan konfigurasi di atas, search pada base dc=example,dc=com akan didistribusikan: bagian yang cocok dengan dc=internal diteruskan ke OpenLDAP, dan dc=external ke AD. Meta backend memetakan namespace, sehingga satu aplikasi bisa query semua direktori tanpa tahu sumber aslinya.
#DIT Merging dan Search Distribution
Konsep kunci dari meta backend adalah DIT merging: kalian menggabungkan beberapa DIT (Directory Information Tree) menjadi satu namespace virtual. Saat search tiba, proxy memilih target berdasarkan bagaimana base request beririsan dengan URI masing-masing backend. Untuk search dengan filter luas, proxy bisa mengirim ke beberapa backend sekaligus lalu menggabungkan hasil. Ini membuka pintu untuk pola federation identitas sederhana tanpa teknologi federasi tambahan.
#SQL Backend: LDAP ke Database
Backend back-sql mengubah sebuah database relasional menjadi direktori LDAP. Klien melakukan bind dan search LDAP seperti biasa, tetapi datanya hidup di PostgreSQL atau MySQL.
dn: olcDatabase=sql,cn=config
objectClass: olcDatabaseConfig
objectClass: olcSqlConfig
olcDatabase: sql
olcSuffix: dc=example,dc=com
olcDbName: pgldap
olcDbHost: 127.0.0.1
olcDbUser: postgres
olcDbPass: secret
olcDbSqlTablePerson: persons#Data Mapping
back-sql menggunakan tabel mapping yang mendefinisikan bagaimana data relasional diterjemahkan ke entry LDAP. Tabel relasional dipetakan ke atribut directory melalui query SQL:
# tabel persons -> object class inetOrgPerson
map objectclass person inetOrgPerson
map attribute uid persons.uid
map attribute mail persons.email
map attribute sn persons.last_name
map attribute givenName persons.first_namemap attribute menentukan bahwa atribut LDAP mail berasal dari kolom email, dan uid dari kolom uid. Dengan mapping yang teliti, aplikasi LDAP bisa membaca data dari database yang sudah ada tanpa migrasi data.
#Use Cases
back-sql paling berguna saat data sudah hidup di database relasional — misalnya aplikasi lama yang user-nya di database, atau sistem HR yang menjadi sumber master karyawan. Alih-alih sinkronisasi dua arah yang rumit, back-sql membuat database itu sendiri menjadi direktori. Kekurangannya: performa search tidak sebaik backend mdb, dan operasi tulis harus dijaga ketat.
#Pertimbangan Performa
Proxy dan gateway menambah satu hop di jalur request. Perhatian ekstra diperlukan agar lapisan ini tidak menjadi titik lemah:
| Aspek | Pertimbangan |
|---|---|
| Connection pooling | Proxy harus memakai pool koneksi ke backend, bukan koneksi baru per request |
| Caching | Simpan hasil search statis (mapping, konfigurasi) agar tidak membebani backend |
| Query optimization | Filter yang buruk di klien menjadi buruk juga di backend — normalisasi di proxy |
| Failover handling | Daftar beberapa URI di olcDbURI agar proxy pindah saat server utama down |
#Connection Pooling dan Failover
Untuk failover, olcDbURI bisa berisi beberapa server sekaligus. Proxy mencoba server pertama, lalu berpindah saat gagal — transparan bagi klien. Load balancing bisa ditambahkan dengan DNS round-robin atau dengan meta backend yang mendistribusikan ke beberapa target.
Caching pada proxy LDAP perlu dipikirkan hati-hati: data yang berubah sering (password) tidak boleh di-cache lama, sementara data yang stabil (nama, alamat) bisa di-cache. Ini sebabnya kebanyakan proxy diimplementasikan dengan kebijakan cache per-attr yang bisa dikonfigurasi.
#Penutup
Pada episode 23 ini, kalian menguasai pola proxy dan gateway LDAP: kasus penggunaan load balancing, caching, dan access control gateway; OpenLDAP sebagai proxy dengan back-ldap; penggabungan direktori dengan meta backend menjadi virtual directory; jembatan ke database relasional lewat back-sql; serta pertimbangan performa seperti connection pooling, caching, dan failover.
Inti yang harus dibawa pulang:
- Proxy menyembunyikan kompleksitas — aplikasi cukup melihat satu endpoint LDAP.
back-ldapuntuk satu target,back-metauntuk banyak target.- Rebind-as-user menjaga identitas asli untuk audit dan kebijakan di server target.
- back-sql membuka data relasional ke klien LDAP tanpa migrasi.
Di episode 24 berikutnya, kalian memasuki fase administrasi dan produksi: backup dan restore — strategi offline dan online, penggunaan slapcat dan slapadd, continuous replication sebagai backup, hingga point-in-time recovery. Arsitektur yang kalian bangun sejak episode ini akan membutuhkan keseluruhan strategi pemulihan itu agar benar-benar siap produksi.