IMPLEMENTASI SISTEM SINGLE SIGN ON/ SINGLE SIGN OUT BERBASIS CENTAL

AUTHENTICATION SERVICE PROTOCOL PADA JARINGAN BERBASIS

LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL
Muhammad Yanuar Ary Saputro1),Kodrat Iman Satoto2)Adian Fatchur Rochim2)
Jurusan Teknik Elektro, Fakultas Teknik, Universitas Diponegoro,
Jln. Prof. Sudharto, Tembalang, Semarang, Indonesia
email : technaturology@gmail.com

ABSTRACT
Web applications are currently growing due to the reliability and modularity of web programming language that they used. No
wonder in company or agency have webmail applications, blogs, information systems, ftp and many other web applications. It is very
heartening, but there is one problem thata are there still have too many login process. Login can be used by the same username and
password on each application through an integrated database on all application. But, when we open an application, we must still
doing login process. So it needs a System Single Sign On / Single Sign Out, that is when we are doing a login or logout process in one
application, we no longer need to do login or logout in other applications.
The methodology that used in this final research include literature studies, system design, implementation and system testing.
Literature studies using teaching methods based on reference books and papers related to this thesis. Designing systems using the
Linux operating system with the Diponegoro University's LDAP. Implementation is done by building a CMS-based web services,
multiblogging, webcloud and webmail. Authentication services are integrated with System Single Sign On / Single Sign Out CAS
server and LDAP as user data store.
This final research bring result about System Single Sign On / Single Sign Out based on CAS protocol in the LDAP-based network.
SSO server that being used is CAS Server. CAS SSO Server is used as a centralized login page for CMS-based web services,
multiblogging, webcloud and webmail. While the account that used to login is from Diponegoro University's LDAP. Success is
determined by login and logout process on one application.. If one application success in login / logout then other applications will
login / logout automatically.

Keyword : CAS, Single Sign On, Single Sign Out, Authentication, LDAP

I.

aplikasi dan menggunakan sebagian waktunya untuk

proses login yang sama.
Untuk membuat proses login menjadi sederhana,
maka diperlukan sebuah sistem yang disebut Sistem
Single Sign On/ Single Sign Out, yaitu dimana kita hanya
perlu login/logout pada salah satu aplikasi saja, dan tidak
perlu login/logout lagi pada aplikasi lainnya. Sistem
Single Sign On/ Single Sign Out akan memudahkan
pengguna dalam mengakses banyak aplikasi sekaligus.
Pengguna hanya perlu mengingat satu username dan satu
password saja untuk semua aplikasi dan hanya perlu
melakukan satu kali login/logout untuk mengakses semua
aplikasi yang tersedia di Universitas Diponegoro. Salah
satu produk Sistem SSO ini adalah Central
Authentication Services (CAS) yang berbasis Cental
Authentication Service Protocol 2.0. Sedangkan sebagai
user datastore nya digunakan sistem direktori terpusat
berbasis Lightweight Directory Access Protocol (LDAP)
yaitu OpenLDAP.

PENDAHULUAN

Latar Belakang
Perkembangan aplikasi web yang marak telah
membuat Universitas Diponegoro memiliki banyak
aplikasi web yang digunakan untuk meringankan beban
pekerjaan dan mempermudah komunikasi serta
pertukaran informasi dalam linkungan akademis
Universitas Diponegoro. Sebut saja sistem informasi
penggajian, webmail, blog, webcloud, repositori, sistem
informasi akademik dan lainnya.
Hanya saja aplikasi web tersebut masih
dibangun secara tersendiri (stand alone), sehingga
berdampak pula pada banyaknya sistem login, yang
berbeda pada setiap aplikasi web di Universitas
Diponegoro. Kadang kala username dan password
antara satu aplikasi dengan aplikasi yang lainnya
berbeda. Hal ini dikarenakan tidak adanya integrasi basis
data antar aplikasi. Sedangkan bagi yang sudah
terintegrasi basis datanya, hanya ada satu username dan
satu password per-user, akan tetapi tetap saja setiap kali
mengakses aplikasi web tersebut, pengguna harus login
pada setiap aplikasi.
Proses login yang banyaknya sebanyak jumlah
aplikasi yang tersedia, secara tidak langsung
menjenuhkan pengguna. Hal itu dikarenakan pengguna
harus menghafal username dan password pada setiap

1)

Mahasiswa Teknik Elektro UNDIP

2)

Dosen Teknik Elektro UNDIP

Tujuan
1. Mempelajari, merancang dan mengimplementasikan
Sistem Single Sign On/ Single Sign Out berbasis
Cental Authentication Service Protocol di jaringan
berbasis Lightweight Directory Access Protocol
milik Universitas Diponegoro.

2.

Mengintegrasikan
layanan
webmail,
web,
multiblogging, dan webcloud dengan Sistem Single
Sign On/ Single Sign Out berbasis CAS dan LDAP.
Batasan Masalah
Adapun pembatasan masalah pada makalah ini adalah
sebagai berikut :
1. Server CAS menggunakan sistem operasi Linux
distro Ubuntu Server.
2. Integrasi CAS hanya dilakukan pada layanan
webmail, web, multiblogging, dan webcloud serta
otentikasi hanya dilakukan terhadap LDAP.
3. LDAP yang digunakan merupakan openLDAP milik
Universitas Diponegoro.
4. Pembuatan layanan email menggunakan program
open source Postfix untuk mesinnya dan Squirrelmail
untuk aplikasi webnya .
5. Pembuatan layanan web menggunakan joomla.
6. Pembuatan layanan multiblogging menggunakan
Wordpress-MU
7. Hanya digunakan aplikasi web berbasis PHP sebagai
klien CAS
8. Tidak membahas masalah manajemen akun
pengguna, instalasi dan konfigurasi di dalam
openLDAP
II.

