Download - Bab II Landasan Teori
BAB II
LANDASAN TEORI
1.1 Lightweight Directory Access Protocol (LDAP)
LDAP merupakan kependekan dari Lightweight Directory Access Protocol
adalah suatu aplikasi dan protokol untuk query dan memodifikasi layanan
direktori yang berjalan pada protokol TCP/IP. Sebuh direktori adalah suatu set
objek dengan atribut yang diselenggarakan dengan cara logis dan hierarkis.
Sebuah contoh sederhana adalah direktori telepon, yang terdiri dari daftar nama-
nama (baik nama orang atau organisasi) yang disusun menurut abjad, dengan
nama masing-masing memiliki alamat dan nomor telepon yang terkait dengan
nya.
Pohon direktori LDAP berisi daftar politik, geografis, dan/atau batas-batas
organisasi, tergantung pada model yang dipilih. Penerapan LDAP pada saat ini
cenderung menggunakan Domain Name System (DNS) untuk struktur di tingkat
paling atas dari hierarki. Versi terakhir dari LDAP adalah LDAPv3 yang
ditentukan oleh Internet Engineering Task Force (IETF) sebagai RFC4510.
Menurut Carter (2003), pengertian LDAP dibagi menjadi 3 bagian, yaitu :
1. Lightweight
2. Directory
3. Access Protocol
11
12
1.1.1 Lighweight
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 protokol suite,
tetapi ketika dibandingkan dengan TCP/IP protokol 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.
13
Gambar 2.1 X.500 dengan OSI Vs LDAP dengan TCP/IP
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.
1.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
14
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.2 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
15
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).
1.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 responsnya mungkin datang dalam urutan yang
berbeda ketika permintaan itu dimunculkan (Carter, 2003).
16
Gambar 2.3 LDAP Request dan Response
1.1.4 Struktur Direktori LDAP
Struktur direktori LDAP mengikuti struktur direktori dari X.500
edisi 1993. Isi direktori jika direpresentasikan dengan format LDIF terlihat
seperti di bawah ini.
# Barbara's Entry dn: cn=Barbara J Jensen,dc=example,dc=com cn: Barbara J Jensen cn: Babs Jensen objectClass: person sn: Jensen
# Bjorn's Entry dn: cn=Bjorn J Jensen,dc=example,dc=com cn: Bjorn J Jensen cn: Bjorn Jensen objectClass: person sn: Jensen # Base64 encoded JPEG photo jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer's Entry dn: cn=Jennifer J Jensen,dc=example,dc=com cn: Jennifer J Jensen cn: Jennifer Jensen objectClass: person sn: Jensen
17
# JPEG photo from file jpegPhoto:< file:///path/to/file.jpeg
Dimana dn merupakan nama dari kumpulan data diatas, cn adalah common
name, sn adalah surname, dc adalah domain component. Berikut
merupakan tabel untuk singkatan yang biasa di gunakan dalam LDAP :
Tabel 2.1 Daftar Singkatan pada LDAP
Singkatan Keterangandn distinguished nameo organizationou organization unitdc domain componentscn common namesn surnameuid user idc country namel locality namest stategn given name
mail e-mail address
1.1.5 Operasi LDAP
Client mengirimkan permintaan ke server berupa ID pesan dan
server merespon dengan ID yang sama. Respon dapat termasuk kode-kode
numerik yang dapat diartikan sebagai query sukses, error ataupun pesan-
pesan lainnya. Proses lengkap dari operasi LDAP ini adalah :
1. Pengertian TLS
2. Bind (Otentikasi)
3. Mencari dan mencocokan data
4. Unbind
18
1.1.5.1 Pengertian TLS
TLS (Transport Layer Security) merupakan turunan SSL
(Security Socket Layer) dapat digunakan untuk melindungi data dari
kemungkinan proses penyadapan. Pada saat proses negosiasi, server
mengirimkan sertifikat X.509 untuk membuktikan identitasnya, begitu
juga client. Setelah identitas masing-masing diketahui, client dapt
menggunakan SASL untuk mengotentikasi dirinya.
Server juga dapat menyediakan layanan LDAPS yang tidak
standar dengan menggunakan SSL. Layanan ini menggunakan port
berbeda, biasanya pada port 636. Layanan ini mulai ditinggalkan pada
LDAPv3 dan hanya digunakan pada LDAPv2.
1.1.5.2 Bind (Otentikasi)
Operasi bind akan mengotentikasikan client ke server penyedia
layanan. Proses bind sederhana mengirimkan DN dan password dalam
kondisi plain text sehingga diperlukan TLS untuk melindungi koneksi
dari kemungkinan penyadapan.
Pada LDAPv2, bind merupakan operasi pertama yang harus
dilakukan sebelum melakukan operasi-operasi selanjutnya, hal ini tidak
diperlukan lagi pada LDAPv3.
19
1.1.5.3 Mencari dan Mencocokan Data
Operasi ini bertujuan untuk mencari data dan membaca data pada
direktori sesuai dengan permintaan pemakai. Parameter dari operasi ini
adalah :
baseObject : DN (Distinguished Name) dari isi yang akan dicari
scope : Elemen yang akan dicari pada struktur direktori dibawah
baseObject. Bisa berupa baseObject (nama, alamat), singleLevel (satu data
tepat dibawah baseObject), atau wholeSubstree (semua data yang ada pada
DN)
1.1.5.4 Unbind
Operasi unbind berfungsi untuk meninggalkan semua operasi dan
menutup koneksi ke server penyedia layanan LDAP. Operasi ini tidak
memiliki respon.
User dapat membatalkan sesi dengan hanya menutup koneksi,
akan tetapi untuk lebih aman user harus melakukan operasi unbind jika
akan meninggalkan sesi. Unbind akan memberikan kesempatan kepada
server untuk menutup koneksi dengan sempurna, mengurangi
kemungkinan sesi dapat dipakai oleh user lainnya, membebaskan
resource yang dipakai oleh koneksi dan juga memerintahkan server
untuk membatalkan operasi yang bisa dibatalkan dan tidak akan
mengirimkan respon untuk operasi yang tidak dapat dibatalkan.
20
1.1.6 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):
1. 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.
2. 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
21
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.4 Contoh Tree Directory 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.
3. Fungsional Model
Model fungsional adalah protokol LDAP itu sendiri. Protokol ini
menyediakan tujuan untuk mengakses data dalam tree direktori. Akses
22
diimplementasikan dengan operasi otentikasi (binding), operasi query
(search dan read), dan operasi update (write).
4. Security Model
Model 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.
1.1.7 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
23
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.
Gambar 2.5 Diagram Konseptual dari Schema
1.1.8 Directory Management
Menurut Arkills (2003), menggabungkan informasi ke dalam
sebuah direktori adalah alasan utama dari pengimplementasian LDAP.
Kontrol administratif mengijinkan administrator sebuah direktori untuk
24
lebih mudah mengatur direktori LDAP yang oleh karena itu berhubungan
dengan nilai bisnis yang disediakan oleh LDAP.
1.1.9 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.
Tabel 2.2 Tipe Aturan Akses Direktori
Certificate memetakan sebuah public key pada sebuah identitas.
Sedangkan sebuah Certificate Authority (CA) adalah wewenang dari
25
bagian lain yang dapat dipercaya. Sebagai contoh agar lebih jelas dapat
dilihat pada gambar di bawah ini.
Gambar 2.6 CA dengan Certificate
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.
26
1.2 Central Authentification Service (CAS)
Central Authentication Service (CAS) merupakan sebuah sistem otentikasi
yang aslinya dibuat oleh Universitas Yale untuk menyediakan sebuah jalan yang
aman untuk sebuah aplikasi untuk mengotentikasi 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 Single Sign On (Kristian Aaslund et al, 2007).
CAS terdiri dari kumpulan java servlet dan dapat berjalan pada hampir
semua servlet engine (JSP spec 1.2. compliant) yang menawarkan layanan
otentikasi berbasis web. Kelebihan dari CAS adalah keamanan, fitur proxying,
fleksibilitas, ketahanan dan pustaka client yang bermacam-macam. Gambar 2.7
menggambarkan proses otentikasi dan perjalanan user dan password pada aplikasi
tanpa CAS dan aplikasi terintegrasi dengan CAS.
Pada aplikasi tanpa CAS proses otentikasi terjadi pada masing-masing
aplikasi dan tiap aplikasi mengakses database user dimana proses ini sangat
rawan terhadap penyadapan data login. Sedangkan pada aplikasi dengan CAS
proses otentikasi dan pengaksesan database user hanya berjalan pada server
otentikasi. Aplikasi memanfaatkan tiket yang dihasilkan server otentikasi untuk
melakukan otentikasi terhadap user.
27
Gambar 2.7 Perbandingan Penggunaan CAS
Kelebihan-kelebihan yang terpasang pada CAS antara lain :
1. Keamanan
Keamanan diimplementasikan dengan cara :
a. Password hanya dikirim dari browser ke server otentikasi dimana proses
pengiriman selalu melewati jalur yang terenkripsi.
b. Otentikasi ulang tidak terlihat pada sisi user, yang memastikan bahwa cookie
yang diterima adalah cookie yang unik, cookie ini disebut “Ticket Granting
Cookie”. Cookie ini tidak mengandung informasi pribadi dari user yang
melakukan proses otentikasi, terlindungi dengan protokol HTTPS dan hanya
dapat dibaca oleh server otentikasi
c. Tiket yang telah dikeluarkan oleh server otentikasi dikirim ke aplikasi yang
meminta otentikasi melalui web browser dan akhirnya divalidasi oleh server
28
otentikasi, sehingga dengan mekanisme ini aplikasi tidak pernah meminta
data nama user dan password kepada user aplikasi tersebut.
2. Otentikasi Proxy
Mekanisme Single Sign On klasik tergantung pada komunikasi antara
browser dan aplikasi yang menyebabkan installasi multitier tidak bisa
dijalankan pada aplikasi yang membutuhkan layanan backend untuk
otentikasi.
CAS Versi 2.0 dapat mengatasi masalah ini dengan menawarkan cara
yang lebih baik untuk otentikasi. Dengan proxy granting ticket dan proxy
ticket yang mengijinkan aplikasi pihak ketiga untuk mendapatkan otentikasi.
Fitur ini merupakan kelebihan yang utama pada CAS.
3. Fleksibilitas
Paket yang ditawarkan oleh pengembang CAS adalah implementasi
lengkap dari protokol otentikasi, akan tetapi otentikasi itu sendiri
(pengelolaan database user dll) harus dilakukan oleh administrator.
Pustaka Client
Kode dari protokol dasar dapat dengan mudah ditulis pada sisi klien.
Pustaka tambahan tersedia untuk bahasa Perl, Java, ASP, PHP, dan PL/SQL.
Semua pustaka tersebut memberikan fleksibilitas yang baik untuk memasukkan
CAS pada suatu aplikasi hanya dengan menambahkan beberapa baris code.
29
1.3 Konsep Dasar Single Sign On (SSO)
Single Sign On (SSO) adalah teknologi yang mengizinkan pengguna
jaringan agar dapat mengakses sumber daya dalam jaringan hanya dengan
menggunakan satu acccount user saja (once register multiple access). Teknologi
ini sangat diminati, khususnya dalam jaringan yang sangat besar dan bersifat
heterogen. Dengan menggunakan SSO, seorang pengguna hanya cukup
melakukan proses otentikasi sekali saja untuk mendapatkan izin akses terhadap
semua layanan yang terdapat di dalam jaringan.
Contoh dari sistem SSO adalah protokol Kerberos, yang telah dimasukkan
ke dalam sistem operasi Windows 2000 ke atas. Protokol yang sama dapat juga
digunakan di dalam keluarga sistem operasi UNIX. Novell juga telah menawarkan
fungsi SSO miliknya sendiri, yang disebut sebagai Novell Single Sign On (NSSO)
yang dapat digunakan dalam lingkungan Windows/NetWare. Beberapa
perusahaan, seperti Entrust Technologies dan RSA Security menawarkan fungsi
SSO yang berbasis kriptografi kunci publik.
1.4 World Wide Web (WWW)
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.
30
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 hypertext
yang dinamik untuk dokumen lain disimpan pada komputer yang sama atau
berbeda.
1.5 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).
31
1.6 WordPress
WordPress adalah aplikasi blog dan content management system yang
ditulis menggunakan bahasa php. WordPress adalah pengembangan dari
b2/cafelog yang dikembangkan oleh Michel Vardighi. Pada bulan Mei 2003
wordpress rilis pertama diluncurkan. WordPress juga mendukung penggunaan
blog multi user dengan mengaktifkan plugin multi user.
1.7 Moodle
Moodle adalah aplikasi e-learning yang dikembangkan oleh Moodle
company yang berbasis di Perth, Australia. Pertama kali dirilis pada tahun 1999
dan mulai menggunakan arsitektur saat ini mulai tahun 2001. Moodle dapat
berjalan hampir pada semua sistem yang mendukung php dan database, database
yang didukung oleh moodle sampai dengan versi 2.3 adalah mysql dan postgresql.
Seperti halnya squirrelmail, moodle juga menggunakan plugin untuk
menambakan fitur-fitur yang tidak tersedia pada program pokok.