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

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 Sign-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 yang mendukung autentikasi. Pengembang CAS yang

3

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 Server akan mengirimkan TGC ke browser.

4

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.

5

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

6

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

7

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.

8

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 login pada salah satu aplikasi saja.

9

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

10

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.

DAFTAR PUSTAKA [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.

11

[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_Cookies_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