Anda di halaman 1dari 7

IMPLEMENTASI TEKNOLOGI SINGLE SIGN ON DI LINGKUNGAN TEKNIK INFORMATIKA ITS

Deden Ade Nurdeni Wahyu Suadi, S.Kom., M.Kom.


Fakultas Teknologi Informasi,
Institut Teknologi Sepuluh Nopember (ITS), Surabaya, 60111, Indonesia
E-mail: deden_and@yahoo.com

Diambil sebagai contoh, Institut Teknologi Sepuluh


Nopember (ITS) khususnya jurusan Teknik
Informatika memiliki layanan aplikasi untuk civitasnya
yang sangat kompleks, untuk dapat mengakses sistem
layanan aplikasi tersebut, harus melewati sebuah proses
autentifikasi yang berbeda-beda pada setiap aplikasi.
Dari sini akan timbul kesulitan untuk mengelola login
tersebut jika seorang pengguna memiliki login yang
berbeda-beda untuk setiap sistem aplikasi, dengan
demikian seseorang harus menghapalkan banyak
username dan password.
Oleh karena itu diperlukan suatu sistem portal, yang
dapat mengintegrasikan seluruh layanan aplikasi ini
dan mengelola proses autentifikasi pada masingmasing sistem layanan, menjadi satu proses
autentifikasi. Proses autentifikasi pada sistem yang
terintegrasi ini memerlukan sebuah sistem tambahan
yang menjadi penghubung antara sistem integrator dan
sistem layanan aplikasi. Sistem inilah yang menangani
seluruh proses autentifikasi pada masing-masing sistem
layanan aplikasi, yang biasa dikenal dengan sistem
Single Sign-On (SSO).

Abstrak
Perkembangan teknologi komputer dewasa ini
sangat pesat, terlebih lagi ketika ditemukannya
teknologi jaringan komputer dan internet. Seiring
dengan perkembangan internet, banyak dibangun
sistem yang bersifat real-time dan online, yang
memungkinkan seseorang dapat mengaksesnya dari
mana saja dan mendapatkan informasi terkini. Sistem
tersebut dibangun sendiri sendiri (stand alone) dan
banyak yang membutuhkan user identity yang unik
agar dapat mengakses sistem tersebut.
Jurusan Teknik Informatika mempunya berbagai
macam aplikasi web based dalam menunjang aktivitas
akademiknya, seperti web berbagai macam praktikum,
web kuliah virtual, web monitoring TA, web
perpustakaan digital dan web perkuliahan. Semua
akses ke aplikasi-aplikasi tersebut masing-masing
merlukan otentikasi user yang unik untuk seorang
mahasiswa atau user. Hal ini menyebabkan user akan
melakukan proses login berkali-kali.
Teknologi Single Sign On memberikan kemudahan
kepada user untuk proses otentikasi. User hanya perlu
melakukan satu kali login untuk mengakses semua
aplikasi yang ada. Teknologi ini memerlukan satu buah
user identity yang unik untuk seorang user yang
disimpan dalam sebuah credential store. Otentikasi
dari semua aplikasi yang ada diatur oleh sebuah
server otentikasi (Central Authentication Services)
yang menangani validasi dan authorisasi user identity
yang tersimpan dalam server yang menyimpan
informasi user tersebut. Server Otentikasi ini
memberikan sebuah karcis atau Services Ticket ke
browser user di sisi client jika identitas user sama
dengan identitas user di server database. Ticket
Services ini digunakan browser untuk mengakses
aplikasi lain yang memerlukan otentikasi tanpa
melakukan login kembali.

2. Single Sign On (SSO)