Gambar 2.1 Solusi Praktis WAM / SSO

Garis biru menggambarkan trafik antara browser

pengguna dan resource yang coba diakses oleh pengguna.
Garis merah menggambarkan agent SSO yang mencoba
menahan permintaan dan menanyakan pada policy server
apakah resource yang diminta terlindungi, apakah
pengguna terotentifikasi dan apakah pengguna dapat hak
untuk mengaksesnya. Garis ungu menggambarkan policy
server menampilkan perlawanan terhadap policy store
(Huggins,2009).
Pengguna akan ditahan oleh policy server dan
ditanyakan apakah resource terlindungi, ketika pengguna
ingin mengakses suatu resource. Jika tidak maka
pengguna dapat langsung membukanya, jika ya, maka
diajukan pertanyaan apakah pengguna terotentifikasi. Jika
tidak maka otentifikasi pengguna dipertanyakan, jika
ya maka ditanyakan lagi apakah pengguna berhak
mengaksesnya. Jika ya maka pengguna akan dialihkan
ke halaman resource yang diminta tersebut (Twist,2005).
Sehingga bisa disebutkan bahwa policy adalah rules
(apakah resource terproteksi), subject (siapa yang
diijinkan mengakses) dan condition (aturan tambahan
seperti IP, waktu/hari).
CAS (Central Authentication Service)
Central Authentication Servise (CAS) dibentuk
sebagai sebuah aplikasi web yang berdiri sendiri. Untuk
lebih jelasnya dapat dilihat pada gambar dibawah ini.

DASAR TEORI

Sistem Single Sign-On / Single Sign Out

Pengguna di era ini, akan duduk di tempat
kerjanya untuk login ke desktop, login ke emailnya, dan
mungkin login ke banyak halaman web internal, login
dan login lagi. Pengguna harus menghafalkan username
dan password dari semua aplikasi tersebut, karena bila
terjadi kelupaan, dapat menjadi mimpi buruk bagi
pengguna. Akibat dari itu muncullah fungsi reset
password atau lost password?.
Masalah banyakanya akun seringkali
diatasi
dengan diimplementasikan fasilitas direktori terpusat,
seperti LDAP atau Active Directory (AD). Dengan
adanya ini menyederhanakan banyaknya username dan
password pada sistem berbasis web. Akan tetapi
pengguna tetap harus login atau logout pada setiap
aplikasi. Untuk mengatasi hal ini digunakanlah Sistem
Web Access Management (WAM) atau yang biasa kita
kenal dengan nama Sistem Single Sign-On/Single SignOut (SSO). Dengan adanya SSO, kita hanya perlu satu
kali login atau logout untuk semua aplikasi berbasis
web.
Pengimplementasikan
WAM
atau
SSO,
memerlukan
beberapa
komponen
yang perlu
diperhatikan, yaitu policy server, policy store dan web
agent yang mana terletak pada server web untuk
mengontrol hak akses.

Gambar 2.2 Sistem CAS

URL login menangani otentikasi yang utama.

Karena itu CAS mendorong pengguna dengan sebuah
NetID dan password dan validasinya melawan provider
yang mendukung autentikasi. Pengembang CAS yang
2

berbeda
akan
menghubungkan
bermacam
PasswordHandler untuk mengesahkan username dan
password melawan dukungan mekanisme otentikasi
manapun yang selaras.
CAS juga melakukan usaha untuk mengirimkan
sesuatu dalam memory cookie (ini akan hancur ketika
browser ditutup) kembali ke browser, untuk mencegah
kemungkinan dari pengulangan autentikasi. Cookie ini,
bisa disebut ticket-granting cookie, mengidentifikasi
pengguna sebagai satu yang telah melakukan logged in.
Arsitektur dan Otentikasi CAS
Arsitektur CAS dapat digambarkan dengan
sistem komponen termasuk server, klien yang
berkomunikasi melalui beberapa jenis protocol. CAS
server dan klien CAS merupakan dua komponen sistem
arsitektur CAS yang mengkomunikasi melalui berbagai
protocol (Addison dkk, 2011).

Web browser sendiri harus memenuhi beberapa

persyaratan agar dapat menggunakan fitur CAS,
diantaranya adalah :
- Dapat mendukung SSL, dikarenakan CAS
berjalan dengan baik di HTTPS.
- Dapat menampilkan HTTP redirection dan
mengerti Javascript dasar.
- Menggunakan cookie dan dalam keadaan aktif,
fungsinya untuk menyimpan tiket.
Ketiga persyaratan tersebut tidak perlu
dikhawatirkan lagi saat ini, karena mayoritas browser
saat ini sudah memiliki ketiga fitur tersebut.
Klien CAS
Sebuah aplikasi web yang dilengkapi dengan
library / fungsi CAS klien disebut sebagai klien CAS.
Berguna mengirimkan resource hanya ke klien yang
sebelumnya telah terotentikasi oleh CAS server. Selain
itu klien CAS memiliki satu arti lagi yang berbeda pada
penggunaan umumnya, yaitu aplikasi web yang dapat
diintegrasikan dengan berbagai macam variasi software.
Ada 3 jenis klien CAS :
- Library / fungsi yang berdasarkan bahasa
pemrograman yang digunakan oleh klien (PHP,
ASP .NET, Perl, JSP, Java), yang berfungsi
mengalihkan ke halaman login terpusat CAS, dan
memproses hasil otentikasi oleh CAS Server
- Sebuah modul Apache, digunakan untuk
melindungi dokumen statis.
- Modul PAM, untuk menjembatani otentikasi
pada level sistem / aplikasi desktop.
Otentikasi CAS dengan TGC
Proses otentikasi CAS yang paling sederhana
adalah menggunakan Ticket Granting Cookie (TGC).
Yaitu dimana jika otentikasi dengan CAS berhasil,
maka akan diteruskan kembali ke halaman aplikasi web
klien CAS dengan tiket sebagai bukti otentikasi yang
disimpan di cookie. Tiket ini hanya berlakupada periode
waktu tertentu, dan nilai tidak pernah sama / atau
berubah setiap kali login. Prosesnya secara rinci adalah
sebagai berikut :
- Pertama pengguna yang belum terotentikasi
bersaha mengakses aplikasi web yang telah
terpasang aplikasi klien CAS dengan cara login,
maka akan diteruskan ke halaman login CAS
Server yang meminta pengisian username dan
password.

