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 requestuser 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 server
-server 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 aturan-aturan 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, requestuser 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 IPByang 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
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.
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 SERVER SSO IPB
Database SERVER PROXY Program eksternal Squid Squid File Web service SERVER SSO IPB
Database SERVER PROXY Program eksternal Squid Squid File File
SERVER SSO IPB
Database SERVER PROXY Program eksternal Squid Squid
Gambar 6 Mekanisme pembacaan session proxy dengan web service. Gambar 5 Mekanisme pembacaan session
proxy dengan file lokal.
Gambar 4 Mekanisme pembacaan session proxy dengan database.
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.
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
Gambar 7 Rancangan proses logout SSO IPB.
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
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 X-Forwarded-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. Gambar 8 Rancangan antarmuka login form.
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
Pengujian Keberhasilan Sign-on
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
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 webdi 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
Mekanisme Hasil
Proxy membaca database berhasil
Proxy membaca file lokal 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, password, dan token
melalui HTTPS. 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 masing-masing jumlah session. Hasil pengamatan dapat dilihat pada Tabel 4 sehingga diperoleh grafik pada Gambar 11.
Gambar 10 Grafik kecepatan permintaan status login antara proxy dan server SSO. Tabel 3 Kecepatan permintaan status login antara proxy dan server SSO (dalam detik)
Media Jumlah session yang tersimpan
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
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.
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
dibutuhkan cepat, namun user perlu menunggu beberapa saat untuk dapat melanjutkan akses internet hingga program Cron pada server SSO IPB melakukan sinkronisasi filesession 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.
Gambar 11 Grafik kecepatan permintaan status login antara proxy dan server SSO. Tabel 4 Kecepatan permintaan status login antara proxy dan server SSO (dalam detik)
Media Jumlah session yang tersimpan
1 10 100 1000
Database 0.03742 0.03897 0.04574 0.04418
File lokal 0.03136 0.03129 0.04574 0.03440