Teknologi Single-sign-on (sering disingkat menjadi
SSO) adalah teknologi yang mengizinkan pengguna
jaringan agar dapat mengakses sumber daya dalam
jaringan hanya dengan menggunakan satu akun
pengguna saja. Teknologi ini sangat diminati,
khususnya dalam jaringan yang sangat besar dan
bersifat heterogen (di saat sistem operasi serta aplikasi
yang digunakan oleh komputer adalah berasal dari
banyak vendor, dan pengguna dimintai untuk mengisi
informasi dirinya ke dalam setiap platform yang
berbeda tersebut yang hendak diakses oleh pengguna).
Dengan menggunakan SSO, seorang pengguna hanya
cukup melakukan proses autentikasi sekali saja untuk
mendapatkan izin akses terhadap semua layanan yang
terdapat di dalam jaringan.[2]
Keuntungan sebuah system menggunakan SSO
adalah sebagai berikut :
Mengurangi tingkat kejenuhan user dalam
penggunaan password.
Mengurangi waktu yang digunakan untuk
memasukkan password kembali untuk sebuah
identitas yang sama.
Dapat mendukung otentikasi konvensional seperti
Windows Credential.
Mengurangi biaya IT seiring dengan berkurangnya
user yang meminta bantuan mengenai hal
otentikasi yagn dalam hal ini adalah permaslah di
username atau password

Kata Kunci : Single Sign-On, otentikasi, user


identity. Central Authentication Services, security
1. Pendahuluan
Perkembangan Teknologi Informasi yang begitu
cepat ditunjang dengan berbagai penemuan dan inovasi
telah membawa banyak perubahan dalam kehidupan
manusia. Semakin banyak hal dan aspek dalam
kehidupan yang menggunakan IT untuk menjalankan
roda aktivitasnya.
Dampaknya adalah banyak aplikasi yang dibuat
oleh programmer untuk berbagai macam keperluan
untuk menunjang produktivitas dan efektivitas kerja.
Salah satu implementasi aplikasi tersebut adalah
aplikasi web based dengan berbagai fungsionalitasnya.

Gambar 1 Ilustrasi PKI dalam SSO


4. Lightweight Directory Access Protocol (LDAP)
LDAP (Light Weight Directory Access Protocol)
adalah sebuah protokol yang mengatur mekanisme
pengaksesan layanan direktori (Directory Service)
yang dapat digunakan untuk mendeskripsikan banyak
informasi
seperti
informasi
tentang
people,
organizations, roles, services dan banyak entitas
lainnya. LDAP menggunakan model client-server,
dimana client mengirimkan identifier data kepada
server menggunakan protokol TCP/IP dan server
mencoba mencarinya pada DIT (Directory Information
Tree) yang tersimpan di server. Bila di temukan maka
hasilnya akan dikirimkan ke client tersebut namun bila
tidak maka hasilnya berupa pointer ke server lain yang
menyimpan data yang di cari.
Gambar 2 menunjukkan model dari struktur sebuah
directory. Secara prinsip struktur database pada suatu
directory service adalah hierarki seperti yang di
tunjukkan pada gambar di atas. Suatu directory service
akan memiliki item yang di jadikan sebagai root. Untuk
sebuah titik root, secara umum di tunjukkan dengan
suatu attribut dc (Domain Component) atau o
(Organization) mungkin juga ou (Organization Unit).
Kemudian pada titik daun (leaf) biasanya akan berisi
item dengan attribut uid (User ID) ataupun cn
(Common Name). Directory service biasanya
menyimpan informasi dalam bentuk struktur tree yang
dinamakan Directory Information Tree (DIT).[4]

Keamanan di semua level akses baik masuk


maupun keluar system.[2]

3. Public Key Infrastructure (PKI) dalam SSO


