LDAP merupakan singkatan dari Lightweight Directory Access Protocol.

Artinya, adalah protokol kelas ringan untuk mengakses servis direktori, yang berdasarkan pada protokol servis direktori X.500. LDAP berjalan melalui protokol TCP/P. Pendefinisian secara detail LDAP ada dalam RFC 225l "The Lightweight Directory Access Protocol (v3)" dan dokumen lainnya menyatakan spesifikasi teknik ada pada RFC 3377. Model informasi LDAP adalah berdasarkan entri. Sebuah entri adalah koleksi atribut yang mempunyai nama yang terbedakan (Distinguished Name/DN) secara global. DN ini digunakan sebagai referensi ke entri yang secara unik berbeda dengan nilai DN yang lainnya. Setiap atribut entri mempunyai sebuah tipe dengan satu nilai atau lebih. Tipe biasanya string singkatan khusus, seperti "cn" untuk common name, atau "mail" untuk alamat e-mail. Secara teknis, LDAP adalah sebuah protokol untuk mengakses ke servis direktori X.500, yang merupakan direktori servis yang diatur oleh OSL Awalnya, client LDAP mengakses gateway ke servis direktori X.500. Gateway ini menjalankan LDAP di antara client dan gateway, dan menjalankan Protokol Akses Direktori (Directory Access Protocol/DAP) X.500 antara gateway dan X.500 server. DAP adalah sebuah protokol kelas berat yang beroperasi melalui tumpukan protokol OSI secara penuh dan memerlukan pemrosesan yang sangat signifikan dari sumber daya komputasi. LDAP didesain untuk beroperasi melalui TCP/IP dan menyediakan sebagian besar dari fungsi DAP dengan biaya yang lebih rendah. Request for Comments (RFC) adalah salah satu dari seri dokumen infomasi dan standar internet bernomor yang diikuti secara luas oleh perangkat lunak untuk digunakan dalam jaringan, internet dan beberapa sistem operasi jaringan, mulai dari Unix, Windows dan Novell NetWare. RFC kini diterbitkan di bawah arahan Internet Society (ISOC) dan badan-badan penyusun-standar teknisnya, seperti Internet Engineering Task Force (IETF) atau Internet Research Task Force (IRTF). Semua standar internet dan juga TCP/IP selalu dipublikasikan dalam RFC, meskipun tidak semua RFC mendefinisikan standar internet.

Request for Comments (RFC) menyepakati keberadaan LDAP hal ini dapat di lihat pada RFC 1777. Selain itu terdapat beberapa dokumen dari RFC yang mengatur mekanisme kerja dari LDAP, dokumen RFC yang mengatur mekanisme dari LDAP antara lain RFC 4511, RFC 4512, RFC 4513 dll. Pada RFC 4511 berisi dokumen tentang protokol dari LDAP, Model umum dari protokol ini adalah salah satu klien melakukan operasi protokol terhadap server. Dalam model ini, klien mengirimkan permintaan protokol

menggambarkan operasi yang akan dilakukan untuk server. Server kemudian bertanggung jawab untuk melakukan operasi yang diperlukan (s) dalam Direktori. Setelah menyelesaikan suatu operasi, server mengembalikan sebuah respon yang biasanya mengandung data yang sesuai ke klien yang meminta. Protokol operasi umumnya independen satu sama lain. Setiap operasi diproses sebagai tindakan atom, meninggalkan direktori dalam keadaan yang konsisten. Permintaan dan tanggapan untuk beberapa operasi secara umum dapat dipertukarkan antara klien dan server dalam urutan apapun. Jika diperlukan, sinkron dapat dikontrol oleh aplikasi client. Terdapat beberapa elemen pada protokol ini. Diantaranya adalah Elemen Umum, Operasi Bind, Extended Operation, Operasi Modifikasi DN, dll. Pada elemen umum, di jelaskan format Protocol Data Unit dari LDAPMessage Envelope yang akan digunakan pada operasi protokol. Disini dijelaskan untuk keperluan pertukaran protokol, maka semua operasi protokol harus dikemas dalam amplop yaitu LDAPMessage. Fungsi LDAPMessage adalah untuk memberikan sebuah amplop berisi messageID dan kontrol diperlukan dalam semua pertukaran protokol. Permintaan messageID HARUS memiliki nilai bukan nol yang berbeda dari messageID dari permintaan lain yang berlangsung di sesi LDAP yang sama Nilai nol pada messageID dicadangkan dan digunakan untuk pemberitahuan yang tidak meminta pesan. Sedangkan Operasi Bind berfungsi untuk mengotentikasi pesan yang ditukar antara klien dengan server. Permintaan dari operasi Bind atau BindRequest terbagi atas 3 bidang, yaitu : (1) Versi, versi disini dimaksudkan