Gambar 2.3 Arsitektur CAS

CAS Server dan Web Browser

Otentifikasi yang terpusat pada mesin yang unik,
inilah yang disebut CAS Server. Mesin ini hanyalah
aktor yang mengetahui password pengguna. Mesin ini
memiliki 2 peran utama, yaitu :
- Proses otentikasi pengguna
- Mengirim sertifikasi pengguna yang telah
terotentifikasi (ke klien CAS)
Aplikasi CAS Server merupakan aplikasi Java
servlet yang mana dibangung dengan Spring
Framework yang memiliki fungsi utama untuk
otentikasi pengguna dan memberikan akses ke klien
CAS dengan memvalidasi tiket. Session SSO dibuat
saat tiket divalidasi ke pengguna pada kesuksesan
login. Service Ticket (ST) diberikan ke pengguna
melalui browser yang diteruskan menggunakan TGC
sebagai token.

Gambar 2.4 Otentikasi pengguna

Jika username dan password benar maka CAS

Server akan mengirimkan TGC ke browser.

CAS Protocol merupakan protokol berbasis tiket

yang sederhana dan kuat yang dikembangkan secara
eksklusif untuk CAS. Protokol CAS memiliki 2 versi,
versi 1 merupakan protokol berbasis teks sederhana,
sedangkan versi 2 merupakan protokol berbasis XML
yang mendukung bentuk otentikasi yang tidak diketahui
yaitu Otentikasi berbasis Proxy. CAS merupakan salah
satu dari berbagai produk SSO. Perangkat lunak CAS
Server sejak versi 3.4 meliputi protocol CAS v1 dan CAS
v2. Sedangkan untuk proses Single-Sign-Out nya
menggunakan Protokol SAML 1.1 melalui pemanggilan
kembali aplikasi yang berpartisipasi dalam session
Single-Sign-On.

Gambar 2.5 Pengiriman TGC

TGC merupakan passport pengguna terhadap

CAS Server. Masa berlakunya terbatas dan ini
merupakan
cara
dimana
web
browser
mendapatkan tiket tanpa perlu adanya otentikasi
kembali. Ini hanya merupakan identitas session
antara CAS Server dengan web browser.
Sebagai presentasi dari TGC, CAS Server
memberikan Service Ticket (ST) yang hanya dapat
digunakan untuk aplikasi web dengan klien CAS
yang memerlukannya tadi, yang mana dikirimkan
bersamaan dengan diteruskan kembali ke halaman
aplikasi web dengan klien CAS tersebut.

Lightweigth Data Access Protocol (LDAP)

Menurut Carter (2003), pengertian LDAP dibagi
menjadi 3 bagian, yaitu:
Lightweight
Directory
Access Protocol
Lightweight
LDAP pada mulanya dibuat sebagai protokol
desktop yang lebih muda yang digunakan sebagai
gateway untuk X.500 server. X.500 merupakan sebuah
standard. X.500 mendapatkan gelar Heavyweight karena
membutuhkan client dan server untuk berkomunikasi
menggunakan Open System Interface (OSI) protokol.
Tujuh layer OSI ini bagus dalam mengaplikasikan
jaringan protocol suite, tetapi ketika dibandingkan dengan
TCP/IP protocol suite, ini serupa dengan bepergian jauh
dengan barang bawaan yang sangat berat.
LDAP dikatakan ringan (lightweight) karena
menggunakan sedikit pesan diatas udara yang dipetakan
secara langsung pada TCP layer (biasanya port 389) dari
protokol TCP/IP (Carter, 2003). Karena X.500
merupakan layer aplikasi protokol (dalam OSI layer)
maka ini akan membawa lebih banyak bawaan, seperti
network header yang dipasang pada paket pada setiap
layer sebelum akhirnya dikirimkan ke jaringan.

Gambar 2.6 Validasi dengan ST

- Selanjutnya ST divalidasi oleh klien CAS dan

didapatkan data username yang dapat
digunakan untuk mengakses aplikasi web
dengan klien CAS.

Gambar 2.7 Penerusan ke klien

Melalui mekanisme ticketing ini tidak ada lagi

informasi password yang disimpan dalam session
maupun cookie, karena telah digantikan oleh tiket, yang
mana masa berlakunya singkat dan hanya dapt
digunakan satu kali saja untuk setiap aplikasi (OneTime-Ticket).

Gambar 2.8 X.500 dengan OSI Vs LDAP dengan TCP/IP

LDAPv3 hanya memiliki sembilan operasi utama

dan menyediakan model sederhana untuk programmer
dan administrator. Menyediakan satu set operasi yang
lebih kecil dan sederhana yang mengijinkan pengembang
untuk fokus pada seluk-beluk dari program tanpa harus
mengerti keunggulan dari protokol yang jarang
digunakan. Dengan jalan ini pembuat LDAP berharap
untuk meningkatkan penggunaan dengan menyediakan
pengembangan aplikasi yang lebih mudah.