PKI dengan basis SSO memungkinkan proses
kriptografi public key untuk mengidentifikasi user.
User membuat sertifikat digital. Sertifikat digital
adalah sebuh kartu kredit elektronik yang memuat
data credential user ketika melakukan aktifitas
otentikasi pada website. Sertifikat ini diatur oleh
Certification Authority (CA). CA terdiri dari nama,
serial number, tanggal expired, salinan sertifikat
pemegang public key (digunakan untuk mengenkripsi
pesan dan tanda tangan digital), dan tanda tangan
digital untuk otorisasi sertifikat sehingga user dapat
memverifikasi bahwa sertifikat itu benar. Beberapa
sertifikat digital memenuhi standar X.509. Sertifikat
digital ini dapat disimpan di registry sehingga pada saat
proses otentikasi user dapat mencari public key user
lain.
PKI dalam sistem Single Sign-On memerlukan
sebuah Directory Services, seperti LDAP (Ligtweight
Directory Access Protocol). LDAP akan dijelaskan
pada sub bab setelah ini. LDAP menyimpan informasi
pribadi user dalam direktori dan memerlukan public
key. Direktori ini mungkin juga berisi daftar sertifikat
yang sudah expired dan akan dibuang.
Private key merupakan sekumpulan string bit yang
panjang, biasanya dalam format Base64. Private key
harus dijaga dengan aman, setelah seorang hacker
mendapatkan private key, mereka dapat bertindak
sebagai pemilik dari private key. Biasanya, private key
disimpan di perangkat keras seperti USB, atau smartcard. Private key harus dilindungi oleh sebuah passphrase,
untuk memastikan bahwa hanya yang
memiliki private key yang dapat menggunakannya.
Gambar 1 menunjukkan sistem PKI dalam SSO.
Ketika seorang user mencoba untuk mengakses sebuah
remote resource, maka user tersebut akan menciptakan
sebuah request, termasuk sertifikat digital dirinya
(berisi public key) dan menandainya dengan private
key. Request diterima oleh server yang sebelumnya
telah terhubung dengan server LDAP untuk
memverifikasi public key dari user tersebut benar.
Pada tahap ini memungkinkan penyerang mengganggu
paket di jaringan, dan dapat melakukan serangan reply
attack.
Untuk
alasan
ini
server mengirim tanda kepada klien dengan semacam
puzzle yang sederhana, hanya pemilik dari private key
akan dapat mengirim kembali jawaban dari tanda
tersebut.[3]

Gambar 2 Model directory


5.

Perancangan Sistem Server SSO


Dengan pendekatan Broker, dalam sistem SSO ini
akan dibangun sebuah server otentikasi yang
selanjutnya kami sebut dengan istilah Central
Authentication Server Informatika ITS (CASIF-ITS)
yang berfungsi untuk melakukan otentikasi dan
otorisasi user serta memberikan ticket elektronik atau
Services Ticket (ST) ke client. Dengan tiket ini user
dapat melakukan akses ke beberapa aplikasi yang
masing-masing memerlukan otentikasi user, ST
mempermudah user karena tidak perlu melakukan
proses login disetiap aplikasi karena proses login hanya
dilakukan satu kali ketika mengakses aplikasi yang
pertama. Manajemen data user yang digunakan dalam
sistem ini menggunakan struktur internal dari LDAP
directory yang dihandle oleh sebuah server LDAP.
Dengan struktur directory ini setiap identitas user
dimasukkan dalam entry directory berdasar pada level
aksesnya.

CASIF-ITS untuk melakukan proses validasi user


dan tiket. Gambar 4 adalah diagram alir dari
system CASIF-ITS beserta contoh akses URL
yang terjadi dalam lingkungan sistem ini.

Untuk menjaga keamanan data, sistem ini


menggunakan protokol Transport Layer Security (TSL)
untuk komunikasi antar server CASIF-ITS dan server
LDAP serta ntuk komunikasi antara client dan server
CASIF-ITS.

Gambar 3 Arsitektur System CASIF-ITS


Gambar 3 diatas menunjukkan overview utama
sistem CASIF-ITS yang akan dibangun. Dari arsitektur
diatas sistem ini terdiri dari beberapa bagian:
User : dalam hal ini adalah civitas akademik
teknik Informatika ITS yang akan mengakses
aplikasi web based (1).
Aplikasi : aplikasi web based yang membutuhkan
otentikasi dan otorisasi user untuk aksesnya. Oleh
karena itu user harus melakukan proses login
terlebih dahulu. Dalam sistem ini proses otentikasi
user semua dihandle oleh CASIF-ITS server, maka
aplikasi langsung meredirrect ke CASIF-ITS bila
user belum terotentikasi (2).
Otentikasi dan Pemberian Services Ticket:
Otentikasi dan pemberian service ticket ke client
ditangani oleh server CASIF-ITS, user akan
memasukkan user credential berupa username dan
password (3).
Management User : informasi dari proses login
diatas akan diotentikasi dengan meng-queri useridentity yang ada di server LDAP (4). Jika valid,
server LDAP anak memberitahukan ke server
CASIF-ITS(5). Selanjutnya CASIF-ITS akan
meredirrect kembali ke aplikasi dengan
menyertakan service tiket kepada user (6). Tiket
ini akan memberitahukan ke aplikasi bahwa user
telah terotentikasi dan tidak perlu melakukan
proses logi lagi ketika mengakses Aplikasi yang
lain.
Pada tahapan selanjutnya setelah user
melakukan proses login ke CASIF-ITS server dan
mendapat tiket ke aplikasi pertama, maka user
akan melakukan akses ke aplikasi lain dengan
browser yang sama sebelum browser tersebut
ditutup dan sebelum melakukan logout dari
CASIF-ITS. Pada kasus ini, user tidak perlu
melakukan otentikasi lagi karena sudah mempunya
credential user dan tiket yang tersimpan dalam
cookie browser yang digunakan user. Namun
secara backend system akan meredirect ke server