sebagai petunjuk sebuah nomor dari versi protokol yang dipakai pada lapisan pesan LDAP. (2) Nama, jika tidak terdapat nama direktori pada operasi ini, maka nama yang dipakai adalah Null. Hal ini bertujuan apabila terdapat sebuah server yang berupaya mencari nama obyek, maka server itu tidak akan melakukan dereferncing. (3) Otentikasi, sebelum mentransfer data, klien harus

mempersiapkan sebuah teks password sebagai permintaan dengan menerapkan SASLprep. Dokumen RFC 4512 menjelaskan tentang Model Direktori Informasi pada LDAP. Model direktori ini bertujuan untuk menahan dan memberikan akses, informasi tentang obyek yang menarik. Sebuah obyek dapat berupa apapun yang dapat diidentifikasi. Sebuah obyek setidaknya memiliki sebuah kelas. Kelas obyek adalah sebuah frame yang dapat mengidentifikasikan sebuah obyek yang berbagi karakteristik tertentu. Sebuah direktori juga memiliki entri. Entri direktori adalah sekumpulan informasi atau sebuah dasar unit informasi yang diadakan didalam direktori. Himpunan entri pada direktori diorganisir secara hirarki dalam struktur pohon yang dikenal sebagai Directory Information Tree ( Dit ). Struktur dari entri pada Directory Information Base terdiri dari satu set atribut yang menyimpan informasi tentang obyek yang mewakili entri. Beberapa atribut merepresentasikan penggunaan informasi dan disebut sebagai atribut user. Atribut lain yang merepresentasikan informasi operasional atau administratif disebut atribut operasional. Setiap entri yang bernama relatif terhadap kelas d atasnya dikenal sebagai Relatif Distinguished Name (RDN). Nama dari sebuah entri harus unik antara subclass dan super class-nya. Sebuah entri yang memenuhi syarat penamaan disebut sebagai Distinguished Name (DN).DN merupakan gabungan dari RDN. DN mengacu pada sebuah entri pada hirarki pohon. Pada Model Informasi Direktori yang dijelaskan pada RFC 4512 ini terdapat bagian Direktori Administratif dan Operasional Informasi. Pada bagian ini menjelaskan tentang subtrees, subentries, atribut objectClass, dan atribut operasional.