Central Authentication Services Protocol (CAS

Protocol)
Klien selalu berkomunikasi dengan server
melalui beberapa protokol yang didukung. Semua
protocol yang didukung pada prinsipnya adalah sama,
akan tetapi hanya beberapa fungsi atau karakteristik
yang membuatnya sesuai untuk aplikasi atau kondisi
tertentu. Sebagai contoh CAS Protocol mendukung
otentikasi dengan proxy dan protocol SAML mendukung
pelepasan attribute dan Single-Sign-Out.
4

Directory
Perlu diingat bahwa servis direktori dan basis
data memiliki karakteristik masing-masing, seperti
pencarian cepat dan schema yang dapat diperluas.
Perbedaannya adalah direktori dibuat untuk dibaca lebih
banyak dari pada ditulis. Sedangkan untuk basis data
diasumsikan untuk operasi baca dan tulis memiliki
frekuensi yang sama. Asumsi bahwa direktori dibaca
lebih sering dari pada ditulis merupakan suatu
keunggulan yang spesifik untuk sebuah basis data,
seperti dukungan untuk transaksi dan menulis lock
merupakan sesuatu hal yang tidak penting untuk servis
direktori seperti LDAP.
Titik penting untuk membedakan antara LDAP
dengan backend yang digunakan untuk menyimpan data.
Ingat bahwa LDAP hanya sebuah protokol, yang penting
adalah LDAP adalah sebuah set dari pesan yang
digunakan untuk mengakses data yang spesifik. Protokol
ini tidak mengatakan apapun tentang dimana data
disimpan.

Operasi Klien LDAP

Salah satu topik paling nyata yang termasuk
interaksi client-server adalah client LDAP itu sendiri.
Software client merupakan kunci untuk people
menemukan direktori LDAP yang berguna dan mudah
untuk digunakan. Menurut Arkills (2003), semua operasi
LDAP terdiri dari client yang mengirimkan operasi
request sepanjang dengan parameter ke server. Server
kemudian menjalankan operasi dan mengirimkan sebuah
kode hasil kembali ke client.
Operasi search mempunyai banyak parameter
yang mengubah bagaimana server menjalankan operasi.
Parameter search hanya mempengaruhi sebuah operasi
search untuk yang telah diatur. Untuk mengubah semua
operasi LDAP untuk sebuah session, harus menggunakan
LDAP option, jika ada salah satu yang sesuai.
Ada beberapa parameter search yang wajib,
diantaranya adalah (Arkills, 2003):
Base DN untuk memulai search Base DN
terkadang juga disebut baseObject. Jika tidak
tahu dari mana harus mulai, maka mulailah dari
direktori root. Dalam direktori mycompany, akan
seperti dc=mycompany,dc=com. Jadi pada saat
yang paling minimum, harus mengetahui naming
context dari direktori.
Scope dari search ada tiga pilihan untuk scope.
Scope base berarti hanya mencari satu entry
tunggal pada base DN. Scope one berarti mencari
semua entry pada level yang sama pada urutan
tingkatan dalam container dari base DN. Scope
subtree berarti mencari base DN dan semua entry
di bawah base DN, bagaimanapun juga
tergantung dari level di dalam urutan tingkatan.
Search filter search filter disusun dari sebuah
tipe atribut, sebuah comparison operator, dan
sebuah nilai atribut. Ketiga komponen ini
dikelilingi dengan tanda kurung dan bentuk
sebuah objek search filter. Sintaks yang
sederhana dari objek search filter adalah
"("attributetype
operator
attributevalue")"
dengan tidak ada spasi diantara semua elemen
yang wajib.
Interkoneksi CAS LDAP
Sistem Single Sign On / Single Sign Out dari CAS
hanya dapat melakukan proses otentikasi, tidak dapat
melakukan penyimpanan, pengaturan dan pengintegrasian
data data pengguna seperti username dan password.
Agar dapat melakukan otentikasi terhadap suatu
pengguna,
CAS
melakukan otentikasi
dengan
menggunakan back-end seperti sistem basis data atau juga
bisa menggunakan sistem direktori terpusat (LDAP).
Otentikasi menggunakan sistem direktori
terpusat, memiliki dua mekanisme, yaitu dengan cara
otentikasi secara langsung ke pengguna LDAP (Fast Bind
LDAP) dan dengan cara otentikasi LDAP melaui
pencarian beberapa subtree dan menggunakannya untuk
otentikasi secara langsung (Bind LDAP).
Mekanisme Fast Bind LDAP digunakan bilamana
ingin dilakukan otentikasi secara langsung kepada
pengguna
dengan RDN tertentu. Contoh cn=%u,
dc=mycompany, dc=com, dimana %u merupakan

Gambar 2.9 hubungan antara LDAP client, server, dan data

storage

LDAP server dapat digunakan sebagai backend

storage untuk web server. Semua HTML dan berkas
grafis dapat disimpan dalam direktori dan dapat
dipertanyakan (query) oleh banyak web server.
Disamping semuanya, sebuah web server biasanya
hanya membaca file dan mengirimkannya ke client, file
itu sendiri tidak akan sering diubah. Ketika ini mungkin
untuk mengimplementasikan web server yang
menggunakan LDAP untuk mengakses backend storage,
ada sebuah tipe spesial dari direktori yang telah ada, dan
ini merupakan suite yang lebih baik untuk memenuhi
kebutuhan melayani file, namanya adalah filesystem.
Access Protocol
LDAP merupakan message-based, client/server
protckol yang didefinisikan dalam RFC 2251. LDAP itu
asynchronous (meskipun banyak peralatan development
menyediakan baik blocking dan nonblocking API), ini
berarti bahwa sebuah klien dapat menimbulkan
banyaknya permintaan dan response-nya mungkin
datang dalam urutan yang berbeda ketika permintaan itu
dimunculkan.

Gambar 2.10 LDAP request dan response

username yang didapat dari field username halaman