Gambar 4 Diagram CASIF-ITS


6.

Perancangan aplikasi client

G
ambar 5 Model implementasi aplikasi client
Aplikasi disini adalah beberapa aplikasi website
dimana seorang user mempunyai hak akses disemua
aplikasi tersebut tetapi masing-masing dari aplikasi
memerlukan otentikasi dan otorisasi user. Overview
dari aplikasi sistem ini digambarkan pada gambar 5.

Koneksi secure SSL terjadi diantara aplikasi


client dengan server CASIF-ITS ketika proses
otentikasi. Sedangkan komunikasi antara Server
CASIF-ITS dengan LDAP server berada pada
lingkungan yang secure karena user tidak diijinkan
melakukan komunikasi langsung ke server LDAP.
Gambar 7 menunjukkan model arsitektur sistem
keamanan CASIF-ITS.

Aplikasi yang akan dibangun memiliki lingkungan


pengembangan sebagai berikut:
1. Aplikasi A
Aplikasi ini dibangun berada dalam lingkungan
opensource yakni menggunakan web server dan bahasa
pemrograman yang free sekaligus banyak digunakan
dalam pembangunan aplikasi website di kampus
Teknik Informatik.
- Web Server
: Apache2
- Bahasa pemrograman
: PHP5
- Database
: MySQl 5.0
2. Aplikasi B
Aplikasi ini berada dalam lingkungan Microsoft
dengan teknologi website nya.
- Server
: IIS 5.0
- Bahasa Pemrograman : ASP.Net dengan C#
- IDE
: Visual Studio 2005
- Framework
:Microsoft.Net
Framework3.0
Gambar 6 dibawah menunjukkan aplikasi yang berada
pada lingkungan SSO CASIF-ITS.

8.

Uji Coba Server CASIF-ITS (stand alone)


Gambar 8 adalah snapshoot dari halaman login
server CASIF-ITS yang langsung kita akses di URL
utamanya. URL dari CASIF-ITS.

Gambar 8 Halaman login CASIF-ITS


Selanjutnya kita mempunyai sebuah user ujicoba
dengan nama user deden dengan password rahasia
yang tersimpan dalam struktur directory di LDAP
server. Dengan username dan password tersebut kita
akan melakukan login.

Gambar 6 Model otentikasi Aplikasi dengan sistem


SSO CASIF-ITS
7. Model Security
Perancangan security dari system SSO CASIFITS dengan menggunakan protoko Hypertext Transfer
Protocol Secure (HTTPS) dalam komunikasi server
CASIF-ITS dengan aplikasi client dalam lingkungan
SSO CASIF-ITS. Server CASIF-ITS menggunakan
layer security Security Socket Layer (SSL) dengan
membangun self signed certificate dibagian server serta
menyakinkan semua client yang berada dalam
lingkungan CASIF-ITS ini dapat berkomunikasi secara
secure dengan sertifikat tersebut.

9.

Uji Coba Aplikasi


Sekenario pertama adalah dengan akses aplikasi
website PHP. Aplikasi ini mempunyai URL :
http://10.151.31.234/CAS102/web.php , jika kita
mengakses situs ini untuk pertama kali yang artinya
belum mendapatkan ticket, maka kita akan diredirect
ke halaman login CASIF-ITS dengan tambahan query
string dari URL aplikasi PHP. Gambar 9 menunjukkan
redirect ke CASIF-ITS.

Gambar 9 Halaman login CASIF-ITS dari aplikasi


PHP

Gambar 7 Model security sistem CASIF-ITS

Proses selanjutnya adalah user akan melakukan


