bab ii landasan teori

37
BAB II LANDASAN TEORI 2.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 8

Upload: iqbal-ramadhan

Post on 20-Oct-2015

32 views

Category:

Documents


7 download

DESCRIPTION

BAB II KP

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

8

Page 2: Bab II Landasan Teori

9

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

10

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

11

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

12

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

13

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

Page 7: Bab II Landasan Teori

14

sn: Jensen # 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

15

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

16

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

17

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

18

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

19

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

20

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

21

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

22

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

23

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

24

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

25

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

26

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

27

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

28

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.

2.7 Zimbra Collaboration Suites (ZCS)

Menurut Tuxkeren (2012:3) Zimbra Collaboration Suites (ZCS) atau yang

lebih dikenal dengan Zimbra adalah sebuah produk Groupware yang dibuat oleh

Zimbra, Inc yang berlokasi di Palo Alto, California, Amerika Serikat. Pada masa

awal-awalnya perusahaan ini dibeli oleh Yahoo! Tepatnya pada bulan September

2007.

Pada awal tahun 2010, Zimbra dibeli oleh VMWare. Aplikasi Zimbra

sendiri dibuat menjadi dua bagian komponenn yang bersifat Client dan Server.

Zimbra juga memiliki dua model lisensi, yaitu komersial dengan nama produk

Zimbra Network Edition, dan Zimbra Appliance yang bersifat virtualisasi serta

sebuah lisensi lagi yang bersifat open sources.

Zimbra web client ada sebuah perangkat kolaborasi yang penuh dengan

menggunakan teknologi AJAX, sehingga fitur-fitur seperti tool tips, drag and drop

item, dan klik kanan dapat dilakukan di internet browser, juga ditambah lagi

Page 22: Bab II Landasan Teori

29

dengan addons yang dinamakan Zimlet sehingga membuat Zimbra menjadi kaya

fitur.

Sementara untuk Zimbra server, menggunakan teknologi dari beberapa

aplikasi open sources yang sudah matang dan stabil, yang meliputi aplikasi MTA,

POP3, LDAP, MySQL dan lain-lain. Zimbra server sendiri dapat di install di

beberapa distro linux yang terkenal.

Pembuat Zimbra pertama kalinya adalah Mr. Scott Dietzen, nama Zimbra

sendiri terinspirasi dari lagu pop tahun 70an yang berjudul “I Zimbra” yang

dibawakan group band Talking Heads.

2.8 System Flowcart

2.8.1 Flowchart

Adalah penyajian yang sistematis tentang proses dan logika dari kegiatan

penanganan informasi atau penggambaran secara grafik dari langkah-langkah dan

urut-urutan prosedur dari suatu program. Flowchart menolong analis dan

programmer untuk memecahkan masalah kedalam segmen-segmen yang lebih

kecil dan menolong dalam menganalisis alternatif-alternatif lain dalam

pengoperasian. (Anharku, 2009:1)

2.8.2 System flowchart

Adalah urutan proses dalam system dengan menunjukkan alat media input,

output serta jenis media penyimpanan dalam proses pengolahan data. (Aharku,

2009:1)

Page 23: Bab II Landasan Teori

30

Pedoman-Pedoman Dalam Membuat Flowchart

Jika seorang analis dan programmer akan membuat flowchart, ada

beberapa petunjuk yang harus diperhatikan, seperti :

1. Flowchart digambarkan dari halaman atas ke bawah dan dari kiri ke kanan.

2. Aktivitas yang digambarkan harus didefinisikan secara hati-hati dan definisi

ini harus dapat dimengerti oleh pembacanya.

3. Kapan aktivitas dimulai dan berakhir harus ditentukan secara jelas.

4. Setiap langkah dari aktivitas harus diuraikan dengan menggunakan deskripsi

kata kerja, misalkan Melakukan penggandaan diri.

5. Setiap langkah dari aktivitas harus berada pada urutan yang benar.

6. Lingkup dan range dari aktifitas yang sedang digambarkan harus ditelusuri

dengan hati-hati. Percabangan-percabangan yang memotong aktivitas yang

sedang digambarkan tidak perlu digambarkan pada flowchart yang sama.

Simbol konektor harus digunakan dan percabangannya diletakan pada

halaman yang terpisah atau hilangkan seluruhnya bila percabangannya tidak

berkaitan dengan sistem.

7. Menggunakan simbol-simbol flowchart yang standar.

(Anharku, 2009:1)

Simbol – simbol Flowchart

Dalam membuat system flowchart terdiri dari beberapa simbol-simbol

yang mana simbol-simbol ini saling berhubungan satu sama lainnya. Adapun

Page 24: Bab II Landasan Teori

31

simbol-simbol tersebut diantara lain seperti yang terdapat pada tabel 2.1 dibawah

ini.

Table 2.1. Simbol-simbol Flowchart Sistem

No Simbol Keterangan Fungsi

1 Terminator Pemulaan atau akhir dari program.

2 Garis Alir

(Flow Line)

Arah aliran program

3 Preparation Proses inisiasi atau pemberian harga awal.

Tabel 2.1 Lanjutan

No Simbol Keterangan Fungsi

4 Proses Proses perhitungan atau

proses pengolahan data.

Page 25: Bab II Landasan Teori

32

5 Input/output data Proses input atau output

data, parameter,

informasi

6 Predefined Process (Sub Program) Permulaan sub program

atau proses menjalankan

sub program.

7 Decision Perbandingan pernyataan,

penyeleksian data yang

memberikan pilihan

untuk langkah

selanjutnya.

8 On page connector Penghubung bagian-

bagian flowchart yang

berada pada satu

halaman.

9 Off page connector Penghubung bagian-

bagian flowchart yang

berada pada halaman

yang berbeda.

Page 26: Bab II Landasan Teori

33

(sumber: anharku, 2009:2)