login CAS Server. Dalam konfigurasi CAS digunakan
FastBindLdapAuthenticationHandler untuk melakukan
hal ini. FastBindLdapAuthenticationHandler terdiri dari
filter properti dari LDAP filter yang akan
digunakan pada proses pencarian. Untuk
mencari username digunakan "%u".
ignorePartialResultException properti ini
memberitahu Spring LDAP untuk mengabaikan
pengecualian terhadap pencarian parsial yang
mana mungkin terjadi saat terkoneksi ke Active
Directory.
contextSource referensi ke LdapContextSource
yang mana berisi setting koneksi ke server
LDAP.
Mekanisme yang kedua yaitu Bind LDAP
digunakan untuk mencari RDN pengguna berdasarkan
filter pencarian yang telah ditentukan lalu
menggunakannya dengan password dari halaman login
CAS. Mekanisme ini biasanya digunakanuntuk
otentikasi terhadap banyak pengguna dengan subtree
yang berbeda-beda akan tetapi memiliki komponen dasar
DN yang sama. Dalam konfigurasi CAS digunakan
BindLdapAuthenticationHandler untuk melakukan hal
ini. BindLdapAuthenticationHandler memiliki beberapa
properti
filter properti yang berupa LDAP filter yang
digunakan untuk pencarian
ignorePartialResultException - properti ini
memberitahu Spring LDAP untuk mengabaikan
pengecualian terhadap pencarian parsial yang
mana mungkin terjadi saat terkoneksi ke Active
Directory.
contextSource - referensi ke LdapContextSource
yang mana berisi setting koneksi ke server
LDAP.
searchContextSource digunakan untuk
operasi pencarian pada LDAP, properti ini
mendukung koneksi berbasis pool pada LDAP
allowMultipleAccounts Mengijinkan lebih dari
satu akun uang dapat dikembalikan.
maxNumberOfResults maksimum jumlah
pencarian.
searchBase dasar pencarian yang mana
merupakan titik awal dimana pencarian akan
dilakukan.
timeout batas waktu lamanya pencarian.

membutuhkan IP Publik. Web server dan mail server

ditempatkan berbeda dengan server LDAP karena
merupakan layanan publik.
Server SSO CAS tersendiri, dibuat terpisah dari
web server karena untuk memudahkan dalam
pengembangan di masa depan termasuk dalam
penambahan penambahan aplikasi web lainnya. Server
CAS ditempatkan terpisah juga agar tidak saling
mengganggu antara Apache dan Apache Tomcat, karena
CAS tidak berjalan pada mesin web Apache melainkan
Apache Tomcat

Gambar 3.1 Topologi Jaringan Sistem yang akan

Dirancang

Gambar 3.1 memperlihatkan bagaimana aplikasi

berjalan dan tampak disisi pengguna. Pengguna akan
melihat tombol login di masing maing aplikasi, saat
pengguna mengakses aplikasi aplikasi web seperti
Webmail, Multiblogging, WebCloud dan web berbasis
CMS,. Bila pengguna menekan salah satu saja tombol
login pada salah satu aplikasi saja maka pengguna akan
diteruskan ke halaman login server SSO CAS.
Server SSO CAS, memiliki halaman login yang
meminta pengguna melakukan pengisian username dan
password. Username dan password tersebut akan
dicocokkan dengan data yang ada di dalam server LDAP.
Pengguna akan diteruskan kembali ke halaman
klien CAS, jika login berhasil, yaitu halaman aplikasi web
yang tadi coba diakses oleh pengguna yang memiliki sub
program untuk koneksi ke klien CAS. Tiket yang
didapatkan dari server SSO CAS akan dicek apakah sama
dengan tiket di server SSO CAS, lalu didapatkan
username dari pengguna. Setelah itu dilakukan
pengecekan pada basis data lokal aplikasi web tersebut,
apakah username tersebut sudah tersedia atau belum. Jika
belum maka dilakukan pembuatan username tersebut
pada basis data lokal aplikasi web tersebut, dengan
menggunakan username yang didapat dari server CAS
dan tingkatan hak akses username yang didapat dari
proses ldap_search Jika username sudah tersedia maka
akan dilakukan proses login, dan pembuatan session dan
cookie lokal pada subdomain aplikasi web tersebut.
Apabila pengguna ingin mengakses aplikasi web
lainnya, maka akan dilakukan pengecekan apakah masih
ada cookie pada server SSO CAS, dalam hal ini disebut
CASTGC. Bila cookie masih ada, maka akan dilakukan
pengecekan tiket yang tersimpan pada CASTGC ke
server SSO CAS, bila sama maka akan dilakukan proses

III.

PERANCANGAN SISTEM
Pada perancangan sistem, menggunakan 3 server
masing masing untuk web server, Server LDAP dan
Server CAS. Layanan Multiblogging, WebCloud,
Webmail dan web berbasis CMS berada dalam web
server. Layanan mail server serta server basis data juga
disatukan dengan web server. Kedua server yang lainnya
adalah server LDAP dan server Single Sign-On / Single
Sign-Out CAS.
Server LDAP dibuat terpisah dikarenakan
server LDAP yang digunakan adalah milik Universitas
Diponegoro, dan juga selain itu server LDAP hanya
digunakan di jaringan lokal sehingga tidak
6

login pada aplikasi web tersebut. Akibatnya saat

pengguna begitu membuka aplikasi web lain setelah
login di salah satu aplikasi web lainnya, maka pengguna
akan langsung masuk ke halaman utama aplikasi web
tersebut tanpa login lagi.
Aplikasi web akan meneruskan operasi logout ke
halaman logout server SSO CAS, pada mekanisme
logout. Setelah berhasil maka server SSO CAS akan
meneruskn ke halaman logout aplikasi web tersebut, agar
dapat dilakukan pemusnahan session dan cookie lokal
aplikasi web tesebut. Akibatnya saat pengguna begitu
membuka aplikasi web lain setelah logout di salah satu
aplikasi web lainnya, maka pengguna akan langsung
masuk ke halaman yang berisi tombol login aplikasi web
tersebut tanpa perlu logout lagi.