proses otentikasi dengan memasukkan username dan
password. Jika berhasil maka user akan diredirect
kembali ke URL aplikasi yang dituju diawal dengan
mendapatkan parameter response sebuah baris ticket.
Halaman utama dari aplikasi PHP ini akan
mendapatkan username dari user yang berhasil
melakukan otentikasi. Gambar berikut adalah halaman
aplikasi PHP setelah user berhasil melakukan
otentikasi.

Uji coba server dengan mengirimkan thread


request sejumlah 1, 10, 50, 100, 200, 300 dan 500 buah
secara bersamaan dalam satu waktu. Hal ini
mensimulasikan ketika user melakukan akses ke
aplikasi yang berada dilingkungan CASIF-ITS secara
bersamaan. Berikut table hasilnya.
Akses
ke
URL
https://10.151.31.234/CASIFITS/login?service=http://10.151.31.234/CAS102/web.p
user

Waktu (milisecond)

rata-rata
35

10

respon error
(%)

minimal
35

maksimal
35

186

135

282

50

974

283

2065

100

4211

918

11283

200

8022

21110

14

300

9200

22771

500
hp

8066

33281

43,80

Tabel 1 Tabel response time server CASIF-ITS


sekenario pertama
Gambar 10 Halaman utama aplikasi PHP sekenario
pertama
Sekenario kedua adalah ketika user telah berhasil
melakukan otentikas dan sukses di aplikasi PHP maka
user akan mencoba mengakses aplikasi lainnya dalam
hal ini aplikasi di lingkungan ASP.Net dengan
menggunakan browser yang sama dan tanpa
melakukan logout terlebih dahulu.
Gambar 11 menunjukkan halaman utama dari
aplikasi ASP.Net langsung dapat ditampilkan tanpa
melakukan otentikasi ke server CASIF-ITS terlebih
dahulu. URL dari aplikasi ASP.Net adalah
http://10.151.32.181:4528/dotNet/Default.aspx . Pada
sekenario kedua ini, username langsung dapat
ditampilkan dan URL dari halaman ASP.Net
mendapatkan response barisan deret ticket yang
berbeda dari aplikasi PHP.

Dalam table 1 diatas waktu rata-rata adalah waktu


respon rata-rata server dalam merespon request, waktu
minimal adalah waktu terkecil yang dibutuhkan
menyeselsaikan satu request dan waktu maksimal
adalah waktu terlama server melakukan respon. Respon
error adalah prosentase jumlah respon yang error dari
server CASIF-ITS. Hal ini menunjukkan kelemahan
server dalam menangani beban request yang overload
dalam waktu yang bersamaan.
10.2 Skenario Kedua
Sekenario kedua dengan memberikan beban
request ke server CASIF-ITS dengan format waktu
delay 0.05 detik untuk setiap kali request. Sekenario
kedua mempunyai jumlah user uji coba yang sama
dengan sekenario pertama yaitu 1, 10, 50, 100, 200,
300 dan 500 user dengan menakses URL
https://10.151.31.234/CASIFITS/login?service=http://10.151.31.234/CAS102/web.p
hp . Berikut adalah table hasil response time server
CASIF-ITS untuk sekenario kedua.
user

Waktu (milisecond)
rata-rata

Gambar 11 Halaman utama apliasi ASP.Net sekenario


kedua

minimal

maksimal

40

40

40

10

255

167

587

50

1536

1028

2025

100

264

13

3048

200

332

14

3005

300

1423

13

6334

500

10. Uji Coba Performa Server CASIF-ITS


10.1 Skenario Pertama

respon error
(%)

0
1508
13
18967
Tabel 2 Tabel response time server CASIF-ITS
sekenario kedua

Dari table 2 diatas dapat diketahui tidak ada


response error dari server karena server dapat
melakukan respon dengan baik dari setiap request.
Gambar 12 dan 13 beriut adalah grafik dari hasil diatas.

11.2 Skenario Kedua


Sekenario pertama adalah dengan melakukan
request search ke server sejumlah 1, 10, 50, 100, 200,
300 dan 500 request dengan format delay 0,05 second
setiap request. Request search directory dengan alamat
cn=admin,dc=ncc,dc=its-sby,dc=edu.
user
respon error
Waktu (milisecond)
(%)
rata-rata minimal maksimal
1
0
1
1
1

