bab ii landasan teori

30

Click here to load reader

Upload: iqbal-ramadhan

Post on 20-Oct-2015

25 views

Category:

Documents


0 download

DESCRIPTION

BAB II LDAP

TRANSCRIPT

Page 1: 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

Page 2: Bab II Landasan Teori

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.

Page 3: Bab II Landasan Teori

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

Page 4: Bab II Landasan Teori

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

Page 5: Bab II Landasan Teori

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

Page 6: Bab II Landasan Teori

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

Page 7: Bab II Landasan Teori

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

Page 8: Bab II Landasan Teori

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.

Page 9: Bab II Landasan Teori

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.

Page 10: Bab II Landasan Teori

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

Page 11: Bab II Landasan Teori

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

Page 12: Bab II Landasan Teori

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

Page 13: Bab II Landasan Teori

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

Page 14: Bab II Landasan Teori

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

Page 15: Bab II Landasan Teori

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.

Page 16: Bab II Landasan Teori

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.

Page 17: Bab II Landasan Teori

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

Page 18: Bab II Landasan Teori

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.

Page 19: Bab II Landasan Teori

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.

Page 20: Bab II Landasan Teori

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

Page 21: Bab II Landasan Teori

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.