Selanjutnya pada proses logout CAS digambarkan pada

flowchart berikut ini

Perancangan Server SSO CAS

Perancangan Server SSO CAS pada tugas akhir ini
menggunakan sistem operasi Linux distro Ubuntu Server
11.04 yang merupakan turunan Debian yang mana akan
ditanamkan Java, Apache Tomcat, Maven dan Aplikasi
Server CAS. Maven dibutuhkan untuk building aplikasi
Server CAS sebelum dapat digunakan. Apache Tomcat
berfungsi sebagai web machine tempat berjalannya
aplikasi Server CAS.
Server CAS dibuat terpisah dari web server,
dikarenakan untuk memudahkan pengembangan dan
penambahan aplikasi aplikasi web lain di masa yang
akan datang dan juga agar kedua web machine (Apache
dan Apache Tomcat) tidak saling mengganggu. Server
CAS ini dihubungkan dengan server LDAP milik
Universitas Diponegoro yang sudah tersedia, dan pada
gambar 3.22 adalah Flowchart sistem login aplikasi
Server CAS.

Gambar 3.3 Flowchart proses logout Aplikasi CAS Server

Perancangan Server Web berbasis Klien

Perancangan Klien SSO CAS pada tugas akhir ini
menggunakan sistem operasi Linux distro Linux Mint 10.
Server Web memerlukan aplikasi web berbasis CMS
seperti Joomla, weblog seperti WPMU, webcloud seperti
ownCloud dan webmail seperti Squirrelmail. Kesemua
aplikasi tersebut memerlukan Apache, PHP dan MySQL
karena berjalan pada Apache, dan mengunakan bahasa
PHP serta basis data MySQL. Program kecil tambahan
yang dipasang pada sistem login aplikasi Web tersebut
sangat diperlukan, agar sistem login aplikasi Web
berbasis CMS dapat terintegrasi dengan proses login
server CAS.

Gambar 3.2 Flowchart proses login Aplikasi CAS Server

IV. IMPLEMENTASI DAN PENGUJIAN

Implementasi dan Konfigurasi CAS Server
Aplikasi CAS server merupakan aplikasi utama
dalam implmentasi sistem SSO. Aplikasi ini berfungsi
melayani layanan Single Sign On / Single Sign Out.
Aplikasi ini meneruskan ke halaman web service dan
memberikan tiket sebagai bukti hak akses. Otentikasi
CAS menggunakan LDAP. Langkah pertama adalah
mempersiapkan server Ubuntu Server 11.04 LTS dengan
Tomcat Java Server dan adanya aplikasi Apache Maven
serta SSL. Kemudian dilanjutkan dengan mengunduh
source Aplikasi CAS Server terlebih dahulu.
Server CAS yang telah terunduh, perlu
dikonfigurasi agar menggunakan LDAP sebagai
otentikasinya, yaitu dengan mengedit konfigurasi berkas
deployerConfigContext.xml,
cas-servlet.xml
dan
pom.xml. Stelah konfigurasi selesai dilakukan building
dan hasil dari building berekstensi war dapat dijalankan
di Apache Tomcat.
Implementasi dan Konfigurasi Aplikasi Web
Aplikasi web yang dibutuhkan berbasis PHP,
sehingga perlu diinstall Apache web server, php5, php5dev, dan Mysql server. Apache web server bertugas
menerima dan membalas permintaan situs yang datang
dari klien di web server. Php5 berfungsi mendukung
bahasa pemrograman php pada web server. Php5-dev
digunakan sebagai syarat implementasi PHP Accelerator
dengan perangkat lunak eAccelerator. Mysql server
sebagai basis
data
berfungsi sebagai syarat
mengimplementasi Joomla, WPMU dan ownCloud.
Konfigurasi agar mendukung SSO dilakukan
pada berkas yang berbeda-beda pada masing masing
aplikasi web. Akan tetapi dibuat menggunakan konsep
CASTGC. Tombol login dan logout dari masing masing
web harus diarahakan ke halaman login dan logout CAS
dengan service URL halaman pemrosesan login dan
logout dari aplikasi. Lalu halaman pemrosesan logout
harus memuat fungsi GET terhadap tiket yang dikirimkan
CAS, fungsi parsing xml terhadap protokol CAS yang
mengirim validasi login berupa username, dan fungsi
autocreate username di basis data aplikasi serta fungsi
login aplikasi dengan hanya menggunakan informasi
username. Halaman logout tidak perlu memuat fungsi
khusus selain fungsi pemusnahan session / cookie lokal
aplikasi web
Selain halaman login dan logot, halaman utama
aplikasi / halaman yang sering dimuat ulang, harus
memiliki fungsi pengecekan cookie CASTGC dan cookie
CAS lokal untuk autologin atau auto logout jika
pengguna telah login atau logout dari aplikasi lain.

Gambar 3.4 Flowchart proses login dan logout aplikasi Web

berbasis CMS

Gambar 3.4 dan gambar 3.5 menjelaskan proses

login/logout aplikasi web yang telah diubah sedemikian
rupa sehingga mendukung Single Sign On/Single Sign
Out terhadap CAS, yang mana dilakukan pengecekan
cookie sebelum/ sesudah login/logout

Hasil Pengujian Single Sign On / Single Sign Out

