5
web di IPB tersimpan dalam banyak server dengan spesifikasi dan sistem operasi yang beragam. Topologi jaringan IPB dapat dilihat pada Lampiran 2. IPB telah menggunakan media penyimpanan data tunggal untuk user berupa LDAP. LDAP telah digunakan untuk autentikasi pada beberapa aplikasi di IPB, seperti autentikasi penggunaan layanan internet, KRS-Online, blog, email, dan repository. Pemanfaatan LDAP pada sistem autentikasi IPB dapat dilihat pada Lampiran 3. Pada awalnya, autentikasi akses internet IPB menggunakan Squid dengan mekanisme autentikasi basic. Autentikasi basic mengirimkan pasangan username dan password dari client ke server dalam bentuk plaintext. Pesan yang dikirimkan dalam bentuk plaintext dapat dengan mudah dibaca oleh orang lain dengan perangkat lunak untuk sniffing seperti Wireshark. Pada awal tahun 2010, autentikasi akses internet IPB diganti dengan mekanisme autentikasi digest. Dalam mekanisme ini, username dan password dikirimkan dari client ke server berupa nilai hash sehingga tidak terbaca jika paket data ditangkap dengan sniffer. Penggunaan mekanisme digest ini memunculkan masalah baru. Load balancer meneruskan request user ke empat proxy yang berbeda sesuai algoritme round-robin, sementara mekanisme digest mengirimkan nonce (rangkaian karakter yang hanya dipakai sekali). Nonce yang dikirim oleh setiap proxy selalu berbeda. Akibatnya, ketika algoritme round-robin meneruskan request user ke proxy yang berlainan, user harus kembali memasukkan username dan password proxy karena nonce yang dikirimkan dari server ke client berbeda. Berdasarkan permasalahan di atas, IPB memerlukan aplikasi SSO yang mendukung aplikasi web dan proxy yang dapat diakses dari dalam maupun luar IPB. Selanjutnya, aplikasi ini disebut sebagai SSO IPB. Perancangan Pada tahap perancangan, dilakukan pembuatan desain sistem SSO IPB. Perancangan terdiri atas perancangan jaringan, proses, media penyimpanan, dan antarmuka sistem. Rancangan Arsitektur Jaringan. Perancangan jaringan SSO IPB disesuaikan dengan arsitektur jaringan yang
ada di IPB yang menggunakan dua buah load balancer dengan aplikasi Haproxy, sejumlah server proxy dengan aplikasi Squid 3.0, dan beberapa server website. Selain itu, juga terdapat server LDAP yang menyimpan data personal user di IPB. Sistem SSO IPB memerlukan komputer-komputer server dan komputer client yang mengakses serverserver di IPB. Komputer server tambahan yang diperlukan selain yang sudah ada di jaringan sebelumnya adalah server SSO. Rancangan arsitektur aliran data pada sistem SSO IPB dapat dilihat pada Lampiran 4. Server SSO merupakan sebuah server yang digunakan untuk semua autentikasi aplikasi yang terintegrasi dengan SSO IPB. Dalam server ini, terdapat web server dan database MySQL. Server ini memunculkan permintaan credential (username dan password) serta menyimpan data user yang telah melakukan login ke dalam database. Jika user melakukan akses internet dari dalam jaringan internet IPB, request akan melewati salah satu load balancer dengan alamat IP 172.17.0.11 atau 172.17.0.18 sesuai konfigurasi proxy pada browser yang digunakan untuk mengakses internet. Load balancer tersebut membagi request ke empat buah proxy. Pada empat buah proxy dengan aplikasi Squid 3.0 inilah terdapat aturanaturan yang menolak atau meneruskan permintaan user. Sebagian permintaan user akan diteruskan ke internet atau server yang berada di IPB. Request yang ditolak karena user belum melakukan login akan di-redirect ke halaman login yang tersimpan di server SSO IPB. User dapat mengakses website yang tersimpan di server IPB dari luar jaringan internet IPB. Perbedaannya, request user dari luar jaringan IPB tidak melewati load balancer dan proxy seperti yang terjadi pada request dari dalam jaringan internet IPB, tetapi user dapat langsung melakukan akses terhadap server IPB yang memiliki IP publik. Rancangan Proses Proses yang terjadi dalam sistem SSO IPB dapat dibagi menjadi beberapa bagian. Proses tersebut adalah proses login, logout, proses autentikasi website, dan autentikasi proxy. a Rancangan Proses Login Semua proses login yang berada dalam sistem SSO IPB (login untuk proxy, maupun login untuk website) dilakukan melalui sebuah portal. Diagram alir rancangan proses login
6
dapat dilihat pada Lampiran 5. Seperti proses login pada umumnya, seorang user harus memasukkan pasangan username dan password yang benar. Selanjutnya, sistem memeriksa jumlah UID yang ditemukan pada LDAP untuk mengetahui apabila ada UID yang kembar. Apabila UID tidak kembar, proses login dilanjutkan dengan validasi username dan password pada LDAP. Jika pasangan username dan password sesuai dengan data yang tersimpan di LDAP, session baru dibuat dan disimpan ke dalam database untuk keperluan login selanjutnya. Apabila sudah terdapat session yang sama dalam database, dengan kata lain username yang sama telah melakukan login di lokasi yang berbeda, session yang lama dihapus dan diganti dengan session yang baru. Untuk mempermudah proses login dari aplikasi, data yang telah diperoleh dari LDAP juga disimpan ke dalam database MySQL. b Rancangan Proses Autentikasi Proxy Autentikasi proxy diperlukan ketika user mengakses dari dalam jaringan internet IPB. Aplikasi proxy yang digunakan adalah Squid. Diagram alir proses autentikasi pada proxy
dapat dilihat pada Gambar 3. Squid dapat menerima alamat IP dari komputer user jika Squid langsung berhubungan dengan komputer user. Pada arsitektur jaringan IPB, terdapat load balancer (Haproxy) yang berada di antara komputer client dan Squid sehingga alamat IP yang diterima Squid adalah alamat IP load balancer. Secara default, konfigurasi Haproxy hanya meneruskan alamat IP-nya sendiri, sedangkan alamat IP dari user tidak diteruskan ke tujuan berikutnya (dalam kasus ini, tujuan berikutnya adalah Squid). Untuk memperoleh alamat IP user, diperlukan perubahan konfigurasi pada Haproxy untuk menambahkan header X-Forwarded-For yang meneruskan alamat IP user untuk diterima Squid. Penambahan header X-Forwarded-For juga diperlukan pada setiap server Squid. Jika penambahan header X-Forwarded-For tidak dilakukan, alamat IP yang akan diterima portal SSO IPB ketika terjadi proses login adalah alamat IP proxy itu sendiri, bukan alamat IP client. Akibatnya, jika salah satu request dari salah satu Squid berhasil terautentikasi, semua request berikutnya dari server yang sama akan dianggap telah terautentikasi, meskipun dari user yang berbeda. Tentu saja hal ini tidak diinginkan. Squid menyediakan fasilitas untuk melakukan autentikasi dengan program eksternal. Program ini harus memberikan output berupa string OK jika autentikasi berhasil dan ERR jika autentikasi gagal. Di belakang output OK atau ERR dapat ditambahkan parameter lain seperti user, password, message, dan log. Pada sistem SSO IPB, program eksternal Squid digunakan untuk memeriksa keberadaan IP pada server SSO IPB. Proxy dapat memeriksa keberadaan IP user pada server SSO dengan beberapa cara. Ilustrasi ketiga cara tersebut dapat dilihat pada Gambar 4, Gambar 5, dan Gambar 6. Cara 1: Program eksternal proxy memeriksa keberadaan session di database MySQL secara langsung setiap menerima request dari user.
Gambar 3 Rancangan proses autentikasi proxy.
7
Cara 2: Server SSO membuat file berisi pasangan IP dan user. File tersebut dikirimkan ke proxy server secara berkala dengan bantuan aplikasi rsync. Selanjutnya, program eksternal proxy memeriksa keberadaan IP dan user secara lokal berdasarkan file yang telah diterima dari server SSO IPB. SERVER PROXY
SERVER SSO IPB
Squid
Program eksternal Squid
Database
Gambar 4 Mekanisme pembacaan session proxy dengan database. SERVER PROXY Squid
SERVER SSO IPB
Database
Program eksternal Squid File File
Gambar 5 Mekanisme pembacaan session proxy dengan file lokal. SERVER PROXY Squid
SERVER SSO IPB Database
File Program eksternal Squid Web service
Gambar 6 Mekanisme pembacaan session proxy dengan web service.
Cara 3: Program eksternal proxy memeriksa keberadaan session melalui web service yang disediakan oleh server SSO IPB. Web service tersebut memberikan output berupa pasangan IP dan user. c Rancangan Proses Autentikasi Website Autentikasi Website SSO IPB merupakan proses autentikasi yang terjadi pada setiap website yang terintegrasi dengan sistem SSO IPB. Proses autentikasi web pada SSO IPB dapat dilihat pada Lampiran 6. Untuk mengintegrasikan website dengan sistem SSO IPB, diperlukan sebuah modul yang terpasang pada setiap website. Modul tersebut memeriksa apakah end user sudah melakukan login atau telah logout dari sistem. Proses login diawali ketika seorang user membuka halaman aplikasi yang terintegrasi dengan SSO IPB. Pada halaman tersebut, telah disisipkan sebuah script yang membaca keberadaan user session untuk memperoleh token di server SSO IPB. Apabila session ditemukan dan token berhasil diperoleh, client (aplikasi) melakukan permintaan data user ke SSO IPB dengan menggunakan token. Selanjutnya, client dapat menggunakan data tersebut untuk melakukan sebuah mekanisme login pada aplikasi tersebut. Apabila token gagal diperoleh, halaman aplikasi dalam kondisi tidak login. Pada halaman tersebut, terdapat sebuah tombol login yang mengarahkan user ke halaman login SSO IPB. Pada halaman tersebut, user dapat mengizinkan maupun melarang client memperoleh data yang tersimpan dalam resource server. Server SSO IPB akan memberikan token kepada client apabila user mengizinkan client memperoleh data di dalam resource server. Token tersebut dapat dimanfaatkan untuk mengambil data user untuk keperluan login pada client. d Rancangan Proses Logout Proses logout dapat dilihat pada Gambar 7. User dapat melakukan logout dengan menekan tombol logout pada halaman SSO IPB. Ketika tombol logout ditekan, halaman SSO IPB terbuka dan script untuk logout dijalankan. Script logout menghapus session yang tersimpan di MySQL dan session pada server SSO IPB. User dianggap telah melakukan logout setelah kedua session dihapus. Rancangan Media Penyimpanan SSO IPB memerlukan tiga jenis media penyimpanan yang berupa file, LDAP, dan
8
MySQL. Media penyimpanan lain dapat digunakan pada setiap aplikasi yang terintegrasi dengan SSO IPB sesuai kebutuhan masing-masing aplikasi. a LDAP LDAP digunakan untuk autentikasi user ke aplikasi-aplikasi yang terintegrasi dengan SSO IPB. DIT pada LDAP di IPB memiliki root dc=ipb,dc=ac,dc=id. DIT IPB dalam aplikasi PHP LDAP Admin dapat dilihat pada Lampiran 7.
Root IPB memiliki beberapa cabang OU (organizational unit) seperti alumni, staff_ipb, dan student. Setiap cabang yang terdapat di LDAP digunakan untuk membatasi hak akses user terhadap aplikasi tertentu. Sebagai contoh, aplikasi Blog Student (http://student.ipb.ac.id) hanya dapat diakses oleh user yang berada di bawah DN student (ou=student, dc=ipb ,dc=ac, dc=id) dan tidak dapat diakses oleh user yang berada di luar DN tersebut. Sebaliknya, aplikasi lain seperti Mail Staff hanya dapat diakses oleh user yang berada di bawah DN staff_ipb (ou=staff_ipb, dc=ipb ,dc=ac, dc=id) dan tidak dapat diakses oleh user di luar DN tersebut. b MySQL Fungsi utama MySQL pada sistem SSO IPB adalah menyimpan session yang menentukan apakah seorang user telah melakukan login atau belum. Session ini tersimpan dalam sebuah tabel. Session yang digunakan dalam SSO IPB menggunakan tabel user_session bawaan framework Codeigniter dengan menambahkan kolom user_id, proxy_permission, ldap_json, dan ip. Tabel session dapat dilihat pada Tabel 1.
Gambar 7 Rancangan proses logout SSO IPB.
MySQL dalam sistem SSO IPB selain menyimpan data session, juga berfungsi untuk menyimpan aplikasi-aplikasi yang telah terdaftar dalam SSO IPB, menyimpan status keterhubungan antara user dan aplikasi tertentu (client), serta menyimpan token yang dapat digunakan aplikasi untuk memperoleh resource milik user yang tersimpan dalam resource server. Masing-masing fungsi tersebut ditangani oleh tabel application,
Tabel 1 Struktur tabel user_session Field
Tipe
Keterangan
session_id
Varchar(60)
ID session
ip_address
Varchar(16)
Alamat IP dari header REMOTE_ ADDR
user_agent
Varchar(120)
User agent yang digunakan user
last_activity
Int(10)
Timestamp ketika session terakhir di-update
user_data
Text
Data session
ip
Varchar(16)
Alamat IP user dari header HTTP_X_FORWARDED_FOR
ldap_json
Text
Data dari LDAP yang disimpan dalam format json
user_id
Varchar(40)
Username atau user ID
proxy_permission
Int(1)
Berisi 1 jika user berhak menggunakan akses internet melalui proxy atau 0 jika user tidak berhak melakukan akses internet melalui proxy
9
application_user, dan token yang dapat dilihat pada Lampiran 8, Lampiran 9, dan Lampiran 10. c File File teks digunakan untuk menyimpan data pasangan IP dan username yang dapat digunakan untuk autentikasi pada proxy. Server SSO IPB membuat file teks secara berkala berdasarkan user_session. Selanjutnya, server SSO IPB melakukan sinkronisasi terhadap file yang telah dibuat ke seluruh proxy. Pembuatan file teks dan sinkronisasi dilakukan terus menerus dalam selang waktu yang pendek untuk menjaga kontinuitas koneksi internet melalui proxy. Rancangan Antarmuka Rancangan antarmuka yang dibuat terdiri atas halaman login SSO IPB dan tombol login SSO IPB. a Halaman Login SSO IPB Halaman login SSO IPB, seperti pada Gambar 8, memiliki satu login form untuk memasukkan username dan password. Pada halaman tersebut, terdapat fasilitas untuk melihat username berdasarkan NRP atau NIP yang dapat dimanfaatkan ketika user lupa username tetapi masih mengingat NIP atau NRP. b Tombol Login SSO IPB Tombol login merupakan sebuah tombol yang dapat dipasang pada setiap aplikasi web yang terintegrasi dengan SSO IPB. Ketika tombol login ditekan, akan terbuka sebuah halaman baru untuk melakukan login melalui SSO IPB atau apabila sebelumnya user telah menyetujui login otomatis oleh client, halaman aplikasi client akan langsung terautentikasi. Tombol login dapat dilihat pada Gambar 9. Pengembangan Sistem dan Implementasi Sistem SSO IPB diimplementasikan pada lingkungan dummy yang terdiri atas beberapa komputer untuk load balancer, proxy, server
Gambar 8 Rancangan antarmuka login form.
SSO IPB, dan aplikasi web. Konfigurasi Haproxy Konfigurasi yang perlu ditambahkan pada load balancer (Haproxy) untuk meneruskan alamat IP client adalah penambahan header X-Forwarded-For dan penutupan koneksi HTTP (httpclose). Pada konfigurasi default, kedua konfigurasi tersebut belum aktif. Header X-Forwarded-For pada request HTTP berfungsi untuk menambahkan IP client pada header HTTP sehingga alamat IP client dapat terbaca oleh Squid dan Server SSO IPB. Penutupan koneksi HTTP (httpclose) diaktifkan supaya Haproxy selalu meneruskan alamat IP user untuk setiap request yang melewati load balancer, bukan hanya meneruskan alamat IP user pada request pertama. Konfigurasi Squid Fungsi Squid pada sistem SSO IPB antara lain untuk menerima request yang berasal dari load balancer (Haproxy), melakukan filter request yang telah diterima, dan meneruskan request. Konfigurasi Squid dibuat sedemikian rupa sehingga dapat menerima alamat IP user, kemudian memeriksa apakah IP tersebut telah terautentikasi atau belum. IP user yang dibaca adalah IP yang berada pada header XForwarded-For, bukan IP yang tersimpan pada variabel REMOTE_ADDR (Remote Address) maupun IP Haproxy. Pembacaan pasangan IP dan username terdiri atas tiga mekanisme yang telah dijelaskan pada rancangan proses autentikasi proxy. Instalasi Server SSO IPB Pada server ini, diperlukan sebuah web dan media penyimpanan berupa MySQL. Web server diperlukan karena autentikasi user dilakukan pada halaman website SSO IPB. Website SSO IPB diberi domain http://sso.ipb.ac.id. Pembuatan Modul SSO Modul SSO diperlukan oleh setiap aplikasi web dan proxy yang akan diintegrasikan dengan SSO IPB. Modul untuk aplikasi web dibuat dalam bahasa PHP karena sebagian besar server di IPB telah mendukung bahasa pemrograman ini dan banyak aplikasi yang
Gambar 9 Rancangan antarmuka tombol login.
10
dibuat dengan menggunakan PHP. Tugas yang perlu dilakukan modul pada setiap aplikasi adalah melakukan permintaan akses terhadap resource kepada server SSO IPB dan menerima respons berupa token dari server SSO IPB yang dapat digunakan untuk memperoleh resource pada resource server. Modul SSO ini dapat dimodifikasi oleh developer aplikasi client sesuai kebutuhan client. Modul untuk proxy dibuat dengan bahasa pemrograman PHP dan shell script. PHP digunakan apabila proxy membaca session pada database server SSO IPB secara langsung, sedangkan shell script digunakan apabila proxy perlu melakukan akses terhadap web service pada server SSO IPB atau membaca file lokal pada proxy server. Cron Cron dalam sistem SSO IPB diperlukan untuk melakukan proses rutin dalam server SSO IPB. Proses yang dilakukan secara rutin yaitu penghapusan session yang kadaluarsa dan pengiriman data user dan IP ke setiap proxy dalam selang waktu yang pendek (misalnya setiap satu menit). OAuth 2.0 Grant type OAuth yang digunakan dalam penelitian ini adalah Implicit Grant yang dirancang untuk digunakan pada aplikasi yang dibuka pada browser. Token dari Authorization Server (server SSO IPB) dikirimkan sekaligus bersama respons permintaan akses terhadap protected resource. Token tersebut digunakan untuk memperoleh data user yang berasal dari server SSO. Empat entitas yang terlibat dalam dalam OAuth adalah end user sebagai resource owner, server SSO IPB sebagai authorization server, aplikasi web sebagai client, dan server data sebagai web hosted client resource. Client merupakan aplikasi-aplikasi web yang dihubungkan dengan SSO IPB, sedangkan client resource berupa media penyimpanan data user. Pengujian
disisipkan pada setiap aplikasi dan dimodifikasi sesuai mekanisme login yang digunakan. Masing-masing aplikasi dibuka pada satu browser pada tab yang berbeda dalam kondisi belum login. Selanjutnya, user melakukan login pada halaman SSO IPB dengan alamat sso.ipb.ac.id. Ketiga aplikasi yang semula belum berada dalam status login mengalami perubahan status menjadi login setelah user melakukan refresh pada masing-masing aplikasi. Dengan demikian, penerapan SSO IPB pada tiga aplikasi web di IPB dinyatakan berhasil. b Autentikasi Proxy SSO IPB Pengujian autentikasi proxy dilakukan pada tiga mekanisme pembacaan session yang telah dirancang. Sebelum melakukan akses internet, user perlu melakukan perubahan konfigurasi proxy pada browser sesuai dengan alamat IP load balancer yang terintegrasi dengan SSO IPB. Mula-mula, user yang membuka website http://google.com diarahkan oleh sistem SSO ke halaman login SSO IPB. Setelah user melakukan login, user dapat melanjutkan akses internet sesuai dengan alamat yang diinginkan. Hasil pada ketiga mekanisme pembacaan session dapat dilihat pada Tabel 2. c Penggunaan SSO IPB dari Luar Jaringan Internet IPB Dalam pengujian ini, tiga aplikasi yang telah terintegrasi dengan sistem SSO IPB (Penjadwalan Video Conference, Blog Staff, dan Blog Student) dibuka dari luar jaringan IPB. Berdasarkan percobaan yang telah dilakukan, autentikasi SSO pada ketiga aplikasi tersebut dapat berjalan dengan baik. Autentikasi aplikasi web pada sistem SSO IPB dapat dilakukan dari dalam maupun dari luar jaringan SSO IPB. d Idle User Pengujian ini diawali ketika user telah melakukan login pada halaman login SSO. Sebelum pengujian dilakukan, ditentukan Tabel 2 Hasil pengujian login proxy SSO IPB
Pengujian Keberhasilan Sign-on
Mekanisme
Hasil
a Penerapan SSO untuk Aplikasi Web SSO IPB dilakukan pada tiga aplikasi web yang ada di IPB. Ketiga aplikasi tersebut adalah Penjadwalan Video Conference (jadwalvicon.ipb.ac.id), Blog Mahasiswa IPB (student.ipb.ac.id), dan Blog Staff IPB (staff.ipb.ac.id). Sebuah modul SSO
Proxy membaca database
berhasil
Proxy membaca file lokal
berhasil
Proxy membaca web service
berhasil
11
waktu penghapusan session yang kadaluarsa setiap satu menit. Pengujian idle user dilakukan dengan dua cara. Pada cara pertama, user menutup halaman SSO IPB dan menunggu beberapa saat hingga terjadi logout secara otomatis. Pada cara kedua, user menutup browser kemudian membuka halaman browser kembali untuk melihat kondisi login SSO IPB. Logout otomatis dapat terjadi pada kedua cara. Akan tetapi, user perlu menunggu kurang dari satu menit untuk menunggu logout otomatis dari proxy. e Pengujian SSO pada Browser Pengujian SSO IPB dilakukan pada lima buah browser yang banyak digunakan oleh user. Kelima browser tersebut adalah Mozilla Firefox, Google Chrome, Internet Explorer, Opera, dan Safari. SSO dapat berjalan dengan baik pada Mozilla Firefox, Google Chrome, Opera, dan Safari, namun tidak dapat berjalan dengan baik pada Internet Explorer karena header X-Forwarded-For tidak dapat diteruskan ketika user menggunakan Internet Explorer. Keamanan SSO IPB a IP Spoofing Attack Uji coba IP spoofing attack dilakukan pada autentikasi proxy dengan sebuah komputer sebagai korban dan satu komputer lain sebagai pelaku IP spoofing. Mula-mula, korban melakukan autentikasi proxy melalui sistem SSO IPB, kemudian dilakukan pemutusan koneksi internet sebelum korban melakukan logout. Pelaku IP spoofing memanfaatkan IP korban dengan mengganti alamat IP-nya menjadi alamat IP korban dengan tujuan memperoleh akses internet tanpa melakukan autentikasi terlebih dahulu. Pada mulanya, pelaku memperoleh akses internet tanpa melakukan autentikasi, tetapi beberapa saat kemudian sistem SSO IPB melakukan logout otomatis terhadap alamat IP korban. Hal ini terjadi karena user perlu memperbarui session pada server SSO IPB dengan cara tetap membuka halaman SSO IPB selama melakukan akses internet untuk menjaga session tetap valid. b Packet Sniffing Packet sniffing terjadi ketika seorang hacker mengamati paket TCP/IP yang melewati jaringan dan mencuri informasi di dalamnya. Hal ini dapat terjadi apabila paket yang melewati jaringan tidak terenkripsi. Oleh karena itu, pencegahan terhadap serangan ini dilakukan dengan mengirimkan data rahasia
seperti username, melalui HTTPS.
password,
dan
token
c Passwords Attacks Seorang hacker dapat menemukan password menggunakan program tertentu atau dengan hanya menebak-nebak password yang mungkin digunakan korban. Menurut Scarfonce dan Souppaya (2009), password yang kuat dapat mencegah pembobolan password. Kekuatan password ditentukan oleh panjang password dan kompleksitas yang sangat bergantung pada karakter-karakter yang sulit diprediksi. Untuk mencegah password attack, user disarankan menggunakan password yang terdiri atas minimal tiga dari empat grup berikut: lowercase letters, uppercase letters, digits, dan symbols. d Session Hi-jacking Pencegahan terhadap session hi-jacking dilakukan dengan cara menerapkan token yang berlaku hanya dalam jangka waktu tertentu dan penghapusan session yang kadaluarsa secara berkala. e Penggunaan Network Address Translation (NAT) NAT dapat digunakan oleh user ketika user membuat jaringan kecil sendiri di dalam jaringan internet IPB. Alamat IP yang terbaca oleh load balancer, proxy, dan server SSO IPB adalah alamat IP komputer yang menjadi gateway pada jaringan NAT tersebut. Akibatnya, ketika satu komputer yang berada dalam jaringan NAT telah terautentikasi pada proxy IPB, semua komputer yang berada dalam jaringan tersebut dapat melakukan akses internet tanpa harus terautentikasi satu per satu. Masalah ini masih belum teratasi oleh sistem SSO IPB karena session pada proxy ditentukan berdasarkan alamat IP user. f
Cross Site Request Forgery (CSRF) CSRF terjadi ketika seorang penyerang memberikan sebuah Uniform Resource Identifier (URI) berbahaya melalui email atau image yang telah disisipi sebuah script berbahaya. URI tersebut mengarahkan korban untuk meminta token kepada server SSO dan memberikannya kepada pelaku CSRF melalui URI yang telah ditentukan pelaku. CSRF dapat diatasi pada penggunaan protokol OAuth 2.0 karena protokol ini mewajibkan adanya state yang bernilai unik untuk setiap permintaan token .
12
g Cross Site Scripting (XSS) XSS merupakan penyisipan script dari pihak ketiga melalui URI, form, maupun input user lainnya. XSS dapat diatasi dengan mengaktifkan modul XSS yang telah ada pada framework Codeigniter. Modul ini berfungsi memfilter semua input dari user sebelum input tersebut diproses atau dijalankan. Perbandingan Penggunaan MySQL, File Lokal, dan Web Service Sebagai Aplikasi Eksternal pada Proxy Dalam pengujian ini, dilakukan pengamatan terhadap kecepatan permintaan status login dari proxy ke server SSO IPB. Permintaan status login yang dicoba terdiri atas tiga cara, yaitu: Program eksternal proxy langsung mengakses database pada server SSO. Program eksternal proxy mengakses file lokal yang disinkronisasi dengan file session di server SSO IPB. Program eksternal proxy mengakses web service pada server SSO IPB. Sebagai data pengujian, ditentukan jumlah user yang tersimpan dalam session: 10, 20, 30, 40, dan 50. Pada masing-masing jumlah
session tersebut, diambil seratus permintaan status login dari proxy ke server SSO IPB. Hasil pengamatan terhadap kelima data dapat dilihat pada Tabel 3 sehingga diperoleh grafik pada Gambar 10. Pada grafik tersebut, dapat dilihat bahwa perubahan jumlah session yang tersimpan pada server SSO IPB tidak memengaruhi perubahan waktu yang dibutuhkan untuk memperoleh status login user. Akan tetapi, apabila dilihat secara keseluruhan, urutan kecepatan antara penggunaan database, file lokal, dan web service tetap konsisten. Penggunaan file lokal memerlukan waktu paling cepat, diikuti pembacaan database secara langsung, dan yang paling lambat adalah penggunaan web service. Pada pengujian berikutnya, dilakukan pengamatan kecepatan permintaan status login dengan jumlah session yang tersimpan 1, 10, 100, dan 1000 dengan tujuan untuk melihat perubahan kecepatan permintaan status login apabila terjadi penambahan jumlah session yang besar. Pada pengujian ini, diambil seratus permintaan status login untuk masingmasing jumlah session. Hasil pengamatan dapat dilihat pada Tabel 4 sehingga diperoleh grafik pada Gambar 11.
Tabel 3 Kecepatan permintaan status login antara proxy dan server SSO (dalam detik) Jumlah session yang tersimpan
Media
10
20
30
40
50
Database
0.03897
0.04020
0.03570
0.03800
0.03850
File lokal
0.03194
0.03008
0.03195
0.02578
0.03257
Web service
0.07608
0.06640
0.06772
0.11417
0.08187
Gambar 10 Grafik kecepatan permintaan status login antara proxy dan server SSO.
13
Hasil pada percobaan kedua tidak jauh berbeda dengan hasil percobaan pertama. Jumlah session yang tersimpan tidak memengaruhi kecepatan permintaan status login dari proxy ke server SSO IPB. Akan tetapi, urutan kecepatan permintaan status login masih tetap sama, yaitu penggunakan file lokal yang paling cepat, diikuti penggunaan database, dan web service. Nilai kecepatan yang diperoleh pada penggunaan database dan file lokal hampir sama sehingga grafik yang dihasilkan pada Gambar 11 tampak tumpang tindih.
dibutuhkan cepat, namun user perlu menunggu beberapa saat untuk dapat melanjutkan akses internet hingga program Cron pada server SSO IPB melakukan sinkronisasi file session dengan seluruh proxy server. Pada pembacaan database secara langsung dan penggunaan web service, user dapat langsung melanjutkan akses internet seketika setelah melakukan autentikasi pada halaman login SSO IPB. Namun, apabila aliran data yang melalui proxy sangat besar, user akan merasakan akses internet yang lambat karena proxy harus membaca database atau web service setiap menerima request dari user. Dengan demikian, untuk memperoleh kecepatan akses internet yang optimal melalui proxy, perlu digunakan file lokal maupun penggunaan database. File lokal digunakan setelah terjadi sinkronisasi file, sedangkan database atau web service digunakan sebelum terjadinya sinkronisasi file antara proxy dan server SSO IPB.
Berdasarkan kedua percobaan pengukuran kecepatan permintaan status login, diperoleh kesimpulan bahwa program eksternal yang paling cepat berjalan adalah penggunaan file lokal, diikuti database dan web service. Akan tetapi, perlu dipertimbangkan bahwa ketiga mekanisme tersebut memiliki kelebihan dan kekurangan lain. Pada penggunaan file lokal, waktu yang
Tabel 4 Kecepatan permintaan status login antara proxy dan server SSO (dalam detik) Jumlah session yang tersimpan
Media
1
10
100
1000
Database
0.03742
0.03897
0.04574
0.04418
File lokal
0.03136
0.03129
0.04574
0.03440
Web service
0.47729
0.44847
0.53407
0.46038
Gambar 11 Grafik kecepatan permintaan status login antara proxy dan server SSO.
