pengembangan model single sign-on untuk

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.