cas-gatra-7406030047-id
TRANSCRIPT
PROYEK AKHIR
IMPLEMENTASI CENTRAL AUTHENTICATION SERVICE PADA
EEPIS NETWORK
Gatra Wikan Arminda
7406 030 047
Dosen Pembimbing :
Idris Winarno, S.ST , M.Kom.
NIP. 198203082008121001
JURUSAN TEKNIK INFORMATIKA
POLITEKNIK ELEKTRONIKA NEGERI SURABAYA
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2009
PROYEK AKHIR
IMPLEMENTASI CENTRAL AUTHENTICATION SERVICE PADA
EEPIS NETWORK
Gatra Wikan Arminda
7406 030 047
Dosen Pembimbing :
Idris Winarno, S.ST, MKom.
NIP. 198203082008121001
JURUSAN TEKNIK INFORMATIKA
POLITEKNIK ELEKTRONIKA NEGERI SURABAYA
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2009
IMPLEMENTASI CENTRAL AUTHENTICATION SERVICE PADA EEPIS NETWORK
Oleh:
Gatra Wikan Arminda NRP. 7406030047
Proyek akhir ini diajukan sebagai salah satu syarat akademik
untuk memperoleh gelar Ahli Madya (A.Md.) di
Politeknik Elektronika Negeri Surabaya Institut Teknologi Sepuluh Nopember Surabaya
Surabaya, Agustus 2009
Disetujui oleh: Tim Penguji Dosen Pembimbing
Setiawardhana, ST NIP. 197708242005011001
Idris Winarno, S.ST, M.Kom NIP.198203082008121001
Rengga Asmara, S.Kom NIP. 198105082005011002
Rizky Yuniar Hakkun, S.Kom NIP.198106222008121003
Mengetahui,
Ketua Jurusan Teknik Informatika
Arna Fariza, S.Kom, M.Kom. NIP. 197107081999032001
ABSTRAK Keuniversalan protokol http telah banyak menarik minat
dari para pengembang perangkat lunak untuk membuat aplikasi berdasarkan protokol ini. Permasalahan yang timbul dengan banyaknya aplikasi adalah proses otentikasi pada masing-masing aplikasi. Pada saat ini, sebagian besar aplikasi masih menggunakan system otentikasi yang terpisah untuk masing-masing aplikasi.
Solusi dari permasalahan ini adalah Sigle Sign On. Dari sekian banyak aplikasi Single Sign On yang ada saat ini, pada proyek akhir ini digunakan aplikasi CAS (Central Authentication System) sebagai aplikasi Single Sign On dan LDAP untuk basis data pengguna untuk diterapkan pada jaringan PENS-ITS. Layanan yang diintegrasikan pada proyek akhir ini adalah mail server, proxy server dan aplikasi-aplikasi yang berbasis web.
Untuk pengembangan ke depan diharapkan CAS dapat menggantikan semua system otentikasi yang berjalan pada jaringan PENS-ITS, baik untuk aplikasi yang berbasis web maupun yang tidak memiliki antarmuka web.
Kata kunci: CAS, LDAP, Single Sign On, Otentikasi
ABSTRACT
Universality of http protocol has been interest from software developers to create applications based on this protocol. The problems that arise with the number of applications is a process of authentication for each application. At this time, most applications still use a separate authentication system for each application.
Solution of this problem is Sigle Sign On. From many Single Sign On application that is at this time, at the final project is used CAS (Central Authentication System) as a Single Sign On application and LDAP for the user databases to applied on PENS-ITS Network. Services that are integrated at the end of this project is the mail server, proxy server and full web-based application.
For future development, CAS can be expected to replace all authentication method that are running on the PENS-ITS network, both for web based applications or applications that are not web-based.
Keywords: CAS, LDAP, Single Sign On, Authentication
KATA PENGANTAR
Puji dan syukur kehadirat Allah SWT atas karunia dan rahmat-Nya sehingga penulis dapat menyelesaikan proyek akhir yang berjudul “IMPLEMENTASI CENTRAL AUTHENTICATION SERVICE PADA EEPIS NETWORK” . Proyek akhir ini dibuat untuk memenuhi persyaratan mendapatkan gelar Ahli Madya (A.Md.) pada jurusan Teknologi Informasi Politeknik Elektronika Negeri Surabaya Institut Teknologi Sepuluh Nopember Surabaya. Pada kesempatan ini, tak lupa penulis ucapkan banyak terima kasih kepada:
1. Ayah dan ibunda tercinta, atas segala kasih sayang dan
pengorbanan yang diberikan kepada penulis. 2. Keluarga besarku yang tidak pernah lelah memberi semangat,
cinta, dan dukungan. 3. Bapak Ir. Dadet Pramadihanto, M.Eng, Ph.D, selaku Direktur
Politeknik Elektronika Negeri Surabaya Institut Teknologi Sepuluh Nopember.
4. Ibu Arna Fariza, M.Kom., selaku Ketua Jurusan Teknologi Informasi.
5. Bapak Idris Winarno, S.ST., selaku pembimbing yang telah banyak memberikan masukan kepada penulis.
6. Bapak, Ibu dosen dan karyawan PENS-ITS. 7. Buat teman-teman seperjuangan kelas d3 it b semoga
kebersamaan kita manjadi kenangan yang tak terlupakan. 8. Kepada Pak Nonot, Pak Dhoto, Pak Idris, Pak Udin, Pak Amang
dan Pak Safrodin selaku petinggi UPT Jarkom PENS-ITS. 9. Kepada Pak Isbat dan Pak Idris selaku penghuni Lab Jarkom. 10. Untuk ENT Crew’s Thanks 4 All ☺. 11. Untuk ngikuw yang selalu menemani dan membantuku selama
mengerjakan proyek akhir ini “makasih iyah :-*”
Penulis menyadari bahwa apa yang telah penulis lakukan dalam proyek akhir ini masih jauh dari sempurna. Semua saran, kritik, serta diskusi untuk pengembangan lebih lanjut sangat penulis harapkan. Penulis hanya bisa berharap semoga proyek akhir ini bermanfaat bagi para pembaca terutama bagi almamater.
Surabaya, Agustus 2009
Penulis
DAFTAR ISI HALAMAN JUDUL ..................................................................... i HALAMAN PENGESAHAN....................................................... ii ABSTRAK ..................................................................................... iii ABSTRACT .................................................................................. iv KATA PENGANTAR .................................................................. v DAFTAR ISI ................................................................................. vi DAFTAR GAMBAR .................................................................... viii DAFTAR SKRIP .......................................................................... x BAB I : PENDAHULUAN ....................................................... 1
1.1 Latar Belakang ..................................................... 1 1.2 Perumusan Masalah ............................................. 3 1.3 Batasan Masalah .................................................. 3 1.4 Kontribusi Proyek Akhir...................................... 3 1.5 Metodologi .......................................................... 3 1.6 Sistematika Peembahasan .................................... 6
BAB II : TEORI PENUNJANG ............................................... 7 2.1 CAS Server .......................................................... 7 2.2 Pustaka Klien ....................................................... 9 2.3 LDAP ................................................................... 9
2.3.1 Struktur Direktori LDAP .......................... 10 2.3.2 Operasi LDAP .......................................... 10
2.3.2.1 Pengertian TLS .......................... 11 2.3.2.2 BIND (Otentikasi) ...................... 11 2.3.2.3 Mencari dan Mencocokan Data .. 11 2.3.2.4 UNBIND .................................... 12
2.4 Squirrelmail ......................................................... 12 2.5 Wordpress ............................................................ 13 2.6 Moodle ................................................................. 13
BAB III : PERENCANAAN DAN PEMBUATAN PERANGKAT LUNAK ............................................. 15 3.1 Pendahuluan......................................................... 15 3.2 Perangkat Lunak .................................................. 15 3.3 Konfigurasi Server Otentikasi ............................. 16
3.3.1 Instalasi Tomcat ....................................... 16 3.3.2 Instalasi OpenLDAP ................................. 18 3.3.3 Instalasi Apache dan PHP ........................ 24 3.3.4 Instalasi Server CAS ................................ 28
3.4 Integrasi Klien ..................................................... 30 3.4.1 Pustaka phpCAS ....................................... 30
3.4.1.1 Pustaka phpCAS::client ............. 30 3.4.1.2 Pustaka phpCAS::proxy ............. 32
3.4.2 Pustaka pam_cas....................................... 33 3.4.3 Integrasi Pada Aplikasi ............................. 34
3.4.3.1 Integrasi Dengan Squirrelmail ... 35 3.4.3.2 Integrasi Dengan Wordpress ...... 37 3.4.3.2 Integrasi Dengan Moodle ........... 40
BAB IV : PENGUJIAN DAN ANALISA .................................. 49 4.1 Pengujian Dan Analisa Server LDAP .................. 49 4.2 Pengujian Analisa CAS Server ............................ 50 4.3 Pengujian Analisa Pustaka Klien ......................... 52 4.4 Pengujian Analisa Integrasi Layanan .................. 55
BAB V : PENUTUP ................................................................... 63 5.1 Kesimpulan .......................................................... 63 5.2 Saran .................................................................... 63
DAFTAR PUSTAKA.................................................................... 65 LAMPIRAN .................................................................................. 66 TENTANG PENULIS .................................................................. 70
DAFTAR GAMBAR
Gambar 1.1 Prinsip kerja Sigle Sign On .................................... 2 Gambar 1.2 Tampilan pertama pada CAS server ..................... 5 Gambar 1.3 Otentikasi berhasil ................................................. 5 Gambar 2.1 Aplikasi terpasang CAS ........................................ 7 Gambar 3.1 Proses otentikasi pada browser ............................. 15 Gambar 3.2 Tomcat terinstall ................................................... 17 Gambar 3.3 LDAP berjalan dengan baik .................................. 19 Gambar 3.4 Cpu terinstall ......................................................... 21 Gambar 3.5 phpLDAPadmin terinstall ..................................... 22 Gambar 3.6 Tampilan login phpLDAPadmin ........................... 23 Gambar 3.7 Tampilan halaman administrasi phpLDAPadmin . 23 Gambar 3.8 Proses penambahan pengguna ............................... 24 Gambar 3.9 PHP dan apache terinstall ...................................... 25 Gambar 3.10 CAS terinstall ........................................................ 30 Gambar 3.12 Webmail Terinstall ................................................ 35 Gambar 3.13 Proses instalasi wordpress ..................................... 38 Gambar 3.14 Konfigurasi judul blog .......................................... 39 Gambar 3.15 Konfigurasi kata sandi admin ................................ 39 Gambar 3.16 Pilihan direktori moodle ......................................... 41 Gambar 3.17 Konfigurasi basisdata moodle ................................ 42 Gambar 3.18 Komponen moodle ................................................. 42 Gambar 3.19 Konfigurasi pengguna admin moodle .................... 43 Gambar 3.20 Halaman login bawaan moodle .............................. 44 Gambar 3.21 Halaman administrasi moodle ................................ 44 Gambar 3.22 Halaman administrasi CAS pada moodle ............... 45 Gambar 3.23 Tampilan basisdata moodle pada phpMyAdmin .... 46 Gambar 3.24 Tampilan tabel mdl_user pada phpMyAdmin ........ 46 Gambar 4.1 Hasil pencarian LDAP .......................................... 49 Gambar 4.2 Kesalahan pada kata sandi atau nama pengguna ... 50 Gambar 4.3 Kesalahan kata sandi tidak diisi ............................ 51 Gambar 4.4 Otentikasi berhasil ................................................. 51 Gambar 4.5 Otentikasi phpCas berhasil .................................... 53 Gambar 4.6 Halaman logout ..................................................... 54 Gambar 4.7 Kesalahan karena sertifikat ssl tidak terpercaya ..... 54 Gambar 4.8 Halaman login webmail tanpa cas ......................... 55 Gambar 4.9 Halaman login awal wordpress tanpa cas ............. 56 Gambar 4.10 Halaman login awal moodle tanpa cas .................. 56 Gambar 4.11 Halaman login webmail dengan cas ...................... 57 Gambar 4.12 Halaman login wordpress dengan cas ................... 57
Gambar 4.13 Halaman login moodle dengan cas ....................... 58 Gambar 4.14 Pengguna berhasil login ke dalam webmail .......... 59 Gambar 4.15 Pengguna tidak terdaftar pada wordpress .............. 59 Gambar 4.16 Pengguna berhasil login ke halaman administrasi 60 Gambar 4.17 Halaman registrasi pengguna baru ........................ 60 Gambar 4.18 Halaman administrasi pengguna ........................... 61
DAFTAR SKRIP
Skrip 2.1 Struktur direktori LDAP ............................................. 10 Skrip 3.1 Parameter tomcat ....................................................... 16 Skrip 3.2 Penambahan hak sebagai administrator ..................... 17 Skrip 3.3 Konfigurasi https pada tomcat .................................... 18 Skrip 3.4 Proses instalasi OpenLDAP........................................ 18 Skrip 3.5 Parameter migrationtools ............................................ 19 Skrip 3.6 Isi people_group.ldif ................................................... 20 Skrip 3.7 Kofigurasi cpu ............................................................ 22 Skrip 3.8 Skrip phpinfo ............................................................. 25 Skrip 3.9 Konfigurasi ports.conf ............................................... 26 Skrip 3.10 Konfigurasi virtual host untuk https .......................... 27 Skrip 3.11 Konfigurasi workers ................................................... 28 Skrip 3.12 Konfigurasi mod_jk .................................................... 28 Skrip 3.13 Konfigurasi dependensi pada cas server ..................... 29 Skrip 3.14 Konfigurasi ldap handler pada cas server ................... 29 Skrip 3.15 Konfigurasi ldap handler pada cas server ................... 31 Skrip 3.16 Pustaka phpCas::client ................................................ 31 Skrip 3.17 Pustaka phpCas::proxy ............................................... 32 Skrip 3.18 Konfigurasi modul pam .............................................. 34 Skrip 3.19 Konfigurasi pam_cas .................................................. 34 Skrip 3.20 Konfigurasi plugin squirrelmail .................................. 36 Skrip 3.21 Konfigurasi wp-cas ..................................................... 40 Skrip 4.1 Skrip dasar phpCas .................................................... 52
BAB 1 PENDAHULUAN
1.1 LATAR BELAKANG
Keuniversalan dari protokol HTTP telah menyebabkan banyak pengembang meyukai pengembangan suatu aplikasi dengan menggunakan protokol ini. Hal ini dapat dilihat pada perkembangan aplikasi pada akhir-akhir ini yang banyak menggunakan web based pada bagian antar muka dan juga sebagian besar dari aplikasi tersebut membutuh kan otentikasi untuk masuk kedalam sistem administrasinya[1].
Salah satu metode otentikasi yang sering digunakan saat ini adalah LDAP[3], dengan LDAP kita bisa mempermudah pengguna dalam pemakain kata sandi, dimana pengguna hanya mengingat satu kata sandi saja untuk banyak aplikasi. Akan tetapi pengguna tetap harus mengisikan nama dan kata sandi pada saat akan melakukan otentikasi pada masing-masing aplikasi. Metode LDAP ini juga memiliki beberapa kelemahan, antara lain [1]:
• Otentikasi berulang, pengguna masih harus memberikan nama pengguna dan kata sandi ke masing-masing aplikasi.
• Kemanan, dikarenkan pada saat pengguna akan login ke dalam aplikasi harus memasukkan nama pengguna dan kata sandi maka semakin banyak terdapat form masukkan nama pengguna dan kata sandi maka pencurian kata sandi sangat mungkin terjadi.
Untuk mengatasi kelemahan-kelemahan yang ada di atas maka dikembangkan suatu mekanisme otentikasi yang baru yang disebut Single Sign On (SSO)[1], di mana metode yang digunakan oleh SSO ini adalah [1]:
• Otentikasi tersentral, pada suatu server tunggal, yang merupakan satu-satunya mesin yang mempunyai halaman login melewati protokol yang terenkripsi.
• Penggunaan HTTP Redirection dari aplikasi ke server otentikasi untuk pengguna yang belum terotentikasi dan kembali ke aplikasi ketika pengguna telah terotentikasi.
• Informasi tentang pengguna di kirimkan dari server otentikasi ke aplikasi menggunakan cookies atau parameter CGI.
Pada gambar 1.1 di bawah diilustrasikan perbedaan antar aplikasi yang terintegrasi dengan CAS dan aplikasi yang tidak terintegrasi dengan CAS. Pada aplikasi yang terintegrasi dengan
CAS otentikasi ditangani oleh sebuah layanan tersendiri terpisah dari aplikasi. Aplikasi yang memanfaatkan layanan ini menggunakan tiket yang dihasilkan oleh layanan otentikasi untuk melakukan otentikasi.
Gambar 1.1 . Prinsip kerja dari Single Sign On
Dengan metode otentikasi tersentral ini diharapkan kekurangan-
kekurangan pada metode-metode otentikasi lainnya dapat teratasi dengan baik. Perangkat lunak SSO yang akan digunakan pada proyek akhir ini ada Central Authentication Service (CAS) yang dikembangkan oleh Yale University dan telah berhasil diimplentasikan oleh banyak universitas-universitas terkemuka lainnya[4]. Pada proyek akhir ini CAS akan diubah sesuaikan dengan kondisi dan aplikasi yang berjalan pada jaringan PENS-ITS.
1.2 PERUMUSAN MASALAH Berdasarkan uraian tersebut di atas, dalam pengerjaan proyek
akhir ini timbul beberapa masalah diantaranya adalah: 1. Bagaimana menyesuaikan aplikasi CAS yang telah ada agar
berjalan dengan lancar pada jaringan PENS-ITS. 2. Otentikasi pada aplikasi yang tidak memiliki antarmuka
web. 3. Pembatasan jumlah maksimal login user pada suatu aplikasi.
1.3 BATASAN MASALAH Batasan masalah dari proyek akhir ini adalah 1. Aplikasi CAS ini hanya akan diimplemantasikan pada
jaringan internal PENS-ITS. 2. Otentikasi pada aplikasi yang tidak memiliki antarmuka web
hanya diterapkan pada aplikasi mail server. 3. Basisdata pengguna yang akan digunakan pada tugas akhir
ini adalah LDAP[3].
1.4 KONTRIBUSI PROYEK AKHIR Proyek Akhir ini nantinya diharapkan dapat menggantikan
sistem otentikasi yang telah berjalan selama ini pada jaringan PENS-ITS. Di dalam suatu sistem yang terdapat banyak aplikasi yang memerlukan otentikasi tentu sistem ini akan sangat berguna untuk membantu menyederhanakan dan mengamankan proses otentikasi tersebut.
1.5 METODOLOGI
Aplikasi CAS ini terdiri dari beberapa bagian yang saling bekerja sama untuk melaksanakan otentikasi tersentral. Bagian-bagian tersebut antara lain [1]:
1. CAS Server Tempat dimana otentikasi di proses. Mesin inilah yang
mengetahui seluruh nama pengguna dan kata sandi yang diperlukan untuk otentikasi. Mesin ini mempunyai dua fungsi utama :
• Mengotentikasi pengguna. • Memberikan dan mensertifikasi identitas dari
pengguna yang terotentikasi kepada CAS client. 2. Web Browser
Web Browser harus memenuhi persayratan untuk dapat mendapatkan manfaat yang ada pada CAS. Persyaratan tersebut antara lain :
• Mempunyai mesin enkripsi sendiri yang bisa digunakan pada protokol https.
• Dapat mengeksekusi HTTP Redirections (mengakses URL yang diberikan oleh header Location) dan mendukung javascript.
• Menyimpan cookie, seperti yang didefinisikan diatas, cookie harus dikirim ke mesin yang meminta.
3. CAS Client Aplikasi web yang dilengkapi dengan pustaka client
CAS atau webserver yang menggunakan mod_cas. Kelengkapan client antar lain :
• Pustaka client, yang sebagian besar adalah bahasa pemrograman web yang banyak digunakan.
• Modul web server Apache, modul ini digunakan untuk jika web yang akan diotentikasi berisi konten statis.
• PAM modul, digunakan untuk melakukan otentikasi pada level sistem.
Otentikasi pada CAS server dimulai jika ada pengguna yang belum terotentikasi atau pun pengguna yang masa otentikasinya sudah tidak berlaku maka pengguna tersebut akan diarahkan ke CAS server dimana terdapat halaman untuk login ke dalam sistem seperti terlihat pada gambar 1.2.
Gambar 1.2. Tampilan pertama pada CAS server
Jika pengguna memasukkan netId dan kata sandi yang benar
maka server akan mengirikan cookie yang disebut TGC (Ticket Granting Cookie) ke web browser seperti terlihat pada gambar 1.2.
Gambar 1.3. Otentikasi berhasil
TGC adalah semacam “ijin” yang diberikan oleh CAS server. Masa hidup dari TGC ini terbatas, biasanya beberapa jam. TGC ini adalah jalan untuk bagi web browser untuk memperoleh tiket (untuk digunakan pada CAS client) dari CAS server, tanpa membutuhkan otentikasi ulang pada aplikasi yang bersangkutan. Cookie ini adalah private (tidak dikirimkan ke web server, tapi hanya ke CAS server), dan terlindungi (permintaan ke CAS server terenkripsi). Tiket yang dijalankan oleh CAS server ini bersifat kabur (tidak mengandung informasi pribadi) dan hanya merupakan sesi identifikasi antara web browser dan CAS server.
1.4 SISTEMATIKA PEMBAHASAN
Buku laporan proyek akhir ini terdiri atas 5 bab. Dimana setiap bab memiliki keterkaitan, yaitu:
BAB 1: Memberikan latar belakang tentang permasalahan, tujuan, masalah dan batasan masalah serta metodolgi yang dibahas dalam proyek akhir ini.
BAB 2: Memberikan dasar teori untuk menunjang penyelesaian masalah dalam proyek akhir ini. Teori dasar yang diberikan meliputi: Pengertian dasar Single Sign On, LDAP sebagai basis data pengguna serta aplikasi-aplikasi yang diintegrasikan pada CAS.
BAB 3: Berisi tentang penjelasan mengenai proses perancangan dan penyesuaian aplikasi CAS agar dapat berjalan dengan baik pada jaringan PENS-ITS.
BAB 4: Melakukan pengujian aplikasi dengan membandingkan parameter-parameter sebelum dan sesudah menggunakan CAS.
BAB 5: Berisi tentang kesimpulan proyek akhir yang dibuat serta saran-saran untuk pengembangan selanjutnya.
BAB 2 TEORI PENUNJANG
2.1 CAS SERVER
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 kemanan, fitur proxying, fleksibilitas, ketahanan dan pustaka client yang bermacam-macam[1]. Gambar 2.1 menggambarkan proses otentikasi dan perjalanan user dan kata sandi pada aplikasi tanpa CAS dan aplikasi yang terintegrasi dengan CAS. Pada aplikasi tanpa CAS proses otentikasi terjadi pada masing-masing aplikasi dan tiap aplikasi mengakses basisdata pengguna dimana proses ini sangat rawan terhadap penyadapan data login. Sedangkan pada aplikasi dengan CAS proses otentikasi dan pengaksesan basisdata pengguna hanya berjalan pada server otentikasi. Aplikasi memanfaatkan tiket yang dihasilakan server otentikasi untuk melakukan otentikasi terhadap pengguna.
Gambar 2.1. Aplikasi yang terpasang CAS
Kelebihan-kelebihan yang terpasang pada CAS antara lain :
1. Keamanan Keamanan diimplementasikan dengan cara: • Kata sandi hanya dikirim dari browser ke
server otentikasi dimana proses pengiriman selalu melewati jalur yang terenkripsi.
• Otentikasi ulang tidak terlihat pada sisi pengguna, yang memastikan bahwa cookie
yang diterima adalah cookie yang unik, cookie ini disebut ‘Ticket Granting Cookie’. Cookie ini tidak mengandung informasi pribadi dari pengguna yang melakukan proses otentikasi, terlindungi dengan protokol HTTPS dan hanya dapat dibaca oleh server otentikasi.
• Tiket yang telah dikeluarkan oleh server otentikasi dikirim ke aplikasi yang meminta otentikasi melalui web browser dan akhirnya divalidasi oleh server otentikasi, sehingga dengan mekanisme ini aplikasi tidak pernah meminta data nama pengguna dan kata sandi kepada pengguna aplikasi tersebut.
2. Otentikasi Proxy Mekanisme SSO klasik bergantung pada
komunikasi antara browser dan aplikasi yang menyebabkan instalasi multi-tier tidak bisa dijalankan pada aplikasi yang membutuhkan layanan back-end untuk otentikasi.
CAS versi 2.0 dapat mengatassi masalah ini dengan menwarkan 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. Fleklsibilitas
Paket yang ditawarkan oleh pengembang CAS adalah implementasi lengkap dari protokol otentikasi, akan tetapi otentikasi itu sendiri (pengelolaan basis data pengguna dll) harus dilakukan oleh administrator. Pada tugas akhir ini dicoba untuk membuat penghubung untuk aplikasi yang tidak mempunyai antar muka otentikasi web. CAS juga menyediakan berbagai handler untuk metode otentikasi, antara lain karberos, ldap dan active directory.
2.2 PUSTAKA KLIEN Kode dari protokol dasar dapat dengan mudah ditulis pada sisi
klien. Pustaka tambahan tersedia untuk bahasa Perl, Java, ASP dan
PL/SQL. Juga tersedia pustaka untuk PHP. Semua pustaka tersebut memberikan fleksibilitas yang baik untuk memasukkan CAS pada suatu aplikasi hanya dengan menambahkan beberapa baris kode[1]. Juga tersedia modul (mod_cas) untuk otentikasi pada konten statis pada Apache web server. Modul PAM tersedia untuk otentikasi aplikasi pada level rendah yang tidak memiliki antar muka web.
Aplikasi CAS yang diterapkan pada universitas-universitas di Amerika Serikat menggunakan LDAP atau Karberos untuk metode otentikasinya. Sebagai contoh pada Yale Univeristy dimana CAS pertama kali dibuat dan diterapkan menggunakan Karberos sebagai metode otentikasi[4]. Metode yang akan dipakai pada proyek akhir ini adalah metode otentikasi dengan LDAP.
2.3 LDAP
LDAP merupakan kependekan dari Lightweight Directory Access Protocol adalah suatu aplikasi dan protokol untuk query dan memodifikasi direktori layanan yang berjalan pada protokol TCP/IP. Sebuah direktori adalah satu set obyek dengan atribut yang diselenggarakan dengan cara logis dan hirarkis. 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 dengannya. Pohon direktori LDAP berisi daftar politik, geografis, dan/atau batas-batas organisasi, tergantung pada model dipilih. Penerapan LDAP pada saat ini cenderung menggunakan Domain Name System (DNS) untuk struktur di tingkat paling atas dari hirarki. Versi terakhir dari LDAP adalah LDAPv3 yang ditentukan oleh Internet Engineering Task Force (IETF) sebagai RFC 4510.
2.3.1 STRUKTUR DIREKTORI LDAP
Struktur direktori LDAP mengikuti struktur direktori dari X.500 edisi 1993.
Isi dari struktur direktori jika direpresentasikan dengan format LDIF terlihat seperti dibawah ini :
dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232 mail: [email protected] manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top
Skrip 2.1. Struktur direktori LDAP
Dimana dn merupakan nama dari kumpulan data diatas, cn adalah common name, sn adalah surname, dc adalah domain component.
2.3.2 OPERASI LDAP
Klien mengirimkan permintaan ke server berupa ID pesan dan server merespon dengan ID yang sama. Respon dapat termasuk kode-kode numerik yang dapat diartikan sebagai kueri sukses, error ataupun pesan-pesan lainnya. Proses lengkap dari operasi LDAP ini adalah :
• Pengertian TLS. • Bind (otentikasi). • Mencari dan mencocokan data. • Unbind.
2.3.2.1 PENGERTIAN TLS
TLS (Transport Layer Security);turunan dari SSL; digunakan untuk melindungi data dari kemungkinan proses penyadapan. Pada saat proses negosiasi server mengirimkan sertifikat X.509 untuk membuktikan identitasnya, begitu juga klien. Setelah identitas masing-masing diketahui klien dapat 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.
2.3.2.2 BIND (OTENTIKASI)
Operasi bind akan mengotentikasikan klien 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.
2.3.2.3 MENCARI DAN MENCOCOKAN DATA
Operasi ini bertujuan untuk mencari data dan membaca data di 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 di bawah baseObject. Bisa berupa BaseObject (nama, alamat), singleLevel (satu data tepat dibawah baseObject), atau wholeSubtree (semua data yang ada pada DN).
2.3.2.4 UNBIND
Operasi unbind berfungsi untuk meninggalkan semua operasi dan menutup koneksi ke server penyedia layanan LDAP. Operasi ini tidak memiliki respon.
Pengguna dapat membatalkan sesi dengan hanya menutup koneksi, akan tetapi untuk lebih aman pengguna 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 pengguna lainnya;, membebaskan resource yang dipakai oleh koneksi dan juga memerintahkan server untuk membatalkan operasi yang bias dibatalkan dan tidak akan mengirimkan respon untuk operasi yang tidak dapat dibatalkan. 2.4 SQUIRRELMAIL
Squirrelmail adalah aplikasi surat elektronik yang berbasis web. Dikembangkan pertama oleh Nathan dan Luke Ehresman dan dirilis pertama kali pada 30 Januari 2001. Ditulis dengan bahasa PHP sehingga dapat berjalan pada hampir semua webserver selama mesin webserver dapat mengakses IMAP dan SMTP server.
Keluaran squirrelmail berupa html versi 4.0 sehingga kompatibel dengan sebagian besar browser yang ada saat ini. Squirrelmail menggunakan sistem plugin untuk menambah fitur-fitur yang belum ada pada program dasar. Pada saat ini ada sekitar 200 plugin yang terdaftar pada situs squirrelmail. Saat ini squirrelmail juga telah mendukung lebih dari 50 bahasa termasuk di dalamnya
adalah bahasa Indonesia. Untuk pengembangan kedepan pengembang squirrelmail berencana menambahkan beberapa fungsionalitas antara lain AJAX dll.
2.5 WORDPRESS
Wordpress adalah aplikasi blog dan content management system yang ditulis dengan 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 menggunakan mesin yang dinamakan Wordpress Multi User, WPMU menambahkan delapan tabel baru untuk tiap blog pada basisdata utama wordpress. 2.6 MOODLE
Moodle adalah aplikasi e-learning yang dikembangkan oleh Moodle company yang berbasis di Perth, Australia. Pertama kali dirilis pada 1999 dan mulai menggunakan arsitektur saat ini mulai tahun 2001. Moodle dapat berjalan pada hampir semua sistem yang mendukung php dan basisdata, basisdata yang didukung oleh moodle sampai dengan versi 1.7 adalah mysql dan postgresql. Seperti halnya squirrelmail, moodle juga menggunakan plugin untuk menambahkan fitur-fitur yang tidak tersedia pada program pokok.
Halaman Ini Sengaja Dikosongkan
BAB III PERENCANAAN DAN PEMBUATAN
PERANGKAT LUNAK
3.1 PENDAHULUAN Pada perencanaan dan pembuatan perangkat lunak ini akan
dibahas tentang proses instalasi dan penyesuaian perangkat lunak agar dapat berjalan pada jaringan PENS-ITS. Pengguna yang belum terotentikasi akan diarahkan ke halaman otentikasi yang berada pada server otentikasi. Halaman otentikasi ini hanya berjalan pada mode https untuk memastikan semua proses otentikasi aman. Pada gambar 3.1 diilustrasikan proses otentikasi antara web browser di sisi klien dan server CAS sebagai server otentikasi.Pengguna akan diotentikasikan berdasarkan database ldap, setelah pengguna terotentikasi maka aplikasi CAS akan mengirimkan tiket ke aplikasi yang membutuhkan otentikasi.
Gambar 3.1. Proses otentikasi pada browser
3.2 PERANGKAT LUNAK Pada proyek akhir kali ini, digunakan perangkat lunak single
sign on CAS (Central Authentication Service) yang di kembangkan oleh Jasig. Dibandingkan dengan aplikasi single sign on lain seperti Microsoft .NET Passport dan Sun One Identity server yang berbayar, CAS ini merupakan sebuah sistem sigle sign on yang gratis dan open source serta telah banyak digunakan oleh institusi-institusi pendidikan di banyak negara[4]. Server CAS terdiri dari kumpulan Java Servlet dan Java Server Pages sehingga dalam deployment server harus menggunakan servlet container. Pada tugas akhir ini servlet container yang digunakan adalah Tomcat 5.5, sedangkan untuk basisdata pengguna digunakan OpenLDAP. Untuk integrasi dengan aplikasi yang berbasis php digunakan Apache 2.2.3 dan PHP
5. Aplikasi klien yang diintegrasikan dengan layanan CAS adalah Wordpress, Moodle dan Squirrelmail.
3.3 KONFIGURASI SERVER OTENTIKASI
Sistem dilengkapi dengan paket tomcat5.5 sebagai servlet container, openLDAP sebagai basisdata pengguna apache2 dengan mod_jk dan mod_ssl serta php5 untuk integrasi dengan klien yang berbasis web.
3.3.1 INSTALASI TOMCAT
Untuk servlet container pada proyek akhir ini digunakan apache tomcat. Tomcat merupakan servlet container yang umum dipakai pada banyak system. Untuk menginstal tomcat diperlukan java development kit untuk compiling maupun running program-program berbasis java.
Langkah-langkah instalasi dan konfigurasi tomcat dengan cara mengetikkan perintah-perintah dibawah ini pada shell :
# apt-get install tomcat5 tomcat5-webapps tomcat5-admin-webapps
Perintah diatas akan menginstall tomcat beserta jdk yang dibutuhkan untuk menjalankan CAS server. Setelah tomcat terinstall edit file /etc/default/tomcat 5.5 dan sesuaikan parameter seperti skrip 3.1 di bawah ini :
Skrip 3.1. Parameter Tomcat
Baris pertama adalah konfigurasi letak java development kit
yang terinstall pada komputer server. Baris kedua adalah konfigurasi java security manager, konfigurasi ini harus dimatikan agar proses deployment server CAS berjalan lancar.
Setelah mengkonfigurasi tomcat, agar konfigurasi yang baru dijalankan oleh tomcat maka tomcat perlu direstart.
# /etc/init.d/tomcat5.5 restart Uji coba pada browser dengan mengetikkan
http://namaserver:8180, jika pada browser muncul seperti gambar 3.2 maka instalasi tomcat berhasil. Edit file /var/lib/tomcat5/conf/tomcat-users.xml seperti skrip 3.2 dibawah untuk menambahkan hak sebagai admin pada pengguna tomcat :
Skrip 3.2. Penambahan hak sebagai administrator
Gambar 3.2. Tomcat terinstall
Dikarenakan CAS server membutuhkan mode https untuk
berjalan dengan baik maka tomcat yang kita gunakan harus bisa berjalan pada mode https. Tambahkan konfigurasi https pada file /etc/tomcat5.5/server.xml seperti terlihat pada skrip 3.3 di bawah :
Skrip 3.3. Konfigurasi https pada tomcat
3.3.2 INSTALASI OpenLDAP SEBAGAI LDAP SERVER
Untuk database pengguna pada proyek akhir ini digunakan OpenLDAP. LDAP digunakan karena mudah untuk dikonfigurasi dan di integrasikan ke banyak aplikasi.
Langkah-langkah instalasi OpenLDAP seperti dibawah ini : # apt-get install slapd ldap-utils
migrationtools Pada saat instalasi installer akan menampilkan berapa form
isian yang harus kita isi, pada skrip 3.4 di bawah ini merupakan contoh dari form :
Omit OpenLDAP server configuration? ... No DNS domain name: ... <nama.domain> Name of your organization: ... Whatever & Co Admin Password: XXXXX Confirm Password: XXXXX OK BDB Do you want your database to be removed when slapd is purged? ... No Move old database? ... Yes Allow LDAPv2 Protocol? ... No
Skrip 3.4. Proses instalasi OpenLDAP
Cek apakah server ldap telah berjalan dengan mengetikkan perintah di bawah ini :
$ ldapsearch -x -b dc=torrent,dc=eepis-its,dc=edu
Jika tampil keluaran seperti gambar 3.3 di bawah ini berarti server ldap telah berjalan :
Gambar 3.3. LDAP berjalan dengan baik
Setelah ldap server berjalan, import nama pengguna dan kata
sandi dari basisdata pengguna sistem operasi menggunakan migrationtools.
Langkah pertama pindah direktori ke direktori tempat instalasi migrationtools :
#cd /usr/share/migrationtools/
Edit konfigurasi dari migratontools, sesuikan dengan parameter dari ldap server yang telah dikonfigurasi di atas seperti terlihat pada skrip 3.5 di bawah ini:
$DEFAULT_MAIL_DOMAIN = "torrent.eepis-its.edu"; $DEFAULT_BASE = "dc= torrent,dc= eepis-its,dc=edu";
Skrip 3.5. Parameter migrationtools
Migrasikan daftar pengguna dari sistem operasi ke format basisdata ldap :
# ./migrate_group.pl /etc/group ~/group.ldif # ./migrate_passwd.pl /etc/passwd ~/passwd.ldif Perintah di atas digunakan hanya untuk memigrasikan list
pengguna dan grup dari basisdata sistem operasi ke dalam format basisdata ldap, untuk node People dan Group pada basisdata ldap kita harus membuat sendiri file people_group.ldif dan menambahkan secara manual ke dalam basisdata ldap. Isi dari people_group.ldif adalah seperti terlihat pada skrip 3.6 di bawah ini:
dn: ou=People, dc=debuntu, dc=local ou: People objectclass: organizationalUnit dn: ou=Group, dc=debuntu, dc=local ou: Group objectclass: organizationalUnit
Skrip 3.6. Isi people_group.ldif
Setelah semua siap hasil import siap untuk dimasukkan kedalam database ldap dengan perintah dibawah ini :
# cd ~ # ldapadd -x -W -D "cn=admin,dc=torrent,dc=eepis-its,dc=edu" -f ~/people_group.ldif # ldapadd -x -W -D "cn=admin, dc=torrent,dc=eepis-its,dc=edu " -f ~/group.ldif # ldapadd -x -W -D "cn=admin,
dc=torrent,dc=eepis-its,dc=edu " -f ~/passwd.ldif Cek kembali dengan cara diatas dan pastikan user telah masuk
ke dalam database ldap. Untuk penambahan pengguna ke ldap dapat menggunakan tool
tambahan untuk mempermudah proses penambahan. Pada proyek akhir kali ini tool yang akan digunakan adalah cpu untuk tool berbasis konsol dan phpldapadmin untuk tool yang berbasis web. Untuk mengaktifkan cpu dan phpldapadmin perlu dilakukan instalasi dengan perintah :
# apt-get install cpu phpldapadmin Perintah di atas akan mencari dependensi dari cpu dan
phpldapadmin dan melakukan instalasi. Setelah proses instalasi selesai cek masing-masing tool, untuk cpu pengecekan dilakukan melalui konsol dengan mengetikkan perintah :
# cpu Apabila keluar tampilan seperti pada gambar 3.4 di bawah ini
maka cpu telah berajalan dengan baik.
Gambar 3.4. Cpu terinstall
Untuk pengecekan phpldapadmin buka browser ketikkan
http://namaserver/phpldapadmin, apabila keluar seperti pada gambar 3.5 di bawah ini maka phpldapadmin telah terinstall dengan benar.
Gambar 3.5. phpLDAPadmin terinstall
Untuk tool cpu sebelum dilakukan proses penambahan
pengguna perlu penyesuaian konfigurasi dari cpu agar sesuai dengan konfigurasi dari ldap server yang dipakai pada proyek akhir ini. Untuk file konfigurasi cpu berada pada /etc/cpu/cpu.conf, skrip 3.7 di bawah ini menunjukkan file konfigurasi dari cpu :
Skrip 3.7. Kofigurasi cpu
Setelah selesai pengkonfigurasian cpu maka penambahan pangguna dapat dilakukan dengan perintah :
# cpu useradd nama-pengguna
Untuk phpldapadmin sebelum melakukan proses penambahan pengguna diperlukan proses otentikasi seperti yang ditunjukkan pada gambar 3.6 di bawah ini :
Gambar 3.6. Tampilan login phpldapadmin
Setelah memasukkan kata sandi dari server ldap maka akan
keluar tampilan seperti gambar 3.7 di bawah ini :
Gambar 3.7. Tampilan halaman administrasi phpldapadmin Untuk proses penambahan pengguna dapat dilihat pada gambar
3.8 di bawah ini :
Gambar 3.8. Proses penambahan pengguna
Setelah ditambahkan, pengguna sudah dapat menggunakan aplikasi yang diintegrasikan ke CAS seperti moodle dan wordpress, akan tetapi pengguna baru belum bisa menggunakan aplikasi webmail. Hal ini dikarenakan pengguna belum memilik home direktori pada server. Untuk pembuatan home direktori harus dilakukan oleh administrator.
3.3.3 INSTALASI APACHE, PHP, mod_jk
Webserver dengan dukungan PHP dan mod_ssl digunakan untuk integrasi dengan klien yang berbasis php. Mod_ssl digunakan untuk menambahkan layanan https pada http server. Proses instalasi apache, php dan modul-modul pendukungnya akan dijelaskan dibawah ini.
Untuk instalasi apache dan php ketikkan perintah dibawah ini : #apt-get install apache2 openssl ssl-cert libapache2-mod-php5 php5-cli php5-common php5-cgi Untuk mengecek apakah instalasi telah berjalan dengan benar
buat file info.php dan kopikan ke direktori root dari apache. Isi dari file info.php terlihat pada skrip 3.8 di bawah ini :
Skrip 3.8 Skrip phpinfo
Program diatas akan memanggil fungsi bawaan dari php yang
menampilkan parameter-parameter dari server tempat php berjalan.Buka web browser dan ketikkan http://namaserver/info.php pada browser, jika keluar tampilan seperti gambar 3.9 maka instlasi telah berjalan dengan sukses.
Gambar 3.9. PHP dan Apache terinstall
Langkah selanjutnya adalah konfigurasi dari mod_ssl. Modul
ini dipakai untuk menyediakan layanan https pada web server apache. Untuk mengaktifkan modul tersebut ketikkan perintah :
# a2enmod ssl Perintah di atas akan membuat satu file konfigurasi baru pada
direktori /etc/apache2/site-enabled. Nama file default adalah default-ssl yang merupakan file konfigurasi virtual host untuk protokol https. Agar protokol https dapat berjalan dengan baik kita perlu menambahkan port yang akan dipakai pada file /etc/apache2/ports.conf, skrip 3.9 di bawah ini adalah contoh dari file ports.conf
Skrip 3.9. Konfigurasi ports.conf
Dari skrip 3.9 di atas terlihat bahwa apache akan mendengarkan
permintaan klien pada dua port yaitu 80 dan 443, port 80 digunakan untuk permintaan http biasa dan 443 digunakan untuk permintaan https.
Langkah selanjutnya adalah pembuatan file sertifikat untuk ssl. Pada proyek akhir kali ini tidak menggunakan file sertifikat bawaan openssl dikarenakan CAS server membutuhkan file sertifikat ssl yang ditandatangani oleh otoritas yang dipercaya seperti Verisign, Comodo CA dsb, pada proyek akhir ini digunakan sertifikat gratis dari Comodo CA. Dikarenakan gratis maka masa berlaku dari sertifikat ini hanya tiga bulan.
Langkah pertama untuk pembuatan sertifikat adalah pembuatan key yang akan digunakan untuk enkripsi dan CSR (Certificate Signing Request) yang akan dikirimkan ke otoritas penandatangan sertifikat ssl pembuatan CSR dan key dapat dilakukan dengan perintah :
# openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr Perintah di atas akan menghasilkan key dan CSR yang akan
digunakan untuk membuat sertifikat ssl. CSR tersebut akan dikirimkan ke CA(Certificate Authorithy) untuk dibuatkan sertifikat ssl.
Setelah proses di atas selesai CA akan mengirimkan file sertifikat yang telah ditandatangani file ini yang akan kita gunakan untuk protokol https. Skrip 3.10 di bawah ini adalah contoh dari file konfigurasi virtual host untuk https yang telah ditambahkan dengan file sertifikat ssl :
Skrip 3.10. Konfigurasi virtual host untuk https
Untuk memudahkan konfigurasi selanjutnya maka aplikasi tomcat akan diintegrasikan dengan apache dengan menggunakan mod_jk. Untuk menginstal mod_jk ketikkan perintah di bawah ini :
# apt-get install libapache2-mod-jk Setelah mod_jk terinstall dengan baik edit file
/etc/libapache2-mod-jk/workers.properties Sesuaikan dengan parameter yang ada pada server. Skrip 3.11
di bawah ini contoh konfigurasi dari file workers.properties :
Skrip 3.11. Konfigurasi workers
Langkah selanjutnya masukkan parameter mount point dari
tomcat yang akan kita panggil melalui apache ke dalam virtual host yang kita inginkan. Edit file konfigurasi virtual host /etc/apache2/sites-enabled/default-ssl , tambahkan baris pada skrip 3.12 ke dalam file konfigurasi :
JkMount /cas/* ajp13_worker
Skrip 3.12. Konfigurasi mod_jk
Restart apache dengan perintah : # /etc/init.d/apache2/restart Untuk pengecekan buka browser ketikkan
https://namaserver/cas, jika tampil halaman login cas maka konfigurasi telah berhasi dan url tersebut akan dipakai untuk konfigurasi CAS selanjutnya. 3.3.4 INSTALASI SERVER CAS
Server CAS terdiri dari file-file java yang harus dikompilasi dengan pustaka ant atau maven agar dapat menjadi class servlet dan dapat dijalankan pada container tomcat. Di bawah ini adalah cara instalasi server CAS.
Tambahkan dependency seperti skrip 3.13 di bawah ini pada file pom.xml pada direktori ${project.home}/cas-server-webapp/pom.xml:
Skrip 3.13. Konfigurasi dependensi pada cas server
Tambahkan ldap handler pada file
deployerConfigContext.xml pada direktori webapp. LDAP handler diletakkan antara tag <beans>………….</beans>. LDAP handler terlihat skrip 3.14 di bawah ini :
Skrip 3.14. Konfigurasi ldap handler pada cas server
Setelah selesai menambahkan dependency untuk ldap handler di
atas kompilasikan dan paketkan server CAS dengan apache maven atau pustaka ant. Ketikkan perintah dibawah ini untuk mengkompilasi CAS server :
# mvn package Maven atau ant akan mendownlod beberapa file pustaka dan
mulai mengompilasi dan memaketkan server CAS. Setelah selesai kompilasi maka pada direktori webapp akan terdapat file .war. Untuk deployment server salin file .war tersebut kedalam direktori webapps dari tomcat. Restart tomcat dan lihat hasilnya pada browser dengan mengetikkan https://namaserver:8443/cas/. Jika keluar tampilan seperti pada gambar 3.10 maka instalasi server telah berhasil.
Gambar 3.10. CAS terinstall
3.4 INTEGRASI KLIEN
Seperti yang telah dijelaskan pada bab 2 CAS dapat di integrasikan dengan berbagai macam pustaka klien. Pada proyek akhir ini pustaka klien yang digunakan adalah pam_cas dan phpCAS. Pada bagian ini akan dibahas integrasi dengan pam_cas dan phpCAS. 3.4.1 PUSTAKA phpCAS 3.4.1.1 PUSTAKA phpCAS:client
Untuk mengintegrasikan CAS dengan klien php kita perlu mengunduh terlebih dahulu pustaka untuk menghubungkan CAS server dengan klien berbasis php.Pustaka phpCAS dapat diunduh pada url http://www.ja-sig.org/downloads/cas-clients/php/1.0.1/CAS-1.0.1.tgz pada mesin linux yang digunakan pada tugas akhir kali ini dapat menggunakan perintah :
#wget http://www.jasig.org/downloads/cas-clients/php/1.0.1/CAS-1.0.1.tgz Setelah selesai mengunduh pustaka klien, ekstrak dengan
perintah : #tar -xzvf CAS-1.0.1.tgz Setelah selesai proses ekstraksi akan muncul satu direktori dan
satu file, kopikan direktori yang ada pada /usr/share/php/PEAR/, kopikan juga file yang ada ke direktori yang sama. Kemudian tambahkan dua baris konfigurasi pada skrip 3.15 ini ke file konfigurasi php :
; UNIX: "/path1:/path2" ; Modifier pour fonctionner avec PHPcas include_path = ".:/php/includes:/usr/share/php/PEAR" require_once "/usr/share/php/DB.php"
Skrip 3.15. Konfigurasi ldap handler pada cas server
Langkah selanjutnya adalah menguji coba apakah pustaka klien tersebut telah berjalan dengan baik. Langkah yang harus dilakukan adalah dengan membuat sebuah skrip php sederhana seperti skrip 3.16 di bawah ini :
Skrip 3.16. Pustaka phpCas::client
Pada program phpCAS sederhana diatas, langkah pertama
adalah mengimport pustaka dari phpCAS yang telah terkestrak. Pengambilan pustaka ini harus dalam format full path. Setelah mengimport pustaka selanjutnya adalah menginisialisasi mesin dimana CAS server berjalan. Setelah itu seperti terlihat pada baris kesembilan, program akan memanggil fungsi dari pustaka untuk memaksa pengguna yang belum terotentikasi agar dibelokkan ke halaman otentikasi pada server CAS. Setelah pengguna melakukan otentikasi program akan memanggil fungsi getUser untuk mengambil nama pengguna yang melakukan otentikasi dan menampilkan dilayar, seperti terlihat pada baris dua puluh lima. Untuk proses logout program akan mengambil data dari permintaan yang dilakukan oleh pengguna, jika pengguna melakukan proses logout maka program akan memanggil fungsi logout, seperti terlihat pada baris empat belas sampai lima belas.
3.4.1.2 PUSTAKA phpCAS:proxy
Untuk mengintegrasikan phpCAS dengan aplikasi yang membutuhkan otentikasi level sistem maka digunakan fungsi phpCAS:proxy. Fungsi ini juga sudah tersedia pada pustaka phpCAS.
Perbedaan pertama dari fungsi phpCAS:client dan phpCAS:proxy terletak pada proses inisialisasi server CAS. Jika pada phpCAS:client dimulai dengan phpCAS::client maka untuk phpCAS:proxy ini dimulai dengan phpCAS::proxy. Perbedaan kedua terletak pada proses setelah otentikasi pengguna, jika pada phpCAS::client setelah otentikas hanya akan mengambil nama pengguna untuk proses lebih lanjut maka pada phpCAS:proxy ini akan memanggil nama layanan yang akan dijalankan setelah proses otentikasi berhasil, contoh dari kode program seperti skrip 3.17 di bawah ini :
Skrip 3.17. Pustaka phpCas::proxy
3.4.2 PUSTAKA pam_cas
Dikarenakan pada tugas akhir ini CAS akan diintegrasikan dengan mail dan proxy server yang memerlukan otentikasi level sistem maka diperlukan suatu pustaka yang bisa menghubungkan antara server CAS dengan sistem yang dipakai oleh mesin unix. Salah satu caranya adalah menggunakan modul pam.
Untuk mengintegrasikan server CAS dengan sistem otentikasi sistem dibutuhkan modul pam_cas yang terdapat pada YALE CAS client, pada klien CAS ini terdapat beberapa pustaka klien diantaranya adalah pam_cas, pustaka-pustaka lainnya adalah mod_cas untuk otentikasi pada Apache webserver dan pustaka untuk klien berbasis Java. Untuk mendapatkan YALE CAS client ini dapa diunduh melalui url http://www.ja-sig.org/wiki/download/attachments/827/cas-client-2.0.11.tar.gz. Sedangkan untuk mesin unix yang digunakan pada tugas akhir ini dapat menggunakan perintah:
#wget http://www.ja-sig.org/wiki/download/attachments/827/cas-client-2.0.11.tar.gz
Setelah terdownload ekstrak dengan perintah #tar -xzvf cas-client-2.0.11.tar.gz Setelah terekstrak masuk kedalam direkotri hasil ekstrkasi dan
masuk lagi kedalam direktori modul pam : # cd cas-client-2.0.11/pam_cas/ Kemudian kompilasi dengan mengetikkan perintah : # make Hasil kompilasi akan berupa modul pam unix yang berekstensi
.so, kopikan hasil kompilasi ini kedalam direktori /lib/security : # cp pam_cas.so /lib/security/ Tambahkan konfigurasi seperti skrip 3.18 di bawah pada file
otentikasi unix yang berada pada direktori /etc/pam.d :
Skrip 3.18. Konfigurasi modul pam
Kemudian tambahkan file konfigurasi untuk modul pam_cas ini
pada direktori /etc/pam_cas.conf seperti terlihat pada skrip 3.19 di bawah ini:
Skrip 3.19. Konfigurasi pam_cas
Uji coba dengan login pada halaman otentikasi server CAS dan
cek pada file /etc/syslog pastikan ada baris seperti gambar 3.11 di bawah :
Gambar 3.11. Tampilan syslog jika otentikasi berhasil
Penggunaan pam_cas ini akan dintegrasikan phpCAS:proxy yang telah dijelaskan pada bagian pustaka phpCAS di atas.
3.4.3 INTEGRASI PADA APLIKASI
Pada proyek akhir kali ini aplikasi yang diintegrasikan dengan server CAS adalah :
1. Squirrelmail sebagai aplikasi webmail. 2. Wordpress sebagai aplikasi web blog. 3. Moodle sebagai aplikasi e-learning.
3.4.3.1 INTEGRASI DENGAN SQUIRRELMAIL
Pada proyek akhir ini squirrelmail digunakan sebagai aplikasi webmail. Pengintegrasian dengan CAS dilakukan dengan menggunakan plugin yang ditulis oleh Daniel Stoye dari Humboldt-Universität zu Berlin.
Pertama squirrelmail harus terinstal pada server, untuk menginstal ketikkan perintah
# apt-get install squirrelmail Perintah di atas akan menginstall squirrelmail beserta
dependensi lainnya, antara lain postifix sebagai mail server dan courier-imap sebagai imap server. Untuk mengujicoba squirrelmail buka web browser ketikkan http://namaserver/squirrelmail, apabila keluar tampilan seperti gambar 3.12 maka instalasi squirrelmail telah berhasil.
Gambar 3.12. Webmail terinstall
Setelah squirrelmail terinstal langkah selanjutnya adalah instalasi plugin otentikasi CAS. Untuk memulai instalasi ekstrak file plugin otentikasi CAS dengan perintah
# tar –xzvf cas_auth-0.2-1.4.0.tar.gz Hasil ekstraksi berupa direktori cas_auth. Langkah selanjutnya
kopikan direktori hasil ekstraksi ke direktori plugin squirrel mail. # cp -r cas_auth /usr/share/squirrelmail/plugins Edit file config.php yang ada pada direktori auth_cas dan
sesuaikan dengan parameter yang ada pada server CAS. Contoh skrip ditunjukkan pada skrip 3.20 di bawah ini.
Skrip 3.20. Konfigurasi plugin squirrelmail
Baris pertama sampai dengan baris keenam pada skrip di atas
adalah konfigurasi dari pustaka phpCAS, baris ketujuh adalah konfigurasi untuk memaksa CAS server untuk mengehentikan sesi jika pengguna keluar dari webmail. Untuk baris ketujuh sampai baris lima belas adalah konfigurasi imap server yang di tangani oleh pam_cas. Langkah selanjutnya adalah aktifkan plugin dengan perintah
# squirrelmail-configure Perintah diatas akan menampilkan menu konfigurasi
squirrelmail. Pilih menu plugins � cas_auth, pemilihan menu dilakukan dengan cara memilih nomor yang ada pada bagian depan pilihan. Simpan konfigurasi dengan mengetikkan huruf S pastikan pada bagian installed plugin telah terdapat plugin cas_auth. Selanjutnya keluar dari menu konfigurasi dengan perintah Q. Untuk pengujian selanjutnya akan dibahas pada bab 4.
3.4.3.2 INTEGRASI DENGAN WORDPRESS
Wordpress pada proyek akhir kali ini digunakan sebagai weblog. Pengintegrasian wordpress dengan CAS menggunakan plugin yang ada pada situs http://wordpress.org/extend/plugins/wpcas/. Langkah pertama untuk pengintegrasian ini adalah instalasi wordpress. Wordpress dapat diunduh pada link http://wordpress.org/download/, setelah terunduh ekstrak file dengan perintah
# tar –xzvf latest.tar.gz Langkah di atas akan menghasilkan direktori bernama
wordpress yang bertempat sama dengan tempat pada saat ekstraksi. Langkah selanjutnya adalah pembuatan basisdata, untuk pembuatan basisdata ini dapat menggunakan tool phpMyAdmin. Langkah-langkah yang harus dikerjakan untuk pembuatan basisdata ini adalah sebagai berikut :
1. Pilih nama basisdata yang akan digunakan, masukkan pada kolom Create new database kemudian klik Create.
2. Klik ikon Home pada phpMyAdmin dan klik menu Privileges, klik Add new user ketikkan nama pengguna dan kata sandi yang dinginkan biarkan pilihan lainnya pada pilihan awal.
3. Setelah membuat pengguna baru, tambahkan privileges basisdata yang akan digunakan pada wordpress ke pengguna yang telah dibuat. Langkah pertama adalah seperti langkah nomor dua di atas lalu klik ikon Check priveleges pada pengguna yang akan diedit. Pada bagian Database-specific privileges pilih basisdata yang akan digunakan untuk instalasi wordpress pada menu dropdown Add privileges to the following database halaman akan refresh otomatis dengan menampilkan hak akses pada basisdata yang di pilih, pilih menu Check All untuk memberikan semua hak akses kepada pengguna ke dalam database wordpress.
Setelah pembuatan basisdata untuk wordpress selesai langkah selanjutnya adalah instalasi wordpress, langkah ini dimulai dengan merubah nama file konfigurasi pada direktori wordpress dari wp-config-sample.php menjadi wp-config.php, setelah selesai merubah nama jalankan skrip instalasi yang terletak pada direktori wordpress/wp-admin/install.php. Gambar 3.13 merupakan tampilan dari skrip instalasi.
Gambar 3.13. Proses instalasi wordpress
Pada langkah di atas isikan semua informasi basisdata yang
diperlukan pada kolom isian kemudian klik submit. Jika informasi yang diberikan benar maka skrip akan menampilkan halaman untuk konfigurasi judul blog seperti gambar 3.14 di bawah ini
Gambar 3.14. Konfigurasi judul blog
Setelah memasukkan judul yang diinginkan maka akan
ditampilkan pesan yang berisi kata sandi sementara untuk pengguna admin seperti terlihat pada gambar 3.15 di bawah ini. Kata sandi ini bersifat acak dan dapat dirubah pada halaman administrasi.
Gambar 3.15. Kata sandi pengguna admin
Langkah selanjutnya adalah instalasi plugin otentikasi CAS.
Plugin ini dapat diunduh pada http://downloads.wordpress.org/plugin/wpcas.zip, setelah terunduh ekstrak plugin dengan perintah :
# unzip wpcas.zip Hasil ekstraksi berupa direktori wp-cas. Salin direktori tersebut
ke dalam direktori wordpress/wp-content/plugins. Ubah nama wpcas-conf-sample.php menjadi wpcas-conf.php, sesuaikan parameter pada file konfigurasi tersebut sesuai parameter yang ada pada server CAS. Skrip 3.21 di bawah ini adalah contoh dari konfigurasi plugin wp-cas :
Skrip 3.21. Konfigurasi wp-cas
Baris ketiga sampai baris kedelapan pada skrip 3.21 di atas adalah konfigurasi dari pustaka phpCas, baris tiga belas sampai baris lima belas adalah penanganan kesalahan untuk pengguna yang terdaftar pada server CAS tetapi tidak terdaftar pada basisdata wordpress.
Aktifkan plugin melalui halaman administrasi pada bagian menu Plugins pilih wpcas kemudian klik Activate.
Untuk pengujian lebih lanjut pada wordpress akan dibahas pada bab 4.
3.4.3.3 INTEGRASI DENGAN MOODLE
Aplikasi moodle pada proyek akhir kali ini digunakan untuk aplikasi e-learning. Penginterasian aplikasi ini ke dalam system otentikasi CAS terbilang lebih sederhana dibandingkan dengan aplikasi-aplikasi lainnya di atas. Hal ini dikarenakan moodle pada dasarnya memang sudah mendukung CAS itu sendiri. Selain mudah aplikasi ini cukup fleksibel dalam hal otentikasi, sebagai contoh pada integrasi dengan CAS ini moodle masih menyediakan form login bawaan dari aplikasi yang disediakan untuk user yang tidak terdaftar pada server CAS.
Langkah pertama pada integrasi ini adalah instalasi moodle, file instalasi dapat diunduh pada http://download.moodle.org/download.php/stable19/moodle-1.9.5.tgz, setelah file terunduh ekstrak file dengan perintah
# tar –xzvf moodle-1.9.5.tgz Perintah di atas akan menghasilkan direktori moodle yang
berada pada tempat yang sama dimana proses ekstraksi dilakukan. Selanjutnya buat direktori moodledata dimana direktori ini berfungsi untuk menyimpan data-data course dari moodle, direktori ini harus berada di luar direktori yang bisa diakses dari web. Jalankan file instalasi pada direktori moodle/install, skrip instalasi akan menampilkan form yang berisi lokasi dari direktori dimana moodle berada dan direktori dari moodledata, untuk direktori dimana moodle berada tidak bisa dirubah dan mengikuti direktori dimana direktori moodle ditempatkan, sedangkan untuk kolom Data directory isikan lokasi dimana direktori moodledata berada seperti tampak pada gambar 3.16 di bawah ini:
Gambar 3.16. Pilihan direktori moodle
Setelah memasukkan lokasi direktori maka langkah selanjutnya
adalah memasukkan informasi dari basisdata yang akan digunakan oleh moodle. Sebelum memasukkan informasi tentang basisdata yang akan digunakan oleh moodle pastikan bahwa basisdata yang akan
digunakan telah ada pada mesin basisdata yang digunakan. Apabila belum ada langkah-langkah pembuatan basisdata ini sama dengan pembuatan basisdata untuk wordpress di atas kecuali pada nama basisdata dan nama pengguna.
Setelah pembuatan basisdata selesai masukkan informasi yang diperlukan pada kolom seperti tampak pada gambar 3.17 di bawah ini :
Gambar 3.17. Konfigurasi basisdata moodle
Pastikan semua informasi benar dan klik tombol next. Apabila
informasi yang dimasukkan benar maka installer akan menampilkan komponen-komponen yang dibutuhkan oleh moodle seperti tampak pada gambar 3.18 dibawah ini :
Gambar 3.18. Komponen moodle
Pastikan pada status pada kolom status OK. Setelah semua kebutuhan terpenuhi klik tombol next dan moodle akan melakukakan proses instalasi. Setelah proses instalasi selesai maka akan ditampilkan form untuk pembuatan pengguna admin yang akan melakukan konfigurasi selanjutnya seperti tampak pada gambar 3.19 di bawah ini :
Gambar 3.19. Konfigurasi pengguna admin moodle
Setelah semua proses instalasi selesai langkah selanjutnya ada
konfigurasi moodle agar dapat terintegrasi dengan CAS. Untuk melakukan konfigurasi agar dapat terintegrasi dengan CAS pengguna harus mempunyai hak administrator. Langkah pertama adalah login dengan pengguna yang mempunyai hak administrator melalui halaman login bawaan moodle seperti pada gambar 3.20 di bawah ini :
Gambar 3.20. Halaman login bawaan moodle
Jika nama pengguna dan kata sandi benar maka pengguna akan dibawa ke halaman administrasi moodle seperti tampak pada gambar 3.21 di bawah ini
Gambar 3.21. Halaman administrasi moodle
Untuk mengaktifkan otentikasi CAS, dari halaman administrasi
di atas pilih menu Users � Authentication � CAS Server (SSO), pada halaman akan tampil seperti gambar 3.22 di bawah
Gambar 3.22. Halaman administrasi CAS pada moodle
Isikan parameter-parameter sesuai dengan CAS server yang telah dikonfigurasi sebelumnya, pada halaman ini juga akan diminta konfigurasi LDAP server yang digunakan pada CAS server. Untuk sisa kolom pada halaman konfigurasi di atas biarkan pada kondisi awal, setelah selesai melakukan konfigurasi klik tombol Save
Changes untuk menyimpan konfigurasi yang telah ditulis pada kolom-kolom di atas. Konfigurasi di atas tidak secara otomatis merubah metode otentikasi yang tersimpan pada basisdata moodle oleh karena itu metode otentikasi yang ada pada basisdata moodle harus dirubah secara manual melalui phpMyAdmin atau konsol dari mysql. Buka halaman phpMyAdmin, dari menu dropdown pilih basisdata yang digunakan oleh moodle seperti ditunjukkan gambar 3.23 di bawah ini
Gambar 3.23. Tampilan basisdata moodle pada phpMyAdmin
Pilih tabel mdl_user � klik menu browse pada kolom kanan, akan tampil seperti gambar 3.24 di bawah ini
Gambar 3.24. Tampilan tabel mdl_user pada phpMyAdmin
Pada tabel mdl_user rubah isi dari kolom auth dari pengguna yang akan di ganti sistem otentikasinya dari manual menjadi cas. Nilai awal kolom auth ini adalah manual, untuk mengkatifkan otentikasi melalui cas ubah isi kolom menjadi cas, kemudian klik tombol go untuk menyimpan hasil perubahan dan pastikan bahwa nilai pada kolom auth telah berubah. Untuk pengujian lebih lanjut integrasi moodle dengan cas akan dibahas pada bab 4.
Halaman Ini Sengaja Dikosongkan
BAB IV PENGUJIAN DAN ANALISA SISTEM
4.1. PENGUJIAN DAN ANALISA SERVER LDAP
Pada pengujian dan analisa server LDAP ini akan di cek apakah server LDAP telah berjalan sesuai dengan yang dinginkan. Proses pengecekan dilakukan dengan metode yang telah dijelaskan pada bab 2. Akan tetapi pada proses pengujian ini hanya akan digunakan sebagian proses dari operasi-operasi yang ada pada LDAP. Operasi yang digunakan pada pengujian ini adalah search and query yang tidak memerlukan proses bind.
Proses search and query dapat dilakukan dengan mengetikkan perintah : $ ldapsearch -x –b dc=torrent,dc=eepis-its,dc=edu
Jika terdapat keluaran seperti gambar 4.1 di bawah ini maka LDAP server telah berjalan dengan baik:
Gambar 4.1. Hasil pencarian LDAP
Maka LDAP server telah berjalan dengan baik. Untuk proses
add dan update tidak diperlukan dikarenakan perubahan dan penambahan data tidak ditangani oleh CAS.
4.2. PENGUJIAN DAN ANALISA CAS SERVER
Pada pengujian server CAS ini dilakukan pengetesan apakah CAS server telah terkoneksi dengan baik dengan LDAP server sebagai basisdata pengguna untuk di gunakan ketahapan selanjutnya. Pada pengujian ini terjadi kesalahan apabila nama pengguna dan kata sandi tidak dapat dicocokan dengan daftar pengguna yang ada pada server LDAP. Pada gambar 4.2 di bawah ini menggambarkan ketika
pengguna tidak dapat terotentikasi karena kesalahan pada nama atau kata sandi.
Gambar 4.2. Kesalahan pada kata sandi atau nama pengguna
Kesalahan pada gambar 4.3 terjadi jika salah satu kolom tidak
diisi.
Gambar 4.3. Kesalahan kolom kata sandi tidak di isi
Untuk kesalahan lainnya seperti kegagalan otentikasi
dikarenakan server LDAP mati atau tidak dapat dihubungi akan tampil seperti gambar 4.2 diatas.
Jika semua kolom diatas diisi dengan benar dan server CAS dapat berkomunikasi dengan server LDAP untuk mencocokan nama pengguna dan kata sandinya maka akan muncul pesan sukses seperti pada gambar 4.4 di bawah ini.
Gambar 4.4. Otentikasi berhasil
Apabila otentikasi dengan LDAP telah berhasil seperti gambar 4.4 diatas maka server CAS telah siap digunakan untuk mengotentikasi layanan yang diinginkan.
4.3. PENGUJIAN DAN ANALISA PUSTAKA KLIEN
Setelah CAS server berjalan dengan baik CAS server siap untuk diintegrasikan dengan pustaka klien. Pada proyek akhir kali ini pustaka klien yang digunakan adalah phpCAS.
Untuk menguji phpCAS kita dapat menuliskan contoh sederhana dari pustaka phpCAS. Skrip 4.1 adalah contoh skrip sederhana dari phpCAS :
Skrip 4.1. Skrip dasar phpCas
Pada program phpCAS sederhana diatas, langkah pertama
adalah mengimport pustaka dari phpCAS yang telah terkestrak seperti terlihat pada baris pertama. Pengambilan pustaka ini harus dalam format full path. Setelah mengimport pustaka kita menginisialisasi mesin dimana tempat CAS server berjalan. Setelah itu seperti terlihat pada baris kesembilan program akan memanggil fungsi dari pustaka untuk memaksa pengguna yang belum terotentikasi agar dibelokkan ke halaman otentikasi pada server CAS. Setelah pengguna melakukan otentikasi program akan memanggil fungsi getUser untuk mengambil nama pengguna yang melakukan otentikasi dan menampilkan dilayar, seperti terlihat pada baris dua puluh lima. Untuk proses logout program akan mengambil data dari permintann yang dilakukan oleh pengguna, jika pengguna melakukan proses logout maka program akan memanggil fungsi logout, seperti terlihat pada baris empat belas sampai lima belas.
Jika pengguna terotentikasi maka program akan menampilkan tampilan seperti pada gambar 4.5 di bawah ini.
Gambar 4.5. Otentikasi phpCAS berhasil
Apabila otentikasi pengguna gagal maka program akan
memunculkan halaman kesalahan seperti pada gambar 4.2 atau 4.3. Link logout digunakan jika pengguna ingin mengakhiri sesi phpCAS, link tersebut akan menghasilkan tampilan seperti pada gambar 4.6 di bawah ini.
Gambar 4.6. Halaman logout
Dikerenakan CAS server membutuhkan sertifikat https yang
ditandatangi oleh CA(Cerificate Authority) yang terpercaya maka layanan-layanan yang membutuhkan tingkat otentikasi lebih tinggi seperti phpCAS::proxy yang dijelaskan pada bab3 tidak akan berjalan apabila sertifikat ssl yang digunakan tidak ditandatangani oleh CA(Cerificate Authority) yang terpercaya. Gambar 4.7
menunjukkan contoh kesalahan jika digunakan sertifikat ssl yang tidak ditandatangani oleh CA(Cerificate Authority) yang terpercaya. Pada proyek akhir kali ini digunakan serifikat gratis dari Comodo.Ca untuk sertifikat ssl. Dikarenakan bersifat gratis maka masa berlaku dari sertifikat ini hanya 3 bulan.
Gambar 4.7. Kesalahan karena sertifikat ssl tidak terpercaya
4.4. PENGUJIAN DAN ANALISA INTEGRASI LAYANAN Setelah pustaka klien yang akan dijalankan pada CAS server
telah berjalan dengan baik maka CAS server siap untuk diintegrasikan kedalam layanan yang dinginkan.
Pada proyek akhir kali ini layanan yang dipilih untuk diintegrasikan dengan CAS adalah wordpress untuk klien berbasis web penuh, squirrelmail sebagai layanan webmail dan moodle sebagai aplikasi e-learning.
Gambar 4.8, 4.9, 4.10 dibawah menunjukkan halaman aplikasi sebelum diintegrasikan dengan CAS.
Gambar 4.8. Halaman login webmail tanpa CAS
Gambar 4.9. Halaman login wordpress tanpa CAS
Gambar 4.10. Halaman login moodle tanpa CAS
Setelah layanan diintegrasikan kedalam CAS maka halaman
login akan di redirect ke halaman login dari CAS server seperti pada gambar 4.11, 4.12 dan 4.13 di bawah ini.
Gambar 4.11. Halaman login wordpress dengan CAS
Gambar 4.12. Halaman login webmail dengan CAS
Gambar 4.13. Halaman login moodle dengan CAS
Setelah CAS terintegrasi dengan layanan maka CAS akan
mengambil alih proses otentikasi dari yang awalnya menggunakan basisdata dari layanan itu sendiri, setelah terintegrasi layanan akan menggunakan basisdata pengguna dari CAS. Untuk wordpress dan moodle basisdata asli masih digunakan untuk mengecek ulang apakah pangguna yang terdaftar pada server CAS mempunyai akun pada aplikasi tersebut.
Untuk pengujian pada webmail masukkan nama pengguna dan kata sandi pada kolom yang ada, jika ada kesalahan maka CAS akan menampilkan pesan kesalahan seperti pada gambar 4.2 dan 4.3 diatas. Jika nama dan kata sandi benar maka pengguna akan dibawa ke halaman webmail masing-masing penguna seperti pada gambar 4.14.
Gambar 4.14. Pengguna berhasil login ke dalam webmail
Untuk aplikasi wordpress terdapat pesan kesalahan tambahan
jika pengguna terdaftar pada basisdata CAS tetapi tidak terdafatar pada basisdata wordpress. Jika terjadi hal itu maka aplikasi akan menampilkan pesan yang ditunjukkan pada gambar 4.15.
Gambar 4.15. Pengguna tidak terdaftar pada wordpress Apabila pengguna terdafatar pada wordpress maka pengguna
akan dibawa ke halaman administrasi blog mereka seperti ditunjukkan gambar 4.16 di bawah ini.
Gambar 4.16. Pengguna berhasil login ke halaman administrasi
Pada aplikasi moodle jika pengguna belum terdaftar pada
basisdata maka pengguna akan diarahkan ke halaman registrasi untuk mendaftar ke dalam basisdata pengguna moodle, hal ini ditunjukkan pada gambar 4.17 di bawah ini :
Gambar 4.17. Halaman registrasi pengguna baru
Jika pengguna telah terdaftar baik di basisdata pengguna dan di
basisdata CAS maka pengguna akan diarahkan ke halaman
administrasi masing-masing sesuai dengan level pengguna, seperti di tunjukkan pada gambar 4.18.
Gambar 4.18. Halaman administrasi pengguna
Halaman Ini Sengaja Dikosongkan
BAB V PENUTUP
5.1 KESIMPULAN
Dari hasil uji coba sistem yang dilakukan, dapat ditarik beberapa simpulan, antara lain:
1. Otentikasi dapat berjalan dengan baik pada aplikasi squirrelmail, wordpress dan moodle.
2. Keamanan data-data pengguna pada saat proses login lebih terjamin karena otentikasi berjalan pada protokol https.
3. Sistem hanya dapat berjalan dengan menggunakan sertifikat ssl yang diterbitkan oleh penerbit yang dipercaya.
4. Setifikat ssl yang digunakan pada proyek akhir ini adalah versi gratis dari sertifikat ssl yang diterbitkan oleh Comodo CA.
5.2 SARAN
Hal yang perlu diperhatikan untuk mengembangkan sistem ini lebih lanjut yaitu perlunya mengintegrasikan layanan-layanan non web agar bisa melakukan otentikasi dengan CAS. Dengan demikian pengguna akan lebih terbantu dalam hal manajemen daftar nama dan kata sandi yang mereka gunakan pada jaringan PENS-ITS.
LAMPIRAN
Daftar Perintah LDAP : • Inisialisai TLS menggunakan LDAPv3 Transport Layer
Security (TLS). • Bind � otentikasi dan memilih protokol ldap yang akan
digunakan. • Search � mencar isi direktori. • Compare � mengetes apakah nama yang di masukkan
mengandung aribut. • Menambah data. • Hapus data. • Modifikasi data. • Modifikasi Distinguished Name (DN). • Abandon � membatalkan operasi sebelumnya • Extended Operation � operasi generic yang digunakan
untuk mendefinisikan operasi lainnya. • Unbind � menutup koneksi.
Listing phpCas::client :
<?php // import phpCAS lib include_once('CAS.php'); phpCAS::setDebug(); // initialize phpCAS phpCAS::client(CAS_VERSION_2_0,'proxy3.eepis-its.edu',443,'cas'); // no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();
// force CAS authentication
phpCAS::forceAuthentication();
Listing phpCas::proxy :
// logout if desired if (isset($_REQUEST['logout'])) { phpCAS::logout(); } // for this test, simply print that the authentication was successfull ?> <html> <head> <title>phpCAS simple client</title> </head> <body> <h1>Successfull Authentication!</h1> <p>the user's login is <b><?php echo phpCAS::getUser(); ?></b>.</p> <p>phpCAS version is <b><?php echo phpCAS::getVersion(); ?></b>.</p> <p><a href="?logout=">Logout</a></p> </body> </html>
? include_once('CAS.php'); // set debug mode phpCAS::setDebug(); // initialize phpCAS phpCAS::proxy(CAS_VERSION_2_0,'proxy3.eepis-its.edu',443,'cas'); // no SSL validation for the CAS server phpCAS::setNoCasServerValidation(); // force CAS authentication phpCAS::forceAuthentication(); phpCAS::getUser(). $service = 'http://proxy3.eepis-its.edu/~gatra/docs'; ?>
Listing konfigurasi wp-cas :
<html> <head> <title>phpCAS proxied proxy example</title> </head> <body> <h1>phpCAS proxied proxy example</h1> <p>the user's login is <b><?php echo phpCAS::getUser(); ?></b>.</p> <h2>Response from service <?php echo $service; ?></h2><ul><hr> <?php flush(); // call a service and change the color depending on the result if ( phpCAS::serviceWeb($service,$err_code,$output) ) { echo '<font color="#00FF00">'; } else { echo '<font color="#FF0000">'; } echo $output; echo '</font><hr></ul>'; ?> <? if (isset($_REQUEST['logout'])) { phpCAS::logout(); }?> <p><a href="?logout=">Logout</a></p> </body> </html>
<?php // the configuration array $wpcas_options = array( 'cas_version' => '2.0', 'include_path' => 'CAS.php', 'server_hostname' => 'proxy3.eepis-its.edu', 'server_port' => '443', 'server_path' => '/cas' ); function wpcas_nowpuser( $user_name ){ die('you do not have permission here'); } ?>
Listing konfigurasi auth_cas :
<?hp global $cas_hostname, $cas_port, $cas_uri, $debug_mode, $use_custom_imapserver_for_casticket, $custom_imapserver_for_casticket, $sign_out_from_cas_when_logging_out; // name of the cas serveer $cas_hostname="proxy3.eepis-its.edu"; $cas_port=443; $cas_uri="/cas"; // if set to true, various parameters, including tickets and usernames will be logged $debug_mode=true; $sign_out_from_cas_when_logging_out = true; $use_custom_imapserver_for_casticket = true; $custom_imapserver_for_casticket = 'imap://localhost'; ?>
RIWAYAT PENULIS
Nama : Gatra Wikan Arminda Alamat : Arjuno 01, Jiwan, Madiun 63161 Telp : 031-60855429 TTL : Mataram, 11 Maret 1987 Email : [email protected]
Riwayat Pendidikan: 1 SDN Kincang 03 1992-1998 2 SLTPN 1 Jiwan 1998-2001 3 SMKN 1 Madiun 2001-2004 4 Community College Madiun 2004-2005
5 PENS-ITS Surabaya Jurusan Teknik Informatika
2006-2009