1) Mahasiswa Teknik Elektro UNDIP
2) Dosen Teknik Elektro UNDIP
1
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. 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
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.
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. 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 On/Single
Sign-Out (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.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.
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
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).
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.
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.4 Otentikasi pengguna
- Jika username dan password benar maka CAS
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.
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
(One-Time-Ticket).
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.
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.
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.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.
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.
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
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
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.
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
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
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.
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.2 Flowchart proses login Aplikasi CAS Server
Selanjutnya pada proses logout CAS digambarkan pada
flowchart berikut ini
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.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
Gambar 3.5 Lanjutan Flowchart proses login dan logout aplikasi Web berbasis CMS
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, php5-dev, 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.
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
Gambar 3.1 Percobaan login pada webcloud
Gambar 3.2 Login pada webcloud berhasil
Gambar 3.3 Aplikasi webmail tidak membutuhkan login lagi saat dibuka
Gambar 3.4 Aplikasi web CMS tidak membutuhkan login lagi saat dibuka
Gambar 3.5 Aplikasi weblog tidak membutuhkan login lagi saat dibuka
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.6 Pengujian logout pada aplikasi webmail
Gambar 3.7 Aplikasi webcloud tidak membutuhkan logout lagi saat dibuka
Gambar 3.8 Aplikasi weblog tidak membutuhkan logout 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
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.
PENUTUP
Dari hasil implementasi dan pengujian dapat disimpulkan bahwa :
1. Sistem Single Sign On/ Single Sign Out berbasis
Cental Authentication Service Protocol di jaringan
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.
DAFTARPUSTAKA
[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.
[4] Grubb, Michael Flemin, Rob Carter. “Single Sign
On and System Administrator” .Paper, Universitas
Duke, Boston, 1998.
[5] Carter, Gerald (2003). LDAP System Administration. O’Reilly. 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. O’Reilly. 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.