Pengujian sistem Single Sign On dilakukan
terhadap beberapa aplikasi web yang telah terinstall
(Joomla, WordpressMU, ownCloud dan Squirrelmail),
dengan cara melakukan login pada salah satu aplikasi
saja, kemudian membuka ketiga aplikasi lainnya setelah
login pada salah satu aplikasi saja.

Gambar 3.5 Lanjutan Flowchart proses login dan logout

aplikasi Web berbasis CMS

Pada gambar 3.1 dilakukan percobaan login pada

salah satu aplikasi yaitu aplikasi webcloud ownCloud,
ketika login berhasil, pengguna akan diteruskan ke
halaman utama aplikasi (gambar 3.2). Keberhasilan
Single Sign On terlihat pada gambar 3.3-3.5 yang mana
pengguna langsung dapat mengakses halaman utama
webmail, web dan weblog.
Sedangkan pengujian sistem Single Sign Out
dilakukan terhadap beberapa aplikasi web yang telah ada
(Joomla, WordpressMU, OwnCloud dan Squirrelmail),
dengan cara dilakukan logout pada salah satu aplikasi
saja, kemudian merefresh/membuka menu yang ada pada
ketiga aplikasi lainnya setelah logout pada salah satu
aplikasi saja.

Gambar 3.1 Percobaan login pada webcloud

Gambar 3.2 Login pada webcloud berhasil

Gambar 3.6 Pengujian logout pada aplikasi webmail

Gambar 3.3 Aplikasi webmail tidak membutuhkan login lagi

saat dibuka
Gambar 3.7 Aplikasi webcloud tidak membutuhkan logout lagi
saat dibuka

Gambar 3.4 Aplikasi web CMS tidak membutuhkan login lagi

saat dibuka

Gambar 3.8 Aplikasi weblog tidak membutuhkan logout lagi

saat dibuka

Gambar 3.5 Aplikasi weblog tidak membutuhkan login lagi

saat dibuka

Gambar 3.9 Aplikasi web tidak membutuhkan logout lagi saat

dibuka

Gambar 3.6 menunjukkan pengujian logout pada

aplikasi yang berbeda, yaitu webmail. Maka didapatkan
hasil berupa logout dati webmail. Sama halnya dengan
Single Sign On, keberhasilan Single Sign Out terlihat
pada gambar 3.7-3.9 yang mana pada setiap aplikasi,
pengguna akan langsung logout tanpa perlu menekan
tombol logout lagi di tiap aplikasi

berbasis Lightweight Directory Access Protocol

milik Universitas Diponegoro dapat berjalan dengan
baik.
2. Sistem Single Sign On / Single Sign Out sudah
berjalan dengan baik ditandai dengan hanya
membutuhkan operasi login melalui halaman web
SSO CAS Server pada salah satu aplikasi saja,
sedangkan saat membuka aplikasi lain
3.
Operasi otentikasi CAS Server menggunakan
LDAP sebagai user data store dengan metode Fast
Bind LDAP untuk otentikasi terhadap admin dan
metode Bind LDAP untuk otentikasi pengguna yang
berasal dari banyak direktori yang berbeda tetapi
masih di domain yang sama.
4.
Pembuatan akun pengguna akan dilakukanpada
basis data aplikasi, bila akun pengguna belum ada di
basis data aplikasi web tersebut, sedangkan ia telah
memiliki akun di server LDAP,yang dibuktikan
dengan didapatkannya data username melalui
protocol CAS
5.
Tingkatan hak akses dan grup pengguna yang
dibutuhkan dalam pembuatan akun di aplikasi web
Joomla, aplikasi multiblogging Wordpress, webmail
Squirrelmail dan terutama aplikasi webcloud
ownCloud didapatkan dengan cara melakukan
pencarian RDN pada server LDAP dengan
menggunakan username yang didapat melalui
protocol CAS.
Saran
Adapun saran yang dapat diberikan untuk
penelitian lebih lanjut adalah :
1. Layanan Single Sign On / Single Sign Out CAS
Server dapat dikembangkan lebih lanjut dengan
menggunakan sistem CAS Proxy dan Proxy Tiket
(PT), agar klien CAS tidak perlu lagi mengakses
cookie CAS pada browser.
2. Pengembangan terhadap aplikasi web lain di
jaringan Universitas Diponegoro agar menggunakan
CAS Server sebagai sistem otentikasi terpusat dan
tunggal.
3. Penelitian terhadap keamanan dan kinerja Sistem
Single Sign On / Single Sign Out CAS dapat
dilakukan dengan menggunakan implementasi yang
telah dilakukan.
DAFTAR PUSTAKA

Kelebihan dan Kelemahan Sistem SSO CAS Server

