BAB 2
LANDAS AN TEORI
2.1 Internet
2.1.1 Pengertian
M enurut Engst et al (1995), internet dapat didefinisikan sebagai sebuah kumpulan yang sangat besar dari manusia, mesin, program software, dan data, yang tersebar disekeliling dunia dan terus-menerus berhubungan.
M enurut Turban et al (2005, pp478), internet didefinisikan sebagai sebuah jaringan yang menghubungkan kurang lebih satu juta organisasi internasional jaringan komputer di dalam lebih dari 200 negara pada semua benua, termasuk Antartika.
Secara lebih sederhana pengertian internet berdasarkan kedua pengertian di atas dapat disederhanakan menjadi, internet adalah sebuah kumpulan jaringan yang terdiri dari banyak manusia, mesin, program software, dan data, yang memiliki jumlah sangat besar, tersebar di seluruh dunia, dan terus-menerus berhubungan.
2.1.2 Sejarah Internet
M enurut Turban et al (2005, pp478), sejarah internet dimulai ketika sebuah proyek dari Advanced Research Project Agentcy (ARPA), yang merupakan departemen pertahanan Amerika Serikat. Proyek ini dimulai pada tahun 1969, dan dinamakan ARPAnet. Ini digunakan untuk mengetes kemungkinan dari wide area computer network melewati bagian researcher, educator, military, dan government agency dapat melakukan share data, melakukan pertukaran pesan, dan mengirimkan file. Proyek ini
terus berkembang dan pada tahun 1993 ketika organisasi komersial bergabung dengan ARPAnet, proyek ini diganti menjadi Internet, yang sekarang telah memiliki lebih dari 500 juta pengguna.
2.2 World Wide Web (WWW)
2.2.1 Pengertian
M enurut Engst et al (1995), mengatakan bahwa WWW atau lebih dikenal dengan Web memberikan keistimewaan yang sangat penting untuk internet. Web menyediakan akses untuk huruf, ukuran, dan tipe dari teks, dan juga dapat dimasukkan gambar pada tampilan dengan perlakuan yang biasa. Suara dan film juga mungkin dimasukkan. Web juga menyediakan hypertext, yang menghubungkan dokumen manapun di dalam Web, tidak hanya pada satu mesin. Hypertext merupakan sebuah konsep yang kuat yang mengijinkan pembaca untuk mengendalikan fleksibilitas lewat sebagaian link dari informasi.
M enurut Turban et al (2005, pp482), menjelaskan bahwa WWW tidak serupa dengan Internet. Fungsi Internet adalah sebagai mekanisme transport. Sedangkan WWW adalah sebuah aplikasi yang menggunakan fungsi transport itu. Aplikasi lain juga dapat berjalan dalam Internet. Web merupakan sebuah sistem dengan standar universal yang dapat diterima untuk penyimpanan, pengambilan, pembuatan/pembentukan, dan menampilkan informasi lewat arsitektur client/server. Web menangani semua tipe informasi digital, termasuk teks, hypermedia, grafik, dan suara. Web menggunakan user interface berupa grafik. Web yang berdasarkan standar bahasa hypertext dinamakan Hypertext Markup Language (HTML), dimana format dokumen dan penggabungan link
hypertext yang dinamik untuk dokumen lain disimpan pada komputer yang sama atau berbeda.
2.2.2 Web Portal
Web portal merupakan sebuah teknologi yang akan berkembang pada teknologi web di masa depan. Satu halaman portal terdiri dari berbagai macam portlets yang dapat mengirimkan informasi dari banyak sumber (Braun et al, 2004). Selain informasi web portal juga dapat menggabungkan berbagai aplikasi web menjadi satu kesatuan, sebagai contoh adalah sharing content, digital cinema, e-learning, dll (M annaert et al, 2003).
2.3 Lightweight Data Access Protokol (LDAP)
2.3.1 Pengertian LDAP
M enurut Carter (2003), pengertian LDAP dibagi menjadi 3 bagian, yaitu: • Lightweight
• Directory • Access Protocol
2.3.1.1 Lightweight
LDAP dikatakan ringan jika dibandingkan dengan X.500 servis direktori (Carter, 2003). Hal ini dikarenakan pada mulanya root LDAP sangat dekat terkait dengan X.500. LDAP pada mulanya dibuat sebagai protokol desktop yang lebih muda
yang digunakan sebagai gateway untuk X.500 server. X.500 merupakan sebuah standard. X.500 mendapatkan gelar Heavyweight karena membutuhkan client dan server untuk berkomunikasi menggunakan Open System Interface (OSI) protokol. Tujuh layer OSI ini bagus dalam mengaplikasikan jaringan protocol suite, tetapi ketika dibandingkan dengan TCP/IP protocol suite, ini serupa dengan bepergian jauh dengan dengan barang bawaan yang sangat berat.
Dengan demikian LDAP dikatakan ringan (“lightweight”) karena menggunakan pesan sedikit diatas udara yang dipetakan secara langsung pada TCP layer (biasanya port 389) dari TCP/IP protokol (Carter, 2003). Karena X.500 merupakan layer aplikasi protokol (dalam OSI layer) maka ini akan membawa lebih banyak bawaan, seperti network header yang dipasang pada paket pada setiap layer sebelum akhirnya dikirimkan ke jaringan.
LDAP juga dikatakan ringan (“lightweight”), karena menghilangkan banyak operasi X.500 yang jarang digunakan (Carter, 2003). LDAPv3 hanya memiliki sembilan operasi utama dan menyediakan model sederhana untuk programmer dan administrator. M enyediakan satu set operasi yang lebih kecil dan sederhana yang mengijinkan pengembang untuk fokus pada seluk-beluk dari program tanpa harus mengerti keunggulan dari protokol yang jarang digunakan. Dengan jalan ini pembuat LDAP berharap untuk meningkatkan penggunaan dengan menyediakan pengembangan aplikasi yang lebih mudah.
2.3.1.2 Directory
Jaringan servis direktori bukanlah suatu hal yang baru, khususnya untuk Domain Name System (DNS) (Carter, 2003). Bagaimanapun servis direktori sering dibingungkan dengan database. Perlu diingat bahwa servis direktori dan database memiliki karakteristik masing-masing, seperti pencarian cepat dan schema yang dapat diperluas. Perbedaannya adalah direktori dibuat untuk dibaca lebih banyak dari pada ditulis. Sedangkan untuk database diasumsikan untuk operasi baca dan tulis memiliki frekuensi yang sama. Asumsi bahwa direktori dibaca lebih sering dari pada ditulis merupakan suatu keunggulan yang spesifik untuk sebuah database, seperti dukungan untuk transaksi dan menulis lock merupakan sesuatu hal yang tidak penting untuk servis direktori seperti LDAP.
Pada titik ini penting untuk membedakan antara LDAP dengan backend yang digunakan untuk menyimpan data. Ingat bahwa LDAP hanya sebuah protokol, yang penting adalah LDAP adalah sebuah set dari pesan yang digunakan untuk mengakses data yang spesifik. Protokol ini tidak mengatakan apapun tentang dimana data disimpan.
Pada intinya adalah bahwa client tidak akan (dan tidak akan pernah) melihat atau bahkan tahu tentang mekanisme penyimpanan backend (Carter, 2003).
Gambar 2.1 hubungan antara LDAP client, server, dan data storage
Seperti sudah disarankan bahwa LDAP server dapat digunakan sebagai backend storage untuk web server. Semua HTM L dan file grafik dapat disimpan dalam direktori dan dapat dipertanyakan (query) oleh banyak web server. Disamping semuanya, sebuah web server biasanya hanya membaca file dan mengirimkannya ke client, file itu sendiri tidak akan sering diubah. Ketika ini mungkin untuk mengimplementasikan web server yang menggunakan LDAP untuk mengakses backend storage, ada sebuah tipe spesial dari direktori yang telah ada, dan ini merupakan suite yang lebih baik untuk memenuhi kebutuhan melayani file, namanya adalah filesystem.
Dengan demikian ada dua inti penting yang dapat diambil tentang maksud fungsi dari LDAP (Carter, 2003) :
1. LDAP tidak secara umum menggantikan special direktori seperti halnya filesystem atau DNS.
2. Ketika menyimpan suatu tipe spesifik dari informasi binary (misal : jpeg foto) dalam direktori dapat digunakan, LDAP tidak dimaksudkan untuk menyimpan tipe tertentu seperti “blobs” (Binary Lumps of Bits).
2.3.1.3 Access Protocol
Penjelasan berikut akan cukup untuk membuat berpikir bahwa LDAP merupakan message-based, client/server protokol yang didefinisikan dalam RFC 2251. LDAP itu asynchronous (meskipun banyak peralatan development menyediakan baik blocking dan nonblocking API), ini berarti bahwa sebuah client dapat menimbulkan banyaknya permintaan dan response-nya mungkin datang dalam urutan yang berbeda ketika permintaan itu dimunculkan (Carter, 2003).
2.3.2 Model LDAP
M odel LDAP mewakili servis yang disediakan oleh server, seperti yang dilihat oleh client. M odel ini merupakan model abstrak yang menjelaskan tentang berbagai macam aspek dari direktori LDAP (Carter, 2003). RFC 2251 membagi direktori LDAP menjadi dua komponen, yaitu protokol model dan data model. Ada empat model yang didefinisikan oleh Timothy A. Howes, dkk (Howes et al, 2003):
• Information Model
M odel informasi menyediakan struktur dan tipe data yang diperlukan untuk membangun sebuah pohon direktori LDAP. Inputannya adalah unit dasar dari sebuah direktori LDAP. Bentuk visualnya dapat dilihat sebagai node interior atau node exterior dalam Directory Information Tree (DIT). Sebuah inputan terdiri dari informasi tentang misalnya satu atau lebih objectClasses. ObjectClasses ini memiliki kebutuhan yang spesifik atau atribut pilihan. Tipe atribut harus dibuat encoding dan aturan pencocokannya yang menentukan sesuatu sebagai tipe dari data atribut dapat ditahan dan bagaimana membandingkan data ini selama melakukan pencarian.
• Naming Model
Model naming menentukan bagaimana entry dan data dalam DIT memiliki alamat yang unik. Setiap entry memiliki sebuah atribut yang unik diantara semua atribut yang lain. Keunikan atribut ini dinamakan Relative Distinguished Name (RDN). Keunikan suatu atribut dapat dicari dengan mengenali entry dalam sebuah direktori dengan mengikuti RDN dari semua entry dalam jalur dari node yang diinginkan sampai root dari tree. String ini dibuat dengan
mengkombinasikan RDN ke dalam bentuk nama yang unik yang disebut node Distinguished Name (DN).
Gambar 2.3 Contoh tree direktori LDAP
Garis besar entry direktori pada gambar diatas mempunyai sebuah RDN yaitu cn=gerald carter. Sebagai catatan bahwa nama atribut akan sama dengan nilai yang dimasukkan dalam RDN. DN untuk node ini akan menjadi cn=gerald carter, ou=people, dc=plainjoe, dc=org.
• Fungsional Model
M odel fungsional adalah protokol LDAP itu sendiri. Protokol ini menyediakan tujuan untuk mengakses data dalam tree direktori. Akses diimplementasikan dengan operasi autentikasi (binding), operasi query (search dan read), dan operasi update (write).
• Security Model
M odel security menyediakan sebuah mekanisme untuk client yang digunakan untuk membuktikan identitas (authentication) dan untuk server adalah sebagai
pengatur client yang terautentifikasi dalam mengakses data (authorization). LDAPv3 menyediakan beberapa metode autentifikasi yang tidak didapatkan dalam protokol versi sebelumnya. Beberapa keunggulan, seperti access control list, belum mendapat standarisasi, sehinggal membiarkan vendor dengan perlengkapan mereka sendiri.
Pada level tingkat tinggi ini, LDAP termasuk kategori sederhana. LDAP adalah sebuah protokol untuk membangun pembagian direktori tingkat tinggi.
2.3.3 Ruang lingkup LDAP
Pada bagian diatas telah dijelaskan tentang apa itu LDAP, serta pengertian dari LDAP itu sendiri. Pada bagian ini akan dijelaskan tentang beberapa area yang dapat digunakan untuk menyimpulkan apa itu LDAP dan seperti apa LDAP itu. M enurut Arkills (2003), ada sebuah contoh yang dapat digunakan untuk memahami konteks nyata untuk konsep yang abstrak. Mycompany.com merupakan sebuah tipe perusahaan, yang berpengalaman tentang syarat teknik untuk mengangkat bisnisnya.
Gambar 2.4 Integrasi dari aplikasi dan infrastruktur Mycompany.com dengan menggunakan LDAP
Perusahaan Mycompany akan menggunakan LDAP direktori untuk mengikat semua aplikasi dan servis yang ada menjadi satu, menjadi data manajemen yang lebih sederhana, memotong biaya pengembangan dan support, dan menyediakan sebuah manajemen infrastruktur teknologi informasi. Pada gambar 2.4, digambarkan bagaimana setiap aplikasi, database, dan servis akan berinteraksi dengan data di dalam direktori LDAP. Arah keluar dari direktori menunjukkan operasi search (query) yang merupakan sumber informasi untuk servis atau aplikasi. Arah ke dalam direktori menunjukkan
sumber dari data direktori atau data direktori yang telah ada yang memiliki kemungkinan untuk diubah.
Ada empat ruang lingkup yang dapat digunakan untuk menjelaskan tentang LDAP (Arkills, 2003), yaitu:
• Namespace • Client operation • Schema
• Management
2.3.3.1 LDAP Namespace
”Namespace” menyatakan secara tidak langsung bahwa sebuah nama adalah tidak sesederhana sebuah nama, tetapi mengandung arti dalam hubungannya dengan struktur yang ada. Hubungan ini mengandung dua aspek yang berbeda dari direktori dan mencari bagaimana mengikatnya menjadi satu, atau dengan kata lain bagaimana memberi nama sesuatu dan bagaimana mengaturnya. Definisi dari servis namespace adalah sangan kritis. Ini mungkin sangat jelas, tetapi sebuah namespace mengijinkan untuk menemukan sesuatu. Namespace adalah suatu set dari kumpulan yang digunakan untuk mengenali semua objek dalam sebuah lingkungan yang diberikan. Dengan kata lain ini merupakan sistem penamaan. Tanpa sebuah namespace yang disetujui bersama, mungkin yang terjadi adalah mengarah pada suatu objek yang sama tetapi menggunakan bahasa yang berbeda. Sebuah namespace yang bagus juga memberi keyakinan bahwa nama satu objek tidak akan konflik dengan objek yang lainnya (Arkills, 2003).
Sebuah namespace lebih banyak mengandung informasi dibandingkan dengan pengenalan secara cepat. Sebuah analogi yang dapat digunakan sebagai contoh dalam dunia nyata adalah sistem pengalamatan pada kartu pos. Dalam kartu pos akan terdapat informasi seperti (Arkills, 2003):
• Nama orang • Nama jalan
• Kota dan kodepos • Negara
Alamat ini memberitahukan tentang banyak hal mengenai cara bagaimana struktur ini dibentuk dan nilai dari setiap komponennya, juga membentuk penerima secara unik. Langkahnya dimulai dari nama negara, lalu nama kota dan kodepos, kemudian nama jalan, dan akhirnya nama penerima. Dari hal ini dapat diketahui bahwa penerimanya merupakan unik, atau dapat dikatakan berbeda dari nama yang sama tapi berada pada alamat yang berbeda.
Dengan menggunakan tingkatan namespace maka akan dapat dikirimkan informasi manajemen. Tetapi berdasarkan keterangan lain yang diilustrasikan dengan kartupos, karena namespace diatur dalam bentuk tingkatan akan mengurangi jangkauan yang dibuat secara jelas. M anajemen termasuk dalam objek dapat dikirimkan, dengan kata lain sebelum pembaca menyampaikan surat pada tujuannya, pertama kali yang dilakukan adalah mengirimkannya ke kantor pos yang bertanggung jawab untuk negara yang tertera di surat. Setelah itu baru dikirimkan pada kantor pos setempat, dan seterusnya sampai surat itu sampai pada penerima. Tingkatan yang melekat pada
namespace secara baik menyediakan keefektifan dalam kerjasama pengiriman dari manajemen.
Penggunaan namespace juga dapat mengarah pada implementasi khusus dari direktori. Ketika kata namespace digunakan dalam konteks dari namespace direktori khusus, sedikit perbedaan arti terdapat di dalamnya. Dalam konteks ini bukan merupakan sistem penamaan yang dibutuhkan. Dalam konteks ini namespace ditujukan untuk semua objek dalam direktori dan struktur spesifik yang dipilih. Dengan LDAP, kelihatannya ada dua nama untuk setiap istilah direktori. Kata ini adalah Directory Information Tree (DIT) yang digunakan untuk menunjuk pada namespace direktori yang khusus (Arkills, 2003).
2.3.3.1.1 DNS
Nama DNS server merupakan dasar untuk nama root dari LDAP direktori (Arkills, 2003). Domain Name System (DNS) membentuk suatu bagian dari dasar untuk namespace LDAP, dan ini juga merupakan contoh yang baik untuk sebuah namespace. M engeksplorasi bagaimana DNS bekerja akan menolong dalam menemukan garis besar tentang LDAP. Nama DNS dari direktori LDAP server dapat menjadi bagian paling penting dalam menentukan nama dari direktori root, dimana merupakan direktori berbasiskan DN. M eskipun DNS digunakan dalam penamaan mempengaruhi dari implementasi namespace LDAP. Sebuah direktori berbasiskan DN tidak harus sama dengan nama DNS dari direktori server, dan keduanya biasanya tidak cocok ketika sebuah direktori disebarkan menyeberangi banyak server yang diinginkan. Disamping dari koneksi ini pada namespace, DNS juga dapat menjalankan sebuah aturan kritis
dalam proses LDAP client menemukan lokasi LDAP direktori server. DNS tidak harus digunakan dalam lokasi server, tetapi seringkali digunakan.
DNS memetakan nama manusia pada nama komputer. DNS adalah sebuah penyebaran direktori servis yang dikelola oleh ribuan server diseluruh dunia. Ada milyaran dokumen dalam direktori ini, dimana peta dan alamat IP pada satu nama komputer dan sebaliknya. Alamat IP adalah angka yang merupakan nama dimana satu komputer digunakan untuk menghubungi komputer yang lain. Orang mengetahui komputer melalui nama yang terdiri dari gabungan angka dan huruf (alphanumeric). Sebuah contoh adalah host.mycompany.com dalam 127.42.12.6. dokumen ini menunjukkan bahwa host.mycompany.com adalah nama manusia dari komputer yang memiliki alamat IP 127.42.12.6.
Sebuah urutan tingkatan DNS dipekerjakan untuk menyediakan dasar yang bersih untuk pemecahan nama yang berwenang. Dokumen ini disebarkan melewati jutaan file yang disebut zones. Setiap zone menampung sebuah copy dari dokumen untuk namespace DNS untuk jika ini berwenang. Dengan kata lain, setiap zone mengijinkan perubahan pada hanya sebagian kecil dari seluruh namespace DNS. Dokumen komputer host.mycompany.com milik dari zone mycompany. Mycompany zone milik dari zone com. Dan zone com milik dari zone root. Zone root merupakan zone teratas dari semua DNS. File zone disimpan dalam DNS server yang berwenang untuk zone itu. Setiap zone parent adalah yang berwenang dalam membedakan DNS server mana yang berwenang untuk setiap zone child. Zone root memegang dokumen wewenang untuk setiap zone DNS pada level satu. Ini berbentuk sebuah urutan tingkatan, dimana komputer client dapat melakukan query dengan jaminan yang masuk akal untuk mendapatkan wewenang resolusi nama (Arkills, 2003).
Gambar 2.5 Tingkatan dari Zone DNS
Urutan tingkatan dalam resolusi DNS menyediakan sebuah jalan yang tepat guna bagi komputer client untuk melakukan resolusi nama. Namespace DNS menyediakan sebuah sistem yang baik untuk mengatur dokumen nama komputer dan untuk memecahkan lokasi dari nama komputer. Komputer client biasanya diarahkan untuk melakukan query wewenang DNS server dari zona lokal untuk resolusi nama. Sebagai contoh, komputer host.mycompany.com akan diubah untuk melakukan query DNS server untuk mycompany.com. Seharusnya host.mycompany.com ingin tahu alamat IP untuk unknown.whitehouse.gov, ini pertama kali akan bertanya pada DNS server di mycompany.com. mycompany.com akan menunjuk pada DNS server com. DNS server com akan mengarah pada DNS server root. DNS server root akan mengarah pada DNS server gov. DNS server gov akan mengarah pada DNS server whitehouse.gov. DNS server whitehouse.gov kemudian akan menjawab client dengan mengirimkan alamat IP dari unknown.whitehouse.gov. Biasanya DNS server menyembunyikan informasi
tentang zone penting seperti root dan DNS server level satu, sehingga pada kenyataannya proses penggambarannya akan mengikuti banyak jalur yang lebih pendek .
Ada beberapa tipe dasar dari DNS. Untuk penjelasannya dapat dilihat pada tabel dibawah ini (Arkills, 2003).
Tabel 2.1 Tipe Dasar Dokumen DNS
DNS digunakan untuk mendaftarkan sebuah direktori servis. Satu maksud penting dari LDAP menggunakan namespace DNS adalah dengan mendaftarkan sebuah nama domain DNS untuk menghubungkan sebuah host atau zone, secara tidak sengaja juga mendaftar untuk sebuah namespace direktori servis. Ada persamaan dalam namespace pengiriman email dengan dokumen M X dan banyak servis berbasiskan jaringan lainnya. Ketika mendaftar sebuah dokumen untuk mycompany.com dengan sebuah wewenang dari DNS server, mycompany.com mungkin menjadi sebuah namespace direktori servis yang aktif (Arkills, 2003).
LDAP membuat peningkatan penggunaan DNS khususnya untuk fungsi namespace-nya. Ada berbagai anggapan tentang hubungan DNS dengan LDAP, RFC 2247 menyediakan standar yang jelas bagi DNS untuk digabungkan secara mudah ke dalam namespace yang digunakan LDAP dalam direktori. Atribut dari domain component (dc) sudah ditetapkan, dan ini dapat digunakan sebagai nama atribut dalam direktori sebagai wadah objek (Arkills, 2003).
2.3.3.1.2 LDAP Object S tructure
Struktur internal dalam sebuah direktori LDAP menyediakan aturan untuk entry dengan sebuah urutan tingkatan. Sebuah struktur sangat penting untuk digunakan dan diatur dalam sebuah direktori. Struktur juga mengijinkan keuntungan yang dimiliki namespace LDAP dapat disediakan dengan mudah (Arkills, 2003). Berikut merupakan keuntungan dari namespace LDAP (Arkills, 2003):
• Struktur dapat membuat lebih mudah untuk menyebarkan informasi melewati banyak server. Direktori disebarkan melewati banyak server dengan tujuan menyediakan ketahanan yang lebih besar dan kemungkinan penempatan informasi direktori dekat dengan lokasi remote.
• Struktur dapat membuat manajemen kontrol akses menjadi lebih sederhana. • Struktur dapat membuat aplikasi dengan kebutuhan direktori khusus untuk
disatukan dengan suatu direktori.
• Struktur dapat menyederhanakan perawatan direktori dengan menyatukan entry yang sama menjadi satu.
Struktur itu sendiri tidak menyediakan keuntungan ini. Bagi mycompany untuk merealisasikan keuntungan ini tergantung dari implementasi direktori dan rancangan dari namespace.
Sebuah urutan tingkatan adalah mungkin di dalam LDAP karena adanya container entry. Container entry adalah sebuah entry khusus yang mengijinkan entry lain untuk menempati tempat urutan dibawahnya. Entry yang berada di bawah container biasa disebut dengan child container atau subordinate entry dari container. Container terkadang disebut parent dari entry yang berada di bawahnya.
Hanya bentuk struktur yang khusus yang diijinkan dalam LDAP. Namespace dalam direktori LDAP mengijinkan hubungan yang berubah dalam sebuah struktur. Struktur sama juga dengan hubungan link dalam sebuah halaman web (struktur web) juga tidak diijinkan. Lebih khusus lagi, sebuah container hanaya diijinkan memiliki sebuah parent tunggal diatasnya. Tipe struktur seperti ini biasanya disebut dengan tree structure. Bagian ini mungkin mengingatkan tentang bagian pengganti untuk namespace: Directory Information Tree (DIT). Pada gambar di bawah ini (gambar 2.6 dan 2.8) merupakan contoh dari struktur namespace yang benar dan salah. Tujuan pengaturannya pada struktur adalah memudahkan masalah servis yang kecil ketika entry yang baru ditambahkan, karena hanya entry baru saja yang ditulis, dan tidak ada entry yang sudah ada yang diubah (Arkills, 2003).
Gambar 2.6 Contoh Tingkatan Namespace yang baik dalam LDAP
Gambar 2.7 Contoh Tingkatan Namespace yang tidak baik dalam LDAP
Dengan LDAP beberapa entry dapat menjadi sebuah container. Sebuah entry menjadi container ketika beberapa entry diletakkan dibawahnya, tetapi direktori LDAP
tidak melakukan perubahan dalam container entry ketika ini terjadi. Dalam LDAP, semua entry memegang kemungkinan untuk menjadi sebuah container, dan rancangan ini mendukung banyak kemungkinan urutan tingkatan.
M embuat sebuah container dengan membuat sebuah entry di bawah entry yang lain. Konsep ini pernah beberapa kali digunakan, sebagai masukan logika bahwa container entry butuh untuk diubah. Bagaimanapun implementasi khusus dari LDAP mungkin melewati spesifikasi LDAP dan mempunyai atribut khusus untuk informasi child supaya terjadi penambahan fungsi dari manajemen.
Dalam implementasi beberapa server LDAP, mungkin akan terjadi pembatasan dimana object class sebuah entry harus menjadi sebuah container. Pembatasan ini sering disebut structure rule. Secara umum ada beberapa object class yang biasa digunakan sebagai container untuk alasan sejarah. Object class ini biasa digunakan karena merupakan container yang diijinkan dalam X.500 (Arkills, 2003).
Selain object class ini, organization unit juga digunakan secara luas. Ini digunakan untuk berbagai macam tujuan yang lebih besar dibandingkan dengan struktur politik yang sederhana. Penggunaan object class ini tidak diharuskan sebagai container di dalam direktori.
Structure rule digunakan untuk membatasi ketika sebuah entry dari object class dapat dibuat. LDAP juga mendukung structure role khususnya untuk sebuah object class. Fungsi ini tidak semestinya menjadi bagian dalam LDAP standar, tapi ini diimplementasikan oleh beberapa vendor. Object class dari structure rule menentukan batasan dimana sebuah entry dari sebuah bagian object class boleh dibuat. Sebagai contoh, ini mungkin menghubungkan sebuah structure rule dengan organization unit dari sebuah object class. Structure rule ini mungkin membutuhkan semua entry dari objectclass=organizationUnit dijadikan anak dari entry objectclass=organization. Rule ini menentukan tambahan batasan dalam namespace, dan ini juga membatasi kegunaan. Structure rule dipaksakan oleh proses schema-checking (Arkills, 2003).
Naming context biasanya menunjuk pada bagian dari direktori. Nama dari setiap container level teratas mempunyai perbedaan yang biasa disebut naming context. Naming context lebih besar dari hanya sekedar container. Naming context adalah sebuah subtree yang berdekatan yang dimulai dengan container level teratas. Sebagai contoh, jika menunjuk pada sebuah objek naming context dalam mycompany, ini akan berarti container objek, semua dari entry child, dan semua container dan entry yang berada di bawah container objek, seperti ditunjukkan pada gambar 2.8. Dengan kata lain naming context sama dengan istilah directory suffix (context prefix dalam X.500). naming context objek adalah suffix objek (Arkills, 2003).
Gambar 2.8 Contoh naming context dalam direktori LDAP
Sesungguhnya tidak ada objek direktori pada root dari direktori LDAP. Sebagai pengganti, ada direktori khusus seperti objek root, dinamakan root DSE entry, yang mencatat semua naming context dalam server direktori. Direktori menggunakan naming context untuk secara cepat membedakan permintaan untuk sebuah entry ketika berada dalam naming context yang diketahui.
Di dalam direktori dengan struktur flat, susunan dan pengaturan biasanya diabaikan, ketika menambahkan entry baru akan secara mudah bertambah. Seperti pada gambar 2.9, kekurangan dari struktur mendorong perkembangan secara mudah karena hanya ada satu container organizational yang digunakan, dengan sedikit tidak ada masalah penempatan dalam penambahan. Tetapi dalam model ini, konsistensi dan skalabilitas dapat menjadi mimpi buruk. Skalabilitas menjadi sebuah masalah ketika query biasa mengembalikan entry yang sangat banyak. Skalabilitas juga dapat menjadi
masalah ketika jumlah dari nama unik yang digunakan sudah mencapai batas maksimum. Batas maksimum ini mungkin tercapai karena hanya satu entry dalam setiap bagian container dapat diberi nama dengan nama khusus. Ssebuah urutan tingkatan dapat mengesampingkan masalah ini dengan mengatur entry dalam banyak level pada urutan tingkatan (hierarchy).
Gambar 2.9 Namespace flat dalam direktori LDAP
Ada empat pembagian dasar dari namespace direktori yang berguna (Arkills, 2003):
• Political/functional – membagi informasi berdasar pada sebuah organisasi, atau membedakan dalam fungsi yang dibutuhkan. Sebagai contoh adalah pemisahan informasi direktori HR dari informasi direktori marketing.
• Geographic – membagi informasi berdasar pada lokasi dari client yang akan mengakses informasi atau berdasarkan lokasi dari objek nyata yang dinyatakan dari informasi dalam direktori. Sebagai contoh adalah pemisahan
informasi personal untuk individu di Eropa dengan informasi untuk masyarakat U.S.
• Resource-based – membagi informasi berdasar pada tipe dari resource. Sebagai contoh adalah pemisahan informasi printer dari informasi server, atau memisahkan resource public dengan resource private.
• User classification – membagi informasi berdasar pada kebutuhan user. Sebagai contoh adalah pemisahan informasi untuk manajer dari informasi untuk staff.
2.3.3.1.3 LDAP Object Naming
M enurut Arkills (2003), Relative Distinguish Name (RDN) adalah sebuah atribut nama entry. Atribut ini menyediakan penunjuk nama yang unik untuk setiap entry dalam sebuah container. Sebagai contoh , gambar 2.10 menunjukkan entry seseorang dengan RDN cn=Brian Arkills. Tidak mungkin dua entry dengan nilai RDN yang sama berada dalam container yang sama. Jadi tidak ada entry orang lain di dalam container people dengan cn=Brian Arkills, dan dalam container khusus manapun nilai atribut cn harus unik untuk entry orang yang berada di bawah pada container itu. Atribut RDN merupakan salah satu dari atribut entry, dikenal dengan nama naming atribute untuk tipe dari entry. Tetapi berbicara secara umum, naming atribut untuk object class tertentu tidak dipaksa untuk menjadi atribut khusus. Dalam definisi object class, beberapa vendor mengharuskan atribut khusus untuk menjadi naming atribute, tetapi ini bukan bagian dari LDAP standar. Pada contoh pada gambar 2.10 atribut cn merupakan naming atribute dari object class orang.
Gambar 2.10 Contoh RDN
RDN dapat dibentuk menggunakan beberapa tipe atribut pada entry yang memiliki nilai yang unik diantara entry yang lain dalam sebuah container. M eskipun aturan ini kelihatan membingungkan. Aturan ini memberikan user keleluasaan untuk mengenali sebuah entry dalam bentuk yang tidak terduga. Bicara secara umum, pengecekan schema harus memastikan bahwa setiap entry baru atau pengubahan terhadap entry yang telah ada meninggalkan entry paling tidak dengan sebuah RDN yang unik, sehingga entry tersebut memiliki nama yang unik. Beberapa implementasi dari LDAP melakukan standarisasi naming atribute untuk beberapa object class yang telah diberikan; dan dalam kasus, atribut yang ditunjuk sebagai naming atribute harus menemukan aturan unik yang schema checker paksakan. Salah satu jalan, ada jaminan untuk setiap entry memiliki nama yang unik melewati direktori (Arkills, 2003).
Tabel 2.3 Atribut umum yang digunakan sebagai Naming atribute
Penggunaan lebih dari satu atribut juga diijinkan dalam RDN. Ini dinamakan multivalued RDN. Fungsi ini mengijinkan user untuk merincikan sebuah entry yang unik dengan sebuah titik potong dari nilai dua atribut ketika nilai satu atau kedua atribut tidak menemui kebutuhan unik. Sebagai contoh, berdasar situasi yang digambarkan pada gambar 2.11. ada dua people dengan nomor telepon yang sama, dan dua people dengan nama keluarga yang sama. Dalam hal ini tidak bisa digunakan atribut baik nomor telepon maupun nama keluarga untuk menunjuk entry Luke Skywalker secara unik, tetapi gabungan kedua atribut akan mencitakan kombinasi yang unik RDN akan menjadi sn=Skywalker+telephoneNumber=+1 222 222 2222. Tentu saja, dalam kasus ini dapat lebih mudah menggunakan cn=Luke Skywalker sebagai RDN.
Gambar 2.11 Contoh multivalued RDN
Distinguish Name (DN) menyediakan nama yang berkualitas untuk setiap entry, sehingga sangat jelas jika sebuah entry dirujuk, dan juga dimana dalam struktur urutan tingkatan (hierarchy) sebuah entry ditempatkan. Di bawah perincian LDAP, setiap entry tidak menyimpan DN-nya, ataupun tidak dengan index direktori yang merupakan DN dari direktori entry. Sebagai penggantinya, DN terutama digunakan untuk user dari direktori untuk dapat menunjuk direktrori mana yang entry inginkan. Sebuah DN ditampilkan dengan operasi permintaan dari client, dan direktori kelihatan dinamis saat dilihat ketika sebuah entry sama dengan DN yang dikabarkan.
M embuat DN dapat menjadi sedikit sulit karena user harus tahu RDN dari semua container diatas entry. DN merupakan sebuah susunan string RDN dari entry berhubungan dengan container RDN dari entry berhubungan dengan setiap RDN dari setiap container diatas container tersebut. Dengan kata lain DN adalah susunan RDN
dari entry yang berhubungan dengan DN dari container itu sendiri. Seperti digambarkan pada gambar 2.11 entry bagian kanan mempunyai dua kemungkinan DN (Arkills, 2003):
cn=Luke Skywalker,ou=People,dc=mycompany,dc=com atau
sn=Skywalker+telephoneNumber=+1 222 222 2222,ou=People,dc=mycompany,dc=com
User harus mengolah beberapa karakter khusus ketika menggunakan sebuah DN. Karakter khusus ini dapat disimpan dalam bentuk nilai naming atribute tanpa karakter escape; tetapi ketika merujuk pada karakter ini dalam sebuah DN, user harus melepaskannya. User secara khusus menotasi karakter ini dengan menempatkan lebih dahulu sebuah karakter backslash (\) untuk menghindari kesalahan dalam pengartian. Ini sering kali disebut commenting atau escaping. Sebagai contoh, menandai sebuah DN dengan RDN yang memiliki sebuah koma dalam nilainya akan menyebabkan kebingungan karena direktori menggunakan koma di dalam DN untuk memisahkan komponen DN. Pengolahan karakter digambarkan dalam tabel 2.4 khususnya dalam pengubahannya dalam DN (Arkills, 2003).
Ketika menggunakan web browser sebagai client dari LDAP maka harus menggunakan sebuah format nama yang khusus. Kebanyakan web browser saat ini sudah mendukung fungsi client LDAP. Sebagai hasil fungsi search dapat digunakan dengan mudah melalui browser. Format nama dalam URL LDAP secara penuh dibicarakan dalam RFC 2255. format ini hampir tidak ada perubahan dibandingkan dengan client standar LDAP. URL mempunyai satu set karakter khusus yang harus dioperasikan dengan cara yang khusus seperti yang ditunjukkan dalam RFC 1738, dan menampung format yang berbeda. Format nama LDAP-URL tidak secara khusus digunakan oleh web browser; standar client LDAP juga harus dapat menggunakannya untuk mendukung acuannya.
Sebuah URL LDAP dimulai dengan penunjukan ldap://, diikuti dengan hostname dan port dari direktori server, kemudian base DN dan penunjuk lainnya, seperti scope, filter, dan atribut yang diinginkan. Sintaknya menjadi (Arkills, 2003):
ldap://[hostname][/dn[?[attributes][?[scope] [?[filter][?[extensions]]]]]
Komponen dari sintak adalah :
• Hostname – merincikan dari server LDAP dan port TCP/IP yang digunakan server LDAP. Ditandai dengan kurung besar, baik hostname maupun port adalah sebuah pilihan. Port standar yang digunakan adalah 389 ketika port tidak dirincikan. Ketika hostname tidak dirincikan, client pasti memiliki pengetahuan sebelumnya server mana yang dihubungi. Pemisahan hostname dengan port adalah dengan titik dua, mycompany.com:389, seperti dirincikan dalam RFC 1738.
• DN – komponen DN merincikan base perbedaan nama untuk operasi search. • Attributes – komponen atribut merincikan tipe atribut yang dikembalikan dari
entry yang sama dengan parameter search. Jika tersisa yang tidak diketahui maka semua atribut dikembalikan.
• Scope – komponen scope merincikan batasan entry direktori yang dikembalikan. Sama dengan tipe search LDAP, base, one, dan sub adalah nilai yang mungkin dipakai. Jika nilai tidak dirincikan maka diasumsikan menggunakan sub.
• Filter – komponen filter merincikan batasan filter untuk entry mana yang harus dikembalikan. Ini menggunakan sintaks yang sama dengan tipe search LDAP. Jika tidak dirincikan, maka diasumsikan menggunakan (objectclass=*), sehingga semua entry dikembalikan.
• Extension – komponen extension merincikan pilihan extension dari URL LDAP. Extension ini dapat didefinisikan ketika dibutuhkan, dan ini seharusnya tidak bersesuaian dengan operasi perluasan dari LDAP. Hanya satu jenis extension yang telah distandarisasi dinamakan bindname extension. Bindname extension mengijinkan client untuk merincikan DN dari direktori entry yang digunakan untuk mengesahkan direktori. Setelah pengesahan tantangan berikutnya adalah memulainya.
Ini merupakan contoh dari URL LDAP (Arkills, 2003): ldap://mycompany.com:389/cn=Brian
Seperti contoh yang diberikan pada gambar 2.10, hasil operasi search diatas akan
mengembalikan atribut sn dari entry cn=Brian
Arkills,ou=People,dc=mycompany,dc=com. Hasil search mempunyai jangkauan subtree, tetapi entry yang dirincikan base DN tidak mempunyai child, sehingga hanya satu entry yang dikembalikan.
2.3.3.2 Client LDAP Operation
M enurut Arkills (2003), ketika membuat struktur namespace merupakan hal yang sangat penting untuk administrator direktori, operasi LDAP adalah pusat dari interaksi antara client dan server. Operasi LDAP dikarenakan tipe user seperti apa yang dibutuhkan dalam direktori untuk diketahui, meskipun software client yang bagus meringkaskan pada saat terjadi interaksi dari tampilan. User mungkin hanya memerlukan operasi search, yang terjadi pada kebanyakan operasi perincian. Ada sepuluh operasi utama yang dijabarkan oleh standar LDAP. Administrator dan programmer menggunakan keseluruhannya ketika mengatur informasi direktori dan membuat proses bisnis khusus yang berinteraksi dengan informasi direktori.
Salah satu topik paling nyata yang termasuk interaksi client-server adalah client LDAP itu sendiri. Software client merupakan kunci untuk people menemukan direktori LDAP yang berguna dan mudah untuk digunakan.
2.3.3.2.1 Directory Enable Services and Aplication
M enurut Arkills (2003), banyak keuntungan aplikasi datang dari kemampuan aplikasi tersebut untuk berhubungan dengan direktori untuk mendapatkan informasi. Sebuah aplikasi atau servis yang dapat menjadi client LDAP disebut dengan directory-enabled.
Diantara aplikasi directory-enabled yang paling umum adalah servis email. Ketika sebuah server email menerima email. Server dapat melakukan query pada direktori apakah alamat email penerima berada pada site lokal dan apakah mail server tempat mailbox penerima aktif. M emusatkan informasi ini pada direktori mempermudah administrasi dari server email dengan menghilangkan kebutuhan untuk menyelaraskan copy dari informasi ini pada setiap email server.
Hal yang serupa, email client dapat menjadi directory-enabled, dan menyediakan servis yang berharga dengan mencari alamat email yang dituju yang memberikan nama seseorang. Beberapa email client mengijinkan user untuk melihat direktori lewat sebuah tampilan di dalam aplikasi email dan membawa lebih dari satu penerima untuk sebuah email.
Servis directory-enabled mempunyai beberapa batasan. Sebagai contoh, penggunaan direktori LDAP (Arkills, 2003).
• Sebagai penyimpan sertifikat wewenang berhubungan dengan teknologi sertifikat public-private. Ini mengijinkan untuk menyediakan sebuah servis untuk menguji kevalidan dari sertifikat yang ada.
• Untuk menggolongkan lokasi dari HTML dan tipe lain dari dokumen elektronik. Kemudian dapat melakukan query dan mengembalikan rincian dokumen yang pantas, hanya akan seperti katalog perpustakaan yang akan melakukan.
Implementasi LDAP Microsoft Active Directory adalah contoh yang baik dari bagaimana keragaman dari servis directory-enabled dapat disatukan. Dengan menggunakan Microsoft Active Directory, software dapat disebarkan pada komputer, user, dan pengaturan komputer dapat diatur, printer dapat dipromosikan sebagai client, dll. Jelasnya ada keuntungan yang berpengaruh dengan memusatkan informasi dalam sebuah direktori, khususnya informasi yang menolong dalam mengatur resource. Mycompany mudahnya memerlukan kreatifitas dan penyatuan servis yang mengambil keuntungan dari direktori untuk merealisasikan kemampuannya.
2.3.3.2.2. Search
M enurut Arkills (2003), semua operasi LDAP terdiri dari client yang mengirimkan operasi request sepanjang dengan parameter ke server. Server kemudian menjalankan operasi dan mengirimkan sebuah kode hasil kembali ke client. Kode yang dikembalikan ini menandakan sukses atau gagalnya sebuah operasi. Ketika sebuah operasi adalah operasi search, server mengirimkan semua entry yang cocok dengan parameter yang lalu mengirimkan kode hasilnya. Tidak ada yang namanya operasi read, sehingga jika direktori user ingin membaca sebuah direktori yang khusus, maka harus dijalankan operasi search yang memerinci entry.
Operasi search mempunyai banyak parameter yang mengubah bagaimana server menjalankan operasi. Ini merupakan parameter wajib yang dibutuhkan atau operasi
search akan gagal, dan ada beberapa parameter tambahan yang memiliki nilai default jika tidak diatur. Parameter search hanya mempengaruhi sebuah operasi search untuk yang telah diatur. Untuk mengubah semua operasi LDAP untuk sebuah session, harus menggunakan LDAP option, jika ada salah satu yang sesuai.
Ada beberapa parameter search yang wajib, diantaranya adalah (Arkills, 2003): • Base DN untuk memulai search – sebuah ide bagaimana direktori dibentuk
sangat membantu disini. Dengan kata lain, jika ingin mencari person entry, apakah semuanya dalam container yang umum? Base DN terkadang juga disebut baseObject. Jika tidak tahu dari mana harus mulai, maka mulailah dari direktori root. Dalam direktori mycompany, ini akan seperti dc=mycompany,dc=com. Jadi pada saat yang paling minimum, harus mengetahui naming context dari direktori. • Scope dari search – ada tiga pilihan untuk scope. Scope base berarti hanya
mencari satu entry tunggal pada base DN. Scope one berarti mencari semua entry pada level yang sama pada urutan tingkatan dalam container dari base DN. Scope subtree berarti mencari base DN dan semua entry di bawah base DN, bagaimanapun juga tergantung dari level di dalam urutan tingkatan.
• Search filter – search filter disusun dari sebuah tipe atribut, sebuah comparison operator, dan sebuah nilai atribut. Ketiga komponen ini dikelilingi dengan tanda kurung dan bentuk sebuah objek search filter. Sintaks yang sederhana dari objek search filter adalah "("attributetype operator attributevalue")" dengan tidak ada spasi diantara semua elemen yang wajib. Tanda kutip yang mengelilingi merupakan hal yang mutlak dalam sintaks. Sebagai contoh, (objectclass=person) akan menjadi objek search filter yang valid. Satu atau lebih objek search filter
dapat digabungkan dengan operator filter untuk membentuk search filter, jadi contoh ini merupakan sebuah search filter yang valid.
Untuk mengilustrasikan penggunaan sebuah search filter, jika ingin menemukan sebuah entry yang digambarkan pada gambar 2.12 maka parameter search yang digunakan adalah :
Gambar 2.12 Mycompany dengan entry person
Objek filter dapat digabungkan dalam parameter search filter dengan menggunakan filter operator. Filter operator dapat mengubah sebuah objek filter yang telah dirincikan dalam parameter search filter, dan dapat digunakan untuk menggabungkan banyak filter untuk menandakan keruwetan dari pengaturan banyak entry.
• & AND
• | OR
• ! NOT
Operator ini harus mendahului filter yang diubah. Langkahnya hampir sama dengan bagaimana fungsi dalam bahasa LISP atau operasi dalam mengembalikan polish kalkulator yang diwakilkan. Filter yang berikutnya mengilustrasikan penggunaan dari filter operator dengan direktori ditunjukkan pada gambar 2.13 semua contoh mengira menyediakan sebuah base DN pada root dari direktori, sepanjang dengan scope subtree.
Gambar 2.13 Contoh mycompany untuk pencarian filter operator
• Informasi atribut apa yang dikembalikan – jika tidak merincikan apa yang diinginkan, semua atribut dari entry yang ditemukan oleh server akan dikembalikan. Perincian tipe atribut dapat dipisahkan dengan tanda koma. Operational attribute, dimana atribut yang digunakan direktori untuk kepentingannya sendiri, tidak pernah dikembalikan kecuali dirincikan secara explisit.
• derefAliases – menunjukkan bagaimana cara bertransaksi dengan alias entry. Alias entry adalah sebuah dummy entry yang merujuk atau mengarah pada entry yang lain. M enghormati sebuah alias adalah dengan mudah mengajarkan server untuk pergi pada objek yang dirujuk oleh alias, dan untuk tujuan dari operasi search, memperlakukan objek yang dirujuk sebagai alias object.
- neverDerefAliases - jangan melihat pada alias yang dirujuk.
- derefInSearching - melihat semua alias yang dirujuk kecuali pada baseObject.
- derefFindingBaseObj - melihat pada alias yang dirujuk tetapi hanya pada baseObject.
- derefAlways – melihat pada semua alias yang dirujuk.
• sizeLimit – batas angka dari entry yang dikembalikan pada operasi search. Nilai default-nya adalah 0 yang menunjuk pada tidak ada batasan. Jika suatu operasi search menemukan entry lebih dari pada yang dirincikan sebagai batasan, hanya kumpulan angka pertama yang dikembalikan. Dalam kasus ini, kode hasil dari
LDAP_SIZELIMIT_EXCEEDED dikembalikan untuk menunjuk bahwa terdapat hasil yang lebih banyak.
• timeLimit – batasan waktu dalam detik diijinkan untuk menyelesaikan sebuah operasi search. Nilai default-nya adalah 0 yang menunjuk pada tidak adanya batasan. Jika sebuah operasi search membutuhkan waktu lebih lama untuk diselesaikan dibandingkan dengan waktu yang ditentukan, operasi akan selesai pada waktu yang ditentukan. Hanya entry yang ditemukan pada kurun waktu ini yang dikembalikan. Pada kasus ini, kode hasil dari LDAP_TIMELIMIT_EXCEEDED dikembalikan untuk menunjukkan hasil yang diperoleh lebih besar. Beberapa implementasi dari server LDAP mengijinkan administrator direktori untuk mengatur kewajiban menaikkan timeLimit untuk semua operasi cient. Beberapa server LDAP memiliki user khusus yang dapat menggantikan batas waktu server. Client dapat mengatur batasan dengan nilai lebih rendah, tetapi batasan lebih besar daripada batasan server yang diabaikan. • typesOnly – jika diatur menjadi true, hasilnya akan merinci hanya tipe atribut,
bukan nilainya. Nilai default dari false adalah untuk menunjukkan bahwa tipe atrubut dan nilainya harus dikembalikan.
Dalam penambahan pada operator filter, operator yang lain, disebut match operator atau comparison operator, dapat mengubah search filter. Kebanyakan dokumen pada pokok permasalahan ini membingungkan match operator dengan filter operator. Tetapi match operator tidak bekerja pada seluruh ekspresi filter, hanya pada nilai atribut. Match operator biasanya merupakan operator matematika umum, seperti equality, atau greater
than atau equal. Match operator digunakan untuk menolong untuk menandakan entry yang cocok dengan nilai parameter atribut yang diinginkan. Operasi digunakan untuk mencocokkan perubahan tergantung dari tipe khusus dari data yang disimpan dalam atribut. Kebanyakan atribut menyimpan beberapa tipe dari nilai string, dengan kata lain text. Oleh karena itu, kebanyakan operator match yang umum akan menggunakan operator match string. Ini adalah beberapa operator match string (Arkills, 2003):
• = Equality
• <= Less than or equal to - (sn<=Arkills) akan entry huruf sebelumnya pada Arkills dengan tambahan pada Arkill, sebagai contoh sn=Adams. Sebagai catatan dalam menggabungkan dengan bukan operator filter, pembuatan operasi greater-than dengan tidak memasukkan entry yang sama.
• >= Greater than or equal to - (sn>=Arkills) akan mengembalikan entry setelah Arkill ditambahkan pada Arkill, sebagai contoh sn=Chewbacca. Sebagai catatan dalam menggabungkan dengan bukan operator filter, dapat menciptakan operasi less-than
• ~= approximate - (sn~=Cat) akan mengembalikan entry seperti sn=Scat, sn=Cast, sn=Hat, dan sn=Mat. Algoritma dipergunakan untuk memperkirakan kecocokan berbagai macam filter tergantung dari implementasinya. Biasanya sebuah karakter wildcard diijinkan dalam beberapa posisi, tapi ini tidak distandarisasi, dan pendekatan match operator tidak selalu diimplementasi.
Akhirnya, asterisk (*) dapat digunakan sebagai wildcard untuk kosong atau lebih karakter dalam nilai sebuah string. Wildcard digunakan untuk mengetahui keberadaan dari atribut atau dalam kombinasi dengan karakter lain untuk menemukan substrings. Dalam contoh yang ditunjukkan pada gambar di bawah ini, search filter dari (cn=*Skywalker) akan mengembalikan entry baik Luke dan Anakin Skywalker. Baik kehadiran dan kemampuan substring yang dimiliki wildcard sangat berguna.
2.3.3.2.3 LDAP protocol
M enurut Arkills (2003), pembahasan LDAP client-server memperkecil proses pengeluaran dari client. Server bertanggung jawab untuk menjalankan operasi yang diminta dan melakukan proses pengisisan, ketika memenuhi permintaan client. Dalam model client-server, sever dibuat untuk menangani masukan perhitungan yang besar, dengan proses dan kapasitas memori yang lebih besar, ketika client mempunyai sedikit kemampuan perhitungan. Setelah server melakukan operasi permintaan, client menerima response atau error dari server. Client mempunyai sedikit pekerjaan selain mengirimkan request dan menerima jawaban.
Tabel 2.5 Karakter search filter khusus
LDAP didasarkan pada pesan, sehingga client dapat membuat banyak request dalam satu session. Banyak operasi dari session yang sama, masing-masing menerima perhatian dari server pada saat yang sama, dan karena itu keputusan yang baik dalam bekerja dapat dijalankan secara bersamaan. Banyak session dari client yang sama juga dimungkinkan pada saat yang sama, sehingga satu client dapat berhubungan dengan lebih dari satu server LDAP.
Jika sebuah client mengirimkan sebuah search request yang mengembalikan beberapa entry, beberapa pesan juga dikembalikan pada client. Setiap pengembalian
entry dibatasi dengan pemisahan pesan pada client; dan ketika semua entry dikembalikan, pesan kode hasil terakhir dikirimkan pada client. Seharusnya sebuah penyerahan dikembalikan, kemudian tergantung dari setting aplikasi, tambahan lalu-lintas client atau server menghasilkan kode hasil terakhir yang sebelumnya menandakan penyelesaian dari operasi. Asynchronous LDAP API mengubah kebiasaan ini.
LDAP transport membuat banyak efisiensi dalam penggunaan lalu-lintas jaringan. LDAP menggunakan TCP/IP untuk komunikasi jaringan. TCP/IP merupakan prosesor dan memori yang khusus, dengan pengecekan kesalahan dibuat dalam sebuah protokol, ini merupakan bagian yang paling efisien untuk session untuk lebih dari panjang yang sederhana. Nyala dan matinya dari session TCP dapat menjadi sangat mahal dalam penggunaan komputer dan resource jaringan. Kemampuan untuk menjalankan banyak operasi membuat LDAP memiliki kemampuan untuk penggunaan yang lebih baik dari resource komunikasi.
Hubungan client-server biasanya mengikuti pola ini (Arkills, 2003):
• Client berhubungan dengan server dan meminta sebuah bind operation.
• Server mengembalikan bind operation mengembalikan kode (sukses atau proses berakhir disini)
• Client meminta sebuah search operation (atau beberapa operasi yang lain) • Server mengembalikan pesan dengan menempatkan satu entry atau banyak
entry dari search operation. Jika tidak ada entry yang ditemukan, tidak ada pesan entry yang dikirimkan.
• Server mengirimkan kode hasil search operation pada client • Client meminta sebuah unbind operation
• Server mengirimkan kode hasil unbind dan menutup hubungan
Sebagai catatan bahwa kode hasil adalah penting, karena itu tanda dari penyelesaian sebuah operasi sejauh mana server menaruh perhatian.
Ada satu bentuk hubungan dengan direktori LDAP yang menggunakan pengurangan komunikasi yang tetap daripada protokol LDAP tradisional yang mendasarkan pada TCP yang saling mempengaruhi. Bentuk ini disebut sebagai connectionless LDAP, terkadang disingkat sebagai CLDAP. RFC 1798 mendefinisikan CLDAP, yang menggunakan UDP dibanding TCP. Transaksi CLDAP dapat menggunakan tiga paket jaringan lebih sedikit dibandingkan LDAP. CLDAP lebih lanjut mempermudah model direktori dengan membatasi jumlah operasi yang dijalankan. CLDAP secara utama dimaksudkan untuk penggunaan client yang sangat mudah yang membutuhkan pencarian informasi secara cepat pada direktori.
Ada sepuluh operasi yang dibuat dalam LDAP untuk keperluan berinteraksi dengan direktori. Batasan angka dalam operasi berarti baik client maupun server dapat dengan mudah diimplementasi dan membutuhkan batasan resource.
Operasi bind merupakan request pertama dari client pada server. Binding adalah tugas yang sama seperti pengecekan wewenang dari direktori. Client menguji identitas yang dikirimkan pada direktori, sehingga semua operasi yang akan dilakukan selanjutnya dapat dilakukan dalam konteks identitas tersebut. Client yang tidak melakukan bind, atau melakukan bind dengan string kosong, disebut sebagai anonymous.
Operasi search sudah dibahas sebelumnya. Operasi compare secara sederhana mengecek apakah informasi yang ditinggalkan client cocok dengan informasi yang disimpan dalam direktori. Operasi add mengijinkan client untuk membuat satu entry
baru. Operasi ini memerlukan penjelasan client tentang object class yang terdapat pada entry yang baru, dan semua kewajiban atribut dari object class disediakan dengan nilainya. Sebagai contoh adalah operasi add pada direktori mycompany (Arkills, 2003):
Operasi delete menghapus sebuah entry dari direktori. Semua informasi yang berkaitan dengan entry tersebut akan dihapus. Sebagai contoh operasi delete adalah (Arkills, 2003):
Operasi modify adalah operasi mengubah atribut yang telah ada dalam sebuah entry, menghapus nilai atribut, atau menambah sebuah nilai pada satu atau lebih atribut. Sebagai contoh operasi modify adalah (Arkills, 2003):
Operasi modifyRDN mengijinkan client untuk mengganti nama dari entry direktori. Ada empat parameter yang digunakan. Untuk lebih jelasnya perhatikan contoh berikut (Arkills, 2003):
Gambar 2.15 Penggunaan modifyRDN untuk hanya mengubah RDN
Operasi unbind mengijinkan client untuk mengakhiri session yang telah ada dengan direktori. Operasi abandon mengijinkan client untuk mengatakan pada direktori untuk menggagalkan operasi sebelumnya yang diminta secara khusus oleh client. Operasi extended adalah sebuah pemegang keputusan untuk implementasi direktori secara khusus untuk menyampaikan kegunaan dari direktori, tetapi masih memiliki sintaks yang telah didefinisikan sebelumnya untuk melakukan ini.
2.3.3.3 LDAP S chema
M enurut Arkills (2003), schema menentukan aturan yang menguasai sebagian besar dari apa yang direktori LDAP dapat lakukan. Schema menentukan jenis apa dari entry yang dapat dibuat dalam direktori. Ini menentukan informasi apa yang dapat disimpan. Jadi pengubahan schema dapat meningkatkan lebih besar nilai dari direktori LDAP dan fleksibilitasnya.
Pengubahan schema untuk mengijinkan sebuah tipe baru dari objek atau sebuah tipe atribut baru. Ini berdampak pada pembuatan tipe bari dari sebuah entry yang dapat ditambah lebih banyak pada fungsi dari direktori itu sendiri.
Schema terdiri dari beberapa komponen. Pada gambar di bawah ini ditunjukkan bagaimana setiap elemen dari schema berhubungan dalam konteks dari schema.
Sebuah object class menentukan jenis entry yang diperbolehkan dalam direktori. Sebuah object class mendefinisikan aturan konten, aturan struktur, bentuk nama , dan informasi tambahan operasional.
2.3.3.4 Directory management
M enurut Arkills (2003), menggabungkan informasi ke dalam sebuah direktori adalah alasan utama dari pengimplementasian LDAP. Kontrol administratif mengijinkan administrator sebuah direktori untuk lebih mudah mengatur direktori LDAP yang oleh karena itu berhubungan dengan nilai bisnis yang disediakan oleh LDAP.
2.3.3.4.1 Directory security
M enurut Arkills (2003), Autentication adalah sebuah proses yang menyatakan dan menegaskan siapa sebenarnya user, dengan kata lain ini membangun identitas dari client. Secara praktek identitas ini biasanya adalah sebuah username, user identity (uid), tiket, atau sertifikat.
M enurut Arkills (2003), Authorization adalah sebuah proses pembangunan dimana sebuah client diotorisasi untuk mengakses resource. Proses ini dapat ditentukan dengan kombinasi dari faktor access control seperti authentication identity, source IP, kekuatan enkripsi, metode autentikasi, operasi request, dan sumber request.
Tabel 2.5 Tipe aturan akses direktori
Certificate memetakan sebuah public key pada sebuah identitas. Sedangkan sebuah Certificate Authority (CA) adalah wewenang dari bagian lain yang dapat dipercaya. Sebagai contoh agar lebih jelas dapat dilihat pada gambar di bawah ini.
Secure Socket Layer (SSL) menggabungkan enkripsi public dan secret key. SSL juga dapat digunakan untuk mengenkripsi sebuah servis session antara banya dua bagian. Transport Layer Security (TLS) merupakan turunan dari SSL. TLS juga merupakan sebuah standar untuk internet, hal ini didefinisikan dalam RFC 2246.
2.4 Single Sign On (SSO)
2.4.1 Pengertian Single Sign On (SSO)
Single sign-on (SSO) adalah sebuah session atau proses autentikasi user yang mengijinkan user untuk menyediakan sebuah credential sekali dengan maksud untuk mengakses banyak aplikasi (Wikipedia, 2007n; Kristian Aaslund et al, 2007). Single sign on (SSO) mengautentikasi user untuk mengakses semua aplikasi yang telah di-authorized untuk diakses. Ini menghilangkan permintaan authenticaton lagi ketika user mengganti aplikasi selama session berlaku (Kristian Aaslund et al, 2007). .
2.4.2 Central Authentication Service (CAS )
2.4.2.1 Pengertian CAS
CAS adalah merupakan sebuah sistem autentikasi yang aslinya dibuat oleh Universitas Yale untuk menyediakan sebuah jalan yang aman untuk sebuah aplikasi untuk meng-autentikasi seorang user. CAS kemudian diimplementasi sebagai sebuah open source komponen server Java dan mendukung library dari client untuk Java, PHP, Perl, Apache, uPortal, dan lainnya. CAS server sebagai sebuah dasar untuk beberapa framework untuk keamanan dan solusi SSO (Kristian Aaslund et al, 2007).
2.4.2.2 Dasar pemikiran
Dalam tahap pembuatannya, CAS memiliki beberapa alasan dasar pemikiran yang melandasi pembuatan servis ini, diantaranya adalah :
• Untuk memfasilitasi Single Sign On dalam melewati banyak aplikasi web. Sebagai sebuah servis inti, CAS tidak memerlukan web-based tetapi memiliki front-end web.
• Untuk mengijikan servis yang tidak dipercaya yang ditawarkan oleh organization dibandingkan ITS (servis yang dapat dipercaya) untuk mengautentikasi user tanpa memiliki akses pada password-nya.
• Untuk mempermudah prosedur yang diperlukan aplikasi untuk diikuti dengan tujuan untuk melakukan autentikasi.
• Untuk membatasi autentikasi yang utama menjadi satu aplikasi web, dimana mempermudah user untuk menjaga keamanan password-nya dan mengijinkan aplikasi yang dipercaya untuk mengubah logika autentikasinya bila perlu, tanpa harus mengubah banyak aplikasi
2.4.2.3 Design CAS
Central Authentication Servise (CAS) dibentuk sebagai sebuah aplikasi web yang berdiri sendiri. Untuk lebih jelasnya dapat dilihat pada gambar dibawah ini.
Gambar 2.18 Arsitektur CAS
URL login menangani autentikasi yang utama. Karena itu CAS mendorong user dengan sebuah NetID dan password dan validasinya melawan provider yang mendukung autentikasi. Pengembang CAS yang berbeda akan menghubungkan bermacam PasswordHandler untuk mengesahkan username dan password melawan dukungan mekanisme autentikasi manapun yang selaras.
Untuk mencegah kemungkinan dari pengulangan autentikasi, CAS juga melakukan usaha untuk mengirimkan sesuatu dalam memory cookie (ini akan hancur ketika browser ditutup) kembali ke browser. Cookie ini, bisa disebut “ticket-granting cookie”, mengidentifikasi user sebagai satu yang telah melakukan logged in.
2.4.2.4 Menangani servis non-web
Dari perspektif CAS, tidak ada perbedaan yang mencolok antara sebuah web servis yang menyediakan content-nya sendiri dan yang bergantung pada sebuah end servis. Secara logika, CAS secara sederhana menggabungkan front-end dan back-end menjadi satu. Bagaimanapun, yang diberikan front-back-end dan back-back-end adalah bukan program yang sama.
Untuk mengikuti desain untuk web aplikasi yang membutuhkan autentikasi user pada back-end, non-web service. M aka back-end harus diubah, secara umum dapat dilakukan dengan 3 cara :
• Ini harus dapat mengenali usaha untuk mengautentikasi menggunakan tiket CAS sebagai pengganti bagian username atau password.
• Ketika tiket dikenali, maka ini harus dapat mengesahkannya dengan langsung menghubungi server CA S.
• Ketika tiket dikenali, maka ini juga harus mengecek untuk meyakinkan bahwa tiket dikirimkan dari sebuah host yang sanggup untuk menerima surat pengesahan wakil.