Subtrees atau sub pohon merupakan kumpulan obyek dan entri yang terletak di simpul pohon. Sub pohon tidak mengandung subentri. Sub pohon biasanya dimulai dibeberapa titik dan meluas ke beberapa identifikasi batas yang lebih rendah. Sebuah subtree atau sub pohonselalu didefinisikan dalam konteks yang secara implisit sampai ke batas subtree. Subentries merupakan sebuah entri khusus, yang dikenali oleh direktori dan digunakan untuk menyimpan informasi yang terkait dengan penyempurnaan / perbaikan dari subtree. Istilah subentri dalam spesifikasi ini menunjukan bahwa server menerapkan model X.500 (93), pada model tersebut dijelaskan untuk menggunakan subentry dan sebagai server lain harus menggunakan objek entri milik kelas tambahan yang sesuai biasanya digunakan dengan subentry untuk meniru subentry tersebut. RDN pada entri ini akan menjadi obyek yang terbentuk dari nilai atribut cn (commonName). Atribut objectClass, setiap di dalam Directory Information Tree (Dit) memiliki atribut objectClass. Atribut objectClass disini akan menentukan kelas obyek dari entri, antara lain yang digunakan dalam mengendalikan skema untuk dapat menentukan atribut. Nilai dari atribut ini dapat dimodifikasi oleh klien, namun atribut objectClass tidak dapat dihapus. Server yang mengikuti model X.500(93) akan membatasi modifikasi atribut, hal ini dilakukan untuk mencegah terjadinya kelas struktural dasar dari entri yang berubah. Ketika akan membuat sebuah entri atau menambahkan nilai objectClass untuk sebuah entri, semua superclass yang bernama Class akan secara implisit ditambahkan walaupun kelas tersebut sudah ada sebelumnya. Atribut Operasional, sebuah atribut akan dinamakan sebagai atribut operasional jika atribut tersebut digunakan oleh server untuk tujuan administrasi dan operasional. Sebuah direktori atribut operasional digunakan untuk memperesentasikan operasional atau administrasi dari informasi di dalam Model Direktori Informasi. Hal ini termasuk atribut operasional dikelola oleh server, dan atribut operasional yang mengandung nilai-nilai dikelola oleh user.

Dokumen RFC selanjutnya yaitu RFC 4513, pada dokumen RFC ini membahas tentang mekanisme otentikasi dan mekanisme keamanan dari LDAP. Dikarenakan LDAP adalah sebuah protokol untuk mengakses direktori yang menawarkan cara untuk mecari, mengambil, dan memanipulasi isi dari direktori, maka sangatlah penting untuk mengetahui fungsi fungsi keamanan yang dapat dioperasikan diantara semua klien dan server LDAP. Berikut adalah macam macam ancaman yang termasuk ke dalam layanan direktori LDAP. (1) akses tidak sah ke dalam direktori data melalui operasi pengambilan data. (2) akses tidak sah ke dalam data direktori melalui akses monitoring lainnya. (3) modifikasi data direktori yang tidak sah. (4) konfigurasi modifikasi informasi yang tidak sah. (5) Denial of Service. (6) Spoofing. (7) Hijacking. Dll. Semua ancaman di atas merupakan serangan aktif, kecuali ancaman nomor 2. Dikarenakan terdapat ancaman ancaman yang telah di sebutkan diatas, maka LDAP menawarkan beberapa mekanisme keamanan. Mekanisme keamanan tersebut adalah : (1) Otentikasi dengan cara operasi Bind. (2) Intergritas layanan data dengan cara lepisan keamanan pada Transport Layer Security (TLS) atau mekanisme SASL. (3) Server otentikasi dengan cara mekanisme protokol TLS atau SASL. (4) Penggunaan server administratif yang terbatas. Implementasi dari LDAP harus mendukung otentikasi anonim dari mekanisme metode operasi Bind. Implementasi LDAP yang mendukung

mekanisme otentikasi lainnya selain mekanisme otentikasi anonim metode operasi Bind harus mendukung mekanisme otentikasi password / nama dari operasi Bind, dan harus mampu melindungi otentikasi nama/ passwordnya menggunakan

mekanisme TLS sebagaimana ditetapkan oleh operasi STARTTLS. Implementasi LDAP tidak mengijinkan penggunaan nama / password secara default. Implementasi LDAP server harus mendukung pernyataan otoritas dari identitas klien melalui mekanisme EXTERNAL SASL. LDAP server yang mendukung implementasi tidak mempunyai mekanisme otentikasi selain mekanisme otentikasi anonim yang mendukung penggunaan TLS, sebagaimana ditetapkan oleh operasi STARTTLS.

