8

BAB 2

LANDASAN TEORI

2.1 Internet

2.1.1 Pengertian

Menurut 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.

Menurut 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

Menurut 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

8

9

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

Menurut 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.

Menurut 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

10

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 (Mannaert et al, 2003).

2.3 Lightweight Data Access Protokol (LDAP)

2.3.1 Pengertian LDAP

Menurut 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

11

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.

Menyediakan 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.

12

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).

13

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 HTML 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).

14

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).

Gambar 2.2 LDAP request dan response

15

2.3.2 Model LDAP

Model LDAP mewakili servis yang disediakan oleh server, seperti yang dilihat

oleh client. Model 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

Model 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

16

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

Model 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

Model security menyediakan sebuah mekanisme untuk client yang digunakan

untuk membuktikan identitas (authentication) dan untuk server adalah sebagai

17

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. Menurut

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.

18

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

19

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).

20

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. Manajemen 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

21

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.

Mengeksplorasi 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. Meskipun 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

22

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).

23

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

24

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 MX 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).

25

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 Structure

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.

26

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).

27

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

28

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.

Membuat 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).

Tabel 2.2 Object Class yang biasa digunakan sebagai Container

29

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).

30

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

31

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

32

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

Menurut 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.

33

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. Meskipun

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).

34

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.

35

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.

Membuat 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

36

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).

Tabel 2.4 Karakter khusus dalam Distinguish name

37

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.

38

• 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

Arkills,ou=People,dc=Mycompany,dc=com?sn

39

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

Menurut 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.

40

2.3.3.2.1 Directory Enable Services and Aplication

Menurut 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. Memusatkan 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.

41

• 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

Menurut 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

42

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

43

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.

Filter operator yang ada adalah (Arkills, 2003):

44

• & 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

Pilihan parameter search adalah (Arkills, 2003):

45

• 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. Menghormati 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

46

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

47

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.

48

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.

Gambar 2.14 Contoh direktori untuk pencocokan wildcard

49

2.3.3.2.3 LDAP protocol

Menurut 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

50

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

51

• 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

52

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):

Pada direktori akan terlihat seperti gambar berikut ini (Arkills, 2003):

53

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 Schema

Menurut 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.

54

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.

Gambar 2.16 Diagram konseptual dari schema

55

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

Menurut 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

Menurut 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.

Menurut 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.

56

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.

Gambar 2.17 CA dengan Certificate

57

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).

58

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.

59

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.

60

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 back-

end servis. Secara logika, CAS secara sederhana menggabungkan front-end dan back-

end menjadi satu. Bagaimanapun, yang diberikan front-end dan back-end adalah bukan

program yang sama.

Untuk mengikuti desain untuk web aplikasi yang membutuhkan autentikasi user

pada back-end, non-web service. Maka 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 CAS.

• Ketika tiket dikenali, maka ini juga harus mengecek untuk meyakinkan

bahwa tiket dikirimkan dari sebuah host yang sanggup untuk menerima surat

pengesahan wakil.