Otentikasi PHP terhadap layanan LDAP

Saya melihat masalah ini banyak di berbagai skrip PHP yang terhubung ke layanan LDAP .. Masalah tidak terisolasi dengan lingkungan PHP saja, tapi untuk beberapa alasan aneh, pengembang PHP pada akhirnya mayoritas di perangkap ini, sedangkan pengembang untuk menggunakan bahasa pemrograman populer lainnya biasanya menangani masalah ini lebih baik.

Pengantar masalah

Otentikasi layanan LDAP sering menimbulkan tantangan bagi para pengembang yang terlibat dalam pengembangan layanan LDAP tergantung untuk pertama kalinya. Secara umum, input data Anda akan username dan password, sedangkan untuk otentikasi sukses LDAP Anda membutuhkan info yang berbeda: DN (nama dibedakan) dan password.
Jadi, agar dapat mengotentikasi kredensial pengguna terhadap layanan LDAP, Anda harus membuat hubungan antara nama pengguna sebagai variabel input dan DN sebagai parameter layanan LDAP mengharapkan.
Sekali lagi, layanan LDAP sangat spesifik dengan pendekatan terhadap pengguna, password dan otentikasi. Anda mungkin bisa mengambil DN menggunakan query seperti
... Bahkan ketika mengikat server Anda anonim. Tentu saja, itu tergantung pada konfigurasi layanan LDAP Anda, tapi itu tidak begitu jarang terjadi bahwa layanan LDAP memungkinkan informasi dasar seperti DN untuk dibaca melalui koneksi anonim. Harus itu diperbolehkan adalah diskusi untuk beberapa benar-benar kesempatan lain.
Tapi masalahnya dimulai hanya di sini.

Implementasi bermasalah otentikasi LDAP di aplikasi client

Lebih dari sering, pengembang dan sysadmin poin logika ke arah menyiapkan ACL dalam pelayanan LDAP dengan cara yang setidaknya satu (aplikasi spesifik) pengguna LDAP dapat menyapu pohon LDAP keseluruhan dan membaca atribut operasional (dalam hal ini userPassword, atau bidang lain yang berisi password pengguna).
Ide di balik ini adalah bahwa logika yang sama yang digunakan untuk mengikat bersama username dari input pengguna dengan informasi dari DN LDAP tidak juga validasi password.
Kemudian setelah DN ditemukan, aplikasi membaca userPassword (atau bidang lain yang berisi password pengguna di setup yang diberikan) dan membandingkannya dengan aplikasi apa berpikir password harus (aplikasi membuat hash password dengan sendirinya dari teks biasa sandi pengguna memberikan pada login , dan kemudian membandingkannya terhadap password terenkripsi [hash password untuk lebih tepatnya] ditarik dari LDAP):
Dan voila! Masalah dipecahkan, bukan? Tanpa banyak komplikasi, aplikasi berhasil dikonfirmasi pengguna terhadap layanan LDAP.
Nah, terus kuda Anda Johhny. :)

Masalah dunia nyata dengan pendekatan di atas

Memang, kode seperti di atas mungkin tampak seperti sebuah pekerjaan dilakukan untuk Anda. Sama seperti mudahnya mungkin ternyata bahwa ia melakukan pekerjaan dengan sempurna. Tetapi ada beberapa masalah yang jelas dengan pendekatan ini:
  1. Layanan LDAP mendukung setidaknya beberapa mekanisme hashing password. Contoh di atas menerapkan hanya satu (mekanisme hashing CRYPT), tetapi Anda harus menerapkan mereka semua dalam aplikasi Anda agar pendekatan ini berfungsi dengan baik (itu terlalu mudah untuk mencampur jenis hashing password ketika mengelola LDAP - semua alat administrasi yang layak untuk LDAP mendukung sebagian besar jika tidak semua mekanisme hashing sandi layanan LDAP Anda menyadari.
  2. Anda mengandalkan pada kenyataan bahwa bahasa pemrograman atau kerangka pembangunan pilihan Anda telah benar-benar implementasi hashing yang sama seperti layanan LDAP Anda. Hal ini tidak perlu yang benar, meskipun dalam berbagai kasus penggunaan dunia nyata mungkin adalah.
    • Bahkan jika begitu saat ini, tidak mungkin dengan beberapa OS / jasa / update bahasa pemrograman server berikutnya. Keamanan adalah daerah yang berubah dengan cepat ilmu komputer dan praktek.
  3. Anda, untuk tujuan ini setidaknya, sama sekali tidak perlu memungkinkan setidaknya satu pengguna dari layanan LDAP untuk membaca password pengguna. Meskipun mereka biasanya hash, saya harap Anda dapat melihat masalah dari pendekatan ini.

Dan akhirnya, solusi

Jika Anda telah diakui coding praktek Anda dalam contoh di atas, solusinya adalah jauh lebih mudah daripada yang Anda mungkin akan berpikir. :)
Alih-alih memiliki dedicated pengguna pada sistem LDAP Anda yang dapat membaca semua password pengguna ', Anda hanya perlu (demi otentikasi setidaknya) salah satu yang harus mampu membaca, tapi benar-benar, hanya uid (atau atribut setara yang memegang username pada setup anda) dan bidang DN dari LDAP.
Kemudian untuk memulai proses otentikasi Anda akan, sama seperti sebelumnya, mengikat sebagai pengguna khusus (atau bahkan tidak - seperti yang saya sebutkan di awal artikel - info yang mungkin hanya dapat dibaca oleh pengguna anonim mengikat pada LDAP layanan). Anda akan, lagi sama seperti sebelumnya, mencari DN berdasarkan masukan pengguna kolom username.
Namun, selisih dengan praktek sebelumnya, kali ini Anda tidak membaca isi kolom password.
Sebaliknya, Anda mengambil yang baru ditemukan DN dan mengikat sekali lagi untuk layanan LDAP dengan yang baru ditemukan DN   informasi dan password user-disediakan.
Jika mengambil DN gagal, pengguna tidak memasukkan username yang benar.
Jika mengikat dengan terbentuk dengan baik DN Anda telah diambil dari LDAP berdasarkan username dipasangkan dengan pengguna yang disediakan gagal password, pengguna memasukkan password yang salah (dengan asumsi, tentu saja, semua ok dengan LDAP layanan :)).
Dalam prakteknya, hal itu terlihat agak seperti ini:
Tentu saja, Anda akan melakukannya dengan cara yang lebih elegan. Kode ini hanya sebuah mudah mengikuti contoh tentang bagaimana benar melakukan otentikasi LDAP dari PHP.
Harap Anda menikmati artikel ini, yang serupa lainnya akan mengikuti.

Share this

Related Posts

Previous
Next Post »