Operasi STARTTLS menyediakan kemampuan untuk membangun TLS dalam sesi LDAP. Tujuan dari penggunaan protokol TLS pada LDAP adalah untuk memastikan kerahasiaan data dan integritas, selain itu untuk opsional menyediakan otentikasi. TLS menyediakan kemampuan tersebut, meskipun layanan otentikasi dari TLS hanya dapat dikombinasi dengan metode otentikasi EXTERNAL SASL, dan kemudian jika pelaksanaan SEXTERNAL SASL memilih untuk memanfaatkan kredensial TLS. Setiap sesi pada LDAP memiliki Authorization State atau otoritas State. State disini terbagi dari beberapa faktor, seperti otentikasi apa yang telah didirikan, bagaimana cara mendirikan ,dan layanan keamanan apa yang dipakai. Beberapa faktor dapat ditentukan atau dipengaruhi oleh protokol ( misalnya adalah Bind, STARTTLS) dan terdapat beberapa faktor yang dapat ditentukan oleh peristiwa eksternal ( misalnya, waktu, hari, atau beban server). Operasi Bind seperti yang telah dijelaskan pada RFC 4511 memungkinkan untuk mengotentikasi pesan yang ditukar antara klien dengan server. Permintaan Bind biasanya menentukan otentikasi identitas yang diinginkan. Beberapa mekanisme Bind juga memungkinkan Klien untuk menentukan otoritasi dari identitas. Jika otorisasi identitas di tentukan, maka server harus memverifikasi otentikasi identitas dari klien. Sebaliknya, jika otorisasi identitas tidak di tentukan, maka server akan mengotentikasi identitas secara khusus. Metode otentikasi sederhana dari operasi Bind menyediakan tiga mekanisme otentikasi, mekanisme tersebut adalah (1) Sebuah mekanisme otentikasi anonim (2) Sebuah mekanisme otentikasi yang tidak berkepentingan, dan yang terakhir adalah (3) Sebuah mekanisme otentikasi nama / sandi yang menggunakan kredensial yang terdiri dari nama dan password. Pada dokumen RFC selanjutnya akan membahas tentang representasi Stirng dengan Distinguished Name yang digunakan pada LDAP. Pada dokumen RFC 4514 ini tidak membahas tentang representasi String kanonik untuk DNS. Tujuan utama dari adanya DN ini adalah untuk kemudahan encoding dan

decoding, sementara itu tujuan sekundernya adalah agar dapat memiliki nama yang dapat dimengerti oleh manusia. Konversi DistinguishedName dari ASN.1 ke String mempunyai beberapa macam, diantaranya adalah : (1) Konversi RDNSequence, (2) Konversi RelativeDistinguishedName, (3) Konversi AttributeTypeandValue, dan (4) Konversi suatu AtributeValue dari ASN.1 ke String. Selain konversi dari DistinguishedName ke String dokumen ini juga membahas tentang kebalikan dari konversi tersebut. Pada dokumen RFC 4515 dibahas tentang representasi String dari filter perncarian (Search). Pada dokumen ini LDAP mendefinisikan jaringan representasi dari filter pencarian dan ditransmisikan ke LDAP server. Pada filter pencarian LDAP terdapat AttributeDescription, yang merupakan sebuah representasi string dari deskripsi atribut. Filter ini dikodekan melalui jaringan dengan menggunakan Basic Encoding Rules (BER). Sementara itu representasi string dari filter pencarian pada LDAP merupakan string UTF-8 yaitu, karakter UNICODE yang di kodekan mengikuti notasi ABNF. Pada konfigurasi string pada filter pencarian terdapat aturan valueencoding, aturan ini memastikan bahwa string merupakan saringan seluruh UTF-8 yang valid dan merupakan oktet yang mewakili ASCII. Sebagai contoh yaitu filter yang harus diterapkan untuk atribut apapun mendukung aturan pencocokan yang diberikan, hal ini dikarenakan <attr> telah dihilangkan. Selain itu terdapat contoh lainnya filter yang harus diterapkan untuk setiap atribut yang cocok akan diberikan atribut yang mendukung aturan pencocokan. Masalah pertimbangan keamanan untuk menggambarkan representasi string dari filter pencarian pada LDAP, yaitu representasi itu sendiri tidak diketahui implikasi keamanannya pada saat filter pencarian pada LDAP