Dalam sebuah sistem pasti terdapat kelebihan
dan kelemahan. Hal itu juga berlaku pada Sistem Single
Sign On / Single Sign Out CAS Server yang telah
diimplementasikan ini. Pada pengujian Single Sign On
dan Single Sign Out, terlihat kelebihan dari Sistem
Single Sign On / Single Sign Out CAS Server, dimana
pengguna hanya perlu melakukan satu kali login / logout
saja untuk login / logout pada salah satu, beberapa atau
semua aplikasi web yang tersedia (Joomla,
WordpressMU, ownCloud dan Squirrelmail). Sistem ini
memudahkan pengguna dalam melakukan proses login /
logout pada aplikasi web yang tersedia. Pengguna pun
tidak perlu menghafalkan username dan password pada
setiap aplikasi web, yang mana bisa berbeda, karena
sistem ini hanya menggunakan satu sumber otentikasi,
yaitu LDAP milik Universitas Diponegoro.
Sistem Single Sign On / Single Sign Out CAS
Server yang telah diimplementasikan ini juga memiliki
kelemahan, disamping kelebihan berupa semua
kemudahan yang diberikan kepada pengguna untuk
login/logout, yaitu melalui otentikasi yang bersifat
terpusat dan tunggal, mengakibatkan otentikasi
dilakukan melalui server tunggal.
Jika dilakukan pengujian otentikasi saat server
CAS dan server LDAP berada dalam kondisi mati, maka
pengguna tidak akan bisa melakukan otentikasi. Jika
pengguna tidak bisa melakukan otentikasi maka
pengguna juga tidak dapat membuka salah satu,
beberapa atau semua aplikasi web yang menggunakan
otentikasi sistem Single Sign On / Single Sign Out CAS
Server.
Perawatan secara berkala sangatlah diperlukan
untuk mencegah matinya server SSO CAS atau server
LDAP. Clustering juga dapat menjadi sebuah alternatif
untuk mengatasi maslaha matinya server tersebut.
Masalah lain yang timbul sebagai kelemahan sistem
Single Sign On / Single Sign Out CAS Server, adalah
masalah keamanan. Sebagai contoh adalah pencurian
cookie atau adanya LDAP injection. Masalah keamanan
sistem Single Sign On / Single Sign Out CAS Server
tersebut dapat diatasi dengan pemeriksaan secara berkala
dan pemberian sistem keamanan yang memadai. Sebagai
contoh dengan menggunakan metode CAS Proxy dan
menambal setiap lubang keamanan atau vulnerability
pada aplikasi web yang ada.

[1] Addison, Marvin S.,Scott Battaglia, Andrew Petro

(2011). Jasig CAS Documentation. Jasig.
[2] Arkills, Brian (2003). LDAP Directories Explained:
An Introduction and Analysis. Addison Wesley.
Boston, MA 02116, U.S.A.
[3] Greenhill, Kathryn (2011) Flexible, customisable and
good looking: multiple uses for Wordpress MU in
two Australian Libraries, in 15th ALIA Information
Online Conference & Exhibition, Feb 1-3 2011.
Sydney, NSW: Australian Library and Information
Association.

PENUTUP
Dari hasil implementasi dan pengujian dapat
disimpulkan bahwa :
1. Sistem Single Sign On/ Single Sign Out berbasis
Cental Authentication Service Protocol di jaringan
10

[4] Grubb, Michael Flemin, Rob Carter. Single Sign

On and System Administrator .Paper, Universitas
Duke, Boston, 1998.
[5] Carter, Gerald (2003). LDAP System Administration.
OReilly. 1005 Gravenstein Highway North
Sebastopol, CA 95472, U.S.A.
[6] Chopra, Vivek, Sing Li, Jeff Genender (2007).
Professional Apache Tomcat 6 .Wiley Publishing.
Indianapolis, Indiana, USA.
[7] Dent, Kyle D (2003). Postfix: The Definitive Guide.
OReilly. 1005 Gravenstein Highway North
Sebastopol, CA 95472, U.S.A.
[8] Gilmore, W. Jason (2008). Beginning PHP and
MySQL from Novice to Professional.Apress.
Berkeley, USA.
[9] Huggins, Ronnie Dale. Web Access Management
and Single Sign On. Paper , IJCSI International
Journal of Computer Science Issues, Vol. 2, 2009.
[10] Nursyamsi. Implementasi Sistem Single Sign On
berbasis Java. Skripsi S-1, Universitas Sumatera
Utara, Medan, 2009.
[11] Putera, R. Fibrian Satya. Sistem Otentikasi
Terpusat Berbasis Lightweight Directory Access
Protocol. Skripsi S-1, Universitas Diponegoro,
Semarang, 2011.
[12] Riyanto, Slamet. Membuat Web Portal dengan
Joomla. Paper, IlmuKomputer.com, 2006.
[13] Roberts, Craig, Richrd Shipman (2011). Integrating
Version Control into OwnCloud. Department of
Computer Science Aberystwyth University, Dyfed
SY23 3AL, Britania Raya
[14] Roger, Stuart J, Heesun Park .Single Sign On
Configuration and Trobleshooting for SAS 9.2
Enterprise BI Web Applications . Paper, SAS
Global Forum 2011, SAS Institute,Inc.
[15] Rudy, Riechie, Ody Gunadi. Integrasi Aplikasi
Menggunakan Single Sign On Berbasiskan
Lightweight Directory Access Protokol (Ldap)
Dalam Portal Binus@Ccess (Bee-Portal). Skripsi
S-1, Universitas Bina Nusantara, Jakarta, 2009.
[16] Sing Li. Introduction to Apache Maven 2. Paper,
Wrox Press. 2006
[17] Taylor, Carl, Alistair McDonald, David Rusenko,
Patrick Ben Koetter, Ralf Hildebrandt, Magnus
Back (2005). Linux Email: Set up and Run a Small
Office Email Server. PACKT Publishing. Livery
Street, Birmingham
[18] Twist, J. . Better understand cookies with
ieHTTPHeaders.,
from
http://www.thejoyofcode.com/Better_understand_C
ookies_with_ieHTTPHeaders.aspx, 2005

BIODATA
Muhammad Yanuar Ary Saputro,
lahir di Semarang tanggal 8 Januari
1990. Menempuh pendidikan dasar di
SD Negeri Sompok 03 Semarang.
Melanjutkan ke SLTP N 08
Semarang, Dan Pendidikan tigkat atas
di SMA N 11 Semarang, lulus tahun
2008. Dari tahun 2008 sampai saat ini
masih menempuh studi Strata-1 di
Jurusan Teknik Elektro Fakultas Teknik Universitas
Diponegoro Semarang, konsentrasi Komputer dan
Informatika.

Menyetujui,

Dosen Pembimbing I

Ir. Kodrat Iman Satoto, M.T.

NIP. 196310281993031002

Dosen Pembimbing II

Adian Fatchur Rochim, S.T.,M.T.

NIP. 197302261998021001

11