Gambar 12 Grafik respons rata-rata CASIF-ITS


sekenario pertama

10

24

50

34

172

100

236

200

26

714

300

11

1839

500
0
2
1
45
Tabel 4 Tabel response time server LDAP
sekenario kedua
Tabel 4 menunjukkan hasil response time server
LDAP, server dapat dengan baik menyelesaikan thread
respon dari user. Pada gambar 14 dan gmabar 15
dibawah menunjukkan grafik dari response time ratarata uji coba server.

Gambar 13 Grafik respon rata-rata CASIF-ITS


sekenario kedua
11. Uji Query Coba Server LDAP
Uji coba sekenario pada server LDAP
menggunakan mekanisme dan metode yang sama
dengan uji coba pada server CASIF-ITS. JMeter akan
melakukan uji coba server LDAP dengan model
request search susunan directory

Gambar 14 Grafik respon server LDAP sekenario


pertama

11.1 Skenario Pertama


Sekenario pertama adalah dengan melakukan
request search ke server sejumlah 1, 10, 50, 100, 200,
300 dan 500 request. Request search directory dengan
alamat cn=admin,dc=ncc,dc=its-sby,dc=edu. Tabel 3
dibawah menunjukkan hasil response time pada
ujicoba sekenario pertama
user
respon error
Waktu (milisecond)
(%)
ratarata

minimal

maksimal

10

25

50

62

302

100

41

311

200

29

481

300

26

228

500

0,2
422
0
1719
Tabel 3 Tabel response time server LDAP
sekenario pertama

Gambar 15 Grafik respon server LDAP sekenario


kedua
12.
Kesimpulan
Dari hasil pengamatan selama perancangan,
implementasi, dan proses uji coba sistem yang
dilakukan, dapat diambil kesimpulan sebagai berikut :
1. Sistem CASIF-ITS berhasil mengimplementasi
teknologi Single Sign On aplikasi web site dengan
model pendekatan berbasis Broker di lingkungan
Teknik Informatika ITS.

2.

3.

4.

5.

6.

Aplikasi-aplikasi client di lingkungan SSO


CASIF-ITS
dapat
dikembangkan
dalam
lingkungan platform yang berbeda.
Self Signed Certificate dapat digunakan dalam
membangun koneksi secure dengan protokol
HTTPS di sistem SSO CASIF-ITS.
Leighweight Directory Access Protocol (LDAP)
dapat digunakan sebagai pusat manajemen user
sistem SSO.
Response time dari server ke client meningkat
berbanding dengan meningkatnya jumlah user
yang mengakses server dalam waktu yang
bersamaan.
Beberapa response error dari server terjadi ketika
server diakses 200 atau lebih user dalam waktu
yang bersamaan.

13.

Saran
Berikut
adalah
beberapa
saran
untuk
pengembangan sistem Single Sign On pada masa yang
akan datang.
1. Untuk lebih menjaga keamanan data, komunikasi
client server menggunakan koneksi secure SSL
dengan menggunakan sertifikat yang Thrusted
dari Certificate Authory bukan hanya sekedar self
signed certificate.
2. Sistem ini belum memiliki manajemen Otorisasi
user disetiap level hak akses karena user hanya
memiliki satu buah hak akses untuk itu perlu
dikembangkan metode pembagian hak akses user
yang berbeda di setiap aplikasi yang berbeda.
14. Daftar Pustaka
[1] Allen Adam,. 2003, BSc(Hons) Networks
and Communications.
[2] Hursti Jani., 1997, Single Sign On.
Department of Computer Science Helsinki
University of Technology
[3] Munir, Rinaldi., 2006, Kriptografi. Penerbit
Informatika Bandung
[4] Sukmana Ratdhian C., 2006, Pengenalan
LDAP. <URL http://ratdix.wordpress.com>
Diakses tanggal 02-06-2009
[5] Wikipedia
<URL
:
http://en..wikipwdia.org/single-sign-on
>
Diakses tanggal 02-06-2009.
[6] Wikipedia
<URL
:
http://en.wikipedia.org/wiki/Lightweight_Dire
ctory_Access_Protocol
> Diakses tanggal
02-06-2009.

Anda mungkin juga menyukai