dijalankan. Representasi tersebut ditafsirkan oleh server LDAP untuk memilih

entri dari data yang telah diambil. Maka dari itu LDAP server harus berhati hati untuk melindungi data mereka dari akses yang tidak sah. Pada dokumen RFC selanjutnya yaitu RFC 4516. Pada dokumen ini akan membahas tentang lokasi resource yang sama. Dokumen ini menentukan format URL LDAP untuk versi 3 dari LDAP dan menjelaskan bagaimana LDAP URL diselesaikan. Mekanisme ini dapat digunakan untuk menyediakan akses ke ekstensi LDAP yang baru. URL disini dapat digunakan untuk mewakili referensi pengetahuan, termasuk pencarian non-operasi. LDAP URL dimuali dengan awalan protokol ldap dan mengikuti notasi ABNF. Awalan ldap mengindikasi sebuah entri yang diakses dari LDAP server yang berjalan pada nama host yang diberikan nomor port. DN pada LDAP menggunakan format string, hal ini mengindikasi pencarian obyek dasar LDAP atau target dari pencarian non-operasi. Beberapa bidang URL LDAP adalah opsional. Jika nilai default tidak ada, maka maka URL LDAP harus digunakan ketika fieldnya tidak ada. Jika host tidak diberikan, klien harus memiliki beberapa dasar pengetahuan tentang server LDAP yang tepat untuk dapat dihubungi. Port default untuk LDAP adalah port TCP 389. Apabila nilai DN tidak diberikan, maka default DN adalah zero-length DN. Selain itu jika bagian dari atribut dihilangkan, maka pengguna dari seluruh atribut dari entri harus diminta, dengan menetapkan AttributeDescriptionList dan mengisi field atributnya dalam pencarian LDAP dengan nilai NULL. Jika nilai scope dihilangkan, maka sebuah scope akan diasumsikan dari base. Namun jika filter dihilangkan, maka akan mengasumsikan sebuah filter (objectclass=*). Selanjutnya jika extensions dihilangkan, maka tidak akan ada ekstensi yang akan diasumsikan. Penggunaan mekanisme keamanan saat memproses URL LDAP membutuhkan perhatian khusus, hal ini dikarenakan klien mungkin akan mengalami banyak server yang berbeda melalui URL. Selain itu, karena URL kemungkinan akan diproses secara otomatis, tanpa intervensi pengguna. Beberapa

mekanisme otentikasi, khususnya, password yang dapat digunakan kembali dapat dikirim ke server. Hal ini dapat mengungkapkan informasi ke remote server dengan mudah disalahgunakan atau menyadap dalam perjalanan dan tidak digunakan dalam pengolahan URL kecuali diizinkan oleh kebijakan tersebut. Selanjutnya adalah dokumen RFC 4517 yang akan membahas tentang sintaks dan peraturan pencocokan. Setiap atribut yang disimpan dalam direktori LDAP, memiliki nilai nilai yang dapat ditransfer dalam protokol LDAP, dan memiliki sintaks yang didefinisikan dan yang membatasi struktur dan format nilai nilainya. Perbandingan semantik untuk nilai sintaks bukan merupakan bagian dari definisi dari sintaks, melainkan akan didefinikan secara terpisah oleh pengaturan pencocokan. Aturan pencocokan disini akan menentukan argumen, dan juga nilai dari pernyataan atau argumen. Dokumen ini mendefinisikan dasar dari set sintaks dan aturan yang cocok untuk digunakan dalam mendifinisikan atribut pada direktori LDAP. Definisi sintaks membatasi struktur nilai atribut disimpan dalam direktori LDAP dan menentukan representasi dari atribut dan nilai-nilai pernyataan ditransfer dalam protokol LDAP. Server harus mengenali semua sintaks yang tercantum dalam dokumen ini, namun server tidak diharuskan untuk mengenali sintaks jika sintaks tersebut tidak suport terhadap server tersebut. Implementasi dari klien dan server biasanya tidak memiliki kemampuan secara dinamis untuk mengenali sintaks sintaks baru. Deskripsi dari setiap sintaks menentukan bagaimana nilai nilai dari atribut atau argumen sesuai dengan sintaks tersebut, namun harus diwakili saat akan ditransfer kedalam protokol LDAP. Representasi ini disebut sebagai pengkodean LDAP-khusus, hal ini dilakukan untuk membedakannya dari nilai atribut dari metode encoding lainnya. Pengkodean LDAP-spesifik dari sebuah atribut sintaks yang diberikan akan selalu menghasilkan nilai nilai blok-oktet. Setiap nilai sintaks LDAP adalah unik dan selalu diidentifikasikan sengan sebuah obyek identifier, dan diwakili dalam format desimal.Pengidentifikasi obyek ini tidak dimaksudkan untuk ditampilkan kepada pengguna. Sebuah sintaks

mempunyai batas minimum yang disarankan terikat pada jumlah karakter dalam suatu nilai atribut dengan sebuah sintaks berbasis string. Nilai sintaks Deskripsi Tipe Atribut adalah definisi dari jenis atribut. Nilai sintaks pada pengkodean LDAP-spesifik Sebagai ini didefinisikan oleh jika terdapat aturan sintaks

<AttributeTypeDescription>.

contoh

createTimestamp, maka createTimestamp tersebut merupakan tipe atribut dan juga merupakan nilai dari sintaks Deskripsi Tipe Atribut. Nilai sintaks dari Bit String adalah urutan digit biner. Sedangkan nilai dari sintaks Boolean adalah salah satu dari nilai Boolean, yang merupakan true atau false. Nilai sintaks State String adalah salah satu dari dua kode karakter dari ISO 3166 untuk mewakili setiap state. Nilai sintaks pada metode pengiriman adalah urutan item yang menunjukan urutan preferensi, dengan layanan dimana suatu entitas bersedia atau mampu menerima pesan. Nilai dari sintaks Direktori String adalah sebuah string dari satu atau lebih karakter dari Universal Character Set (UCS). Sebuah nilai zero-length tidak diizinkan untuk digunakan. RFC 4519 membahas tentang skema untuk aplikasi pengguna. Pada dokumen RFC ini membahs jenis atribut yang digunakan dan juga membahas tentang macam macam kelas obyek yang digunakan oleh klien direktori LDAP untuk berbagai macam servis direktori. Tipe atribut yang terkandung dalam bagian ini menyimpan informasi pengguna. Tidak ada persyaratn bahwa server harus menggunakan tipe atribut searchGuide dan TeletexTerminalIdentifier. Sebuah implementasi dari LDAP server harus dapat mengenali sisa tipe atribut yang diuraikan dalam bagian ini. Berikut adalah beberapa tipe atribut yang dipakai (1) BussinessCategory, (2) C, (3) Cn, (4) Dc, (5) Description, (6) DestinationIndicator, (7) DistinguishedName, dll. Sebuah LDAP server harus mengenali semua kelas obyek sebagai nilai nilai atribut dari objectclass. Macam macam kelas obyek yang digunakan adalah (1) ApplicationProcess, (2) DcObject, (3) GroupOfName, (4)

GroupOfUniqeName, (5) Organization, (6) Location, dll.

Dari beberapa dokumen RFC diatas dapat ditentukan beberapa komponen pembentuk dari LDAP. Komponen komponen tersebut adalah (1) Operasi Protokol, operasi protokol ini dapat berupa operasi Bind, Extended Operation, dan juga operasi modifikasi. (2) Selain itu Model Direktori Informasi, yang termasuk dari model direktori informasi adalah hirarki yang digunakan direktori LDAP yaitu , hirarki pohon yang mempunyai subentries, subtree, objectclass, dan juga objek operasional. Selain itu dalam model direktori informasi ini juga terdapat Relative Distinguished Name (RDN) dan Distinguished Name. (3) Komponen selanjutnya adalah Mekanisme Keamanan dan Otoritas, dalam mekanisme ini LDAP menggunakan metode nama / password yang nantinya akan dikenali oleh server saat akan bertukar data.