Pembuatan model sistem manajemen otentikasi single sign-on yang memakai proses enkripsi data menggunakan algoritma diffie-helman dan menggunakan RMI (Remote Method Invocation) - USD Repository

METHOD INVOCATION)

TUGAS AKHIR

Diajukan untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Teknik Program Studi Teknik Informatika

Disusun Oleh : Ignatius Wijaya Kusuma

NIM : 075314044

PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA YOGYAKARTA

FINAL PROJECT

Presented as Partial Fulfillment of The Requirements To Obtain Sarjana Teknik Degree

In Informatics Engineering

By :

Ignatius Wijaya Kusuma NIM : 075314044

INFORMATICS ENGINEERING STUDY PROGRAM FACULTY OF SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY YOGYAKARTA

"We shall show mercy, but we shall not ask for it." - Winston Churchill

"Do not be too moral. You may cheat yourself out of much life. Aim above morality. Be not simply good; be good for something." - Henry David Thoreau Publishes

Otentikasi adalah suatu tindakan untuk mengkonfirmasikan suatu kebenaran dari sebuah entitas dan sebuah trusted third-party dibutuhkan ketika sebuah transaksi saling membutuhkan kepercayaan antara orang yang bertransaksi dan orang yang ditransaksi. Penelitian ini mengembangkan suatu sistem otentikasi dengan menggunakan pendekatan sistem terdistribusi dengan menggunakan paralel database dan alogiritma Diffie-Hellman

Ide utama dari parallel DBMS(Database Manajement System) adalah untuk membangun sebuah computer yang sangat kuat dari banyak komputer kecil, yang masing-masing memiliki rasio kinerja dan harga yang sangat baik dengan rasio biaya yang jauh lebih rendah bila dibandingkan dengan sebuah komputer mainframe. Melalui bantuan metode pemanggilan objek, teknologinya akan digunakan untuk memanggil fungsi dan prosedur secara remote/jarak jauh. Salah satu teknologinya adalah RMI(Remote Method Invocation). Hasil utama dari sistem ini berupa sebuah library java yang digunakan sebagai fungsi login pada sistem developer.

Authentication is an action to confirm the truth of an entity and a trusted third-party is required when a transaction requires mutual trust between the people and the people who transact. This study developed an authentication system using the approach of distributed systems using parallel database and Diffie-Hellman algoritm

The main idea of parallel DBMS (Database Management System) is to build a powerful computer of many small computers, each of which has a ratio of performance and excellent price ratio that is much lower cost when compared to a mainframe computer. Through the help of object method calls, the technology will be used to invoke functions and procedures in remote / long distance. One of the technology is RMI (Remote Method Invocation). The main result of this system in the form of a java library that is used as a function of log on the system developer.

Puji dan syukur penulis panjatkan kehadirat Tuhan Yang Maha Esa yang telah

melimpahkan berkat dan rahmatNya, sehingga penulis skripsi dengan judul “Pembuatan

Model Sistem Manajemen Otentikasi Single Sign-On Yang Memakai Proses Enkripsi Data

Menggunakan Algoritma Diffie-Hellman Dan Menggunakan Rmi (Remote Method Invocation)” ini dapat diselesaikan dengan baik oleh penulis. Skripsi ini ditulis sebagai salah

satu syarat untuk memperoleh gelar sarjana komputer di Program Studi Teknik Informatika,

Fakultas Sains dan Teknologi, Universitas Sanata Dharma Yogyakarta.

Selama penulisan skripsi ini, banyak pihak yang telah membantu dan membimbing

penulis. Oleh sebab itu melalui kesempatan ini penulis mengucapkan terima kasih atas selesainya penyusunan skripsi ini, kepada:

1. Bapak Puspaningtyas Sanjoyo Adi S.T., M.T. selaku dosen pembimbing yang telah

bersedia memberi saran, kritik, meluangkan waktu, tenaga dan pikiran untuk membimbing dan mengarahkan penulis.

2. Ibu Ridowati Gunawan S.Kom., M.T. selaku kaprodi Teknik Informatika dan dosen

pembimbing akademik.

3. Kedua orang tua yang telah memberi dukungan baik doa dan materi, hingga penulis dapat

menyelesaikan karya ilmiah ini.

4. Teman-teman TI angkat 2007, 2008 yang meluangkan waktu untuk memberi saran dalam

penyusunan tugas akhir ini.

5. Teman-teman kos yang telah meluangkan waktu untuk disibukkan guna penyelesaian

tugas akhir ini

6. Untuk pihak-pihak yang tidak dapat penulisa sebutkan satu per satu. Penulis

mengucapkan terima kasih atas bantuannya sehingga penulis dapat menyelesaikan karya

ilmiah ini.

Akhir kata, penulis berharap karya ilmiah ini dapat bermanfaat bagi kemajuan dan

perkembangan ilmu pengetahuan.

Yogyakarta, 25 April 2012

DAFTAR ISI

HALAMAN PENGESAHAN ...iv

HALAMAN PERSEMBAHAN ... v

PERNYATAAN KEASLIAN KARYA ...vi

PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ... vii

1.5. Luaran yang Diharapkan ... 12

1.6. Metodologi Penelitian ... 12

1.7. Sistematika Penulisan ... 14

BAB II LANDASAN TEORI ... 15

2.1. Otentikasi ... 15

2.1.1. Single Sign-On ... 15

2.1.2. Trusted Third-Party ... 18

2.1. Diffie-HellmanKey-Exchange Protocol ... 18

2.2. Message Digest 5 ... 22

2.3. DBMS (Database Management System) ... 22

2.3.1. Struktur DBMS ... 24

2.3.2. Parallel DBMS ... 25

2.3.2.1. Arsitektur Fungsional ... 26

2.3.2.2. Partisi Data Paralel ... 28

2.4. Client Server ... 29

2.5. RMI (Remote Method Invocation)... 30

2.5.1. Cara Kerja RMI ... 31

2.5.2. Java Library ... 34

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 36

3.1. Metode Pengembangan Perangkat Lunak ... 36

3.1.1. Unified Process (UP) ... 36

3.2. Analisa Sistem ... 38

3.3. Proses Sistem... 40

3.3.1. Proses Otentikasi... 40

3.3.2. Proses Manajemen Data Account ... 42

3.3.2.1. Proses Manajemen PasswordUser ... 42

3.3.2.2. Proses Manajemen Data User ... 44

3.3.2.3. Proses Konfigurasi DatabaseServer dan Controller ... 44

3.4. Deskripsi Umum Sistem ... 45

3.7.1.2. Diagram SequenceLogin ... 76

3.7.1.3. Diagram Sequence Manajemen Password User ... 79

3.7.1.4. Diagram Sequence Manajemen Data User - Insert ... 82

3.7.1.5. Diagram Sequence Manajemen Data User - Update... 85

3.7.1.6. Diagram Sequence Manajemen Data User - Delete ... 88

3.7.1.7. Diagram Sequence Manajemen Data User - Search ... 91

3.7.1.8. Diagram SequenceSetting, Start/StopServer dan Database Server 94 3.7.2. Diagram Kelas ... 96

3.8. Model Desain ... 96

3.8.1. Penjelasan Antarmuka ... 96

3.8.1.1. Register ... 97

3.8.1.2. Login ... 97

3.8.1.3. MenuUpdate ... 98

3.8.1.4. MenuUpdate_1 ... 99

3.8.1.5. ActionSession... 100

3.8.1.6. MenuInsert ... 101

3.8.1.7. MenuUpdate ... 102

3.8.1.8. MenuDelete ... 103

3.8.1.9. MenuSearch ... 104

3.8.1.10. TrayGUIServer Controller ... 105

3.8.1.11. TrayGUIServer Database ... 106

3.8.2. Penjelasan Kelas ... 107

3.8.2.1. Kelas Web Server ... 107

3.8.2.2. Kelas Aplikasi Client ... 113

3.8.2.3. Kelas Server ... 119

3.8.2.4. Kelas Client Server Database ... 133

3.8.2.5. Kelas Server Database ... 136

3.9. Desain Basis Data ... 147

3.9.1. Basis Data pada Server ... 147

3.10. Metode Pengujian ... 147

3.10.1. Pengujian Aplikasi Web User ... 148

3.10.2. Pengujian Aplikasi Web Administrator ... 148

3.10.3. Pengujian Aplikasi Client Controller ... 149

3.10.4. Pengujian Aplikasi Controller ... 150

3.10.5. Pengujian Aplikasi Client Database ... 151

3.10.6. Pengujian Aplikasi Server Database ... 152

BAB IV IMPLEMENTASI DAN ANALISIS SISTEM ... 154

4.1. Implementasi ... 154

4.1.1. Implementasi File ... 154

4.1.3. Implementasi Basis Data ... 157

4.1.4. Implementasi Antar Muka ... 158

4.1.4.1. Halaman LoginUser... 158

4.1.4.2. Halaman Registrasi ... 158

4.1.4.3. Halaman Manajemen PasswordUser ... 158

4.1.4.4. Halaman SessionAction Administrator ... 159

4.1.4.5. Halaman Manajemen Data User - Insert ... 160

4.2.2. Instalasi Client ... 165

4.3. Pengujian Kelas dan Method ... 166

4.3.1. JavaLibAuthClient ... 166

4.3.1.1. Method insert() ... 166

4.3.1.2. Method update() ... 166

4.3.1.3. Method delete() ... 167

4.3.1.5. Method authentication()... 168

4.3.2. ServerImpl ... 168

4.3.2.1. Method start() ... 168

4.3.2.2. Method stop() ... 169

4.3.2.3. Method scanning() ... 169

4.3.3. DatabaseClient ... 169

4.3.3.1. Method ping() ... 169

4.3.4. ImplDatabaseServer ... 170

4.3.4.1. Method ping() ... 170

4.3.5. Pengujian Use-Case ... 170

4.3.5.1. Use Case Menjalankan ServerDatabase ... 170

4.3.5.2. Use Case Menjalankan ServerController ... 172

4.3.5.3. Use Case Melakukan Login ... 174

4.3.5.4. Use Case Melakukan Registrasi ... 177

4.3.5.5. Use Case Melakukan Update bagi User ... 178

4.3.5.6. Use Case Melakukan InsertAdministrator ... 179

4.3.5.7. Use Case Melakukan UpdateAdministrator ... 180

4.3.5.8. Use Case Melakukan DeleteAdministrator... 180

4.3.5.9. Use Case Melakukan SearchAdministrator ... 181

4.3.5.10. Use Case Pengujian dengan Aplikasi Desktop ... 182

4.3.5.11. Use Case Pengujian dengan Aplikasi Web ... 184

4.3.5.12. Use Case Pengujian Client Secara Bersamaan ... 188

4.3.6. Pengujian Performansi ... 189

4.3.7. Pengujian Oleh Pengguna ... 191

4.3.7.1. Pengujian Oleh User... 191

4.3.7.2. Pengujian Oleh Administrator ... 191

4.4. Analisa Hasil ... 192

BAB V KESIMPULAN DAN SARAN ... 196

DAFTAR GAMBAR

Gambar 1. Otentikasi yang tidak menggunakan Single Sign-On[7] ... 16

Gambar 2. Sistem yang menggunakan Single Sign-On[7] ... 17

Gambar 3. Trusted Third-Party[8] ... 18

Gambar 4. Algoritma Diffie-Hellman key exchange[9] ... 20

Gambar 5. Pengiriman data pada Diffie-Hellman key exchang[9] ... 20

Gambar 6. Arsitektur DBMS [2] ... 24

Gambar 7. Rasio Extensibility, baik dalam bentuk speedup(a) maupun scaleup(b) [2] ... 26

Gambar 8. arsitektur menggunakan subsistem (Bergsten et al.[1991]) [2] ... 27

Gambar 9. Macam-macam penyebaran data [2] ... 28

Gambar 10. Client/Server computing model p [1] ... 29

Gambar 11. Arsitektur RMI, hubungan antara client dan host [1] ... 31

Gambar 12. menggambarkan mendaftarkan layanan dengan RMI registri tunggal [1] ... 32

Gambar 13. cara kerja stub dan skeleton [1] ... 34

Gambar 14. pengembangan perangkat lunak [6] ... 36

Gambar 15. Unified Process (UP) workflow.[6] ... 37

Gambar 16. Arsitektur sistem yang akan dibuat ... 39

Gambar 17. Prosedur Otentikasi... 40

Gambar 18. Proses Otentikasi, data dikirimkan antar aplikasi ... 42

Gambar 19. Proses Distribusi Data... 43

Gambar 20. Proses Pembacaan ... 44

Gambar 21 Use Case Diagram ... 46

Gambar 22 Diagram Activity Registrasi User ... 64

Gambar 23 Diagram Activity Login ... 65

Gambar 24 Diagram Activity Update User ... 66

Gambar 25 Diagram ActivityInsert ... 67

Gambar 26 Diagram ActivityUpdate ... 68

Gambar 27 Diagram Activity Delete ... 69

Gambar 28 Diagram Activity Search ... 70

Gambar 29 Diagram Activity Setting dan Start/Stop Server ... 71

Gambar 30 Diagram Activity Setting dan Start/Stop Server Database ... 72

Gambar 31 Diagram Sequence Registrasi User ... 73

Gambar 32 Diagram Sequence Alternatif RegistrasiUser ... 74

Gambar 33 Interface, Controller, Entity Registrasi User ... 74

Gambar 34 Diagram Sequence Login ... 76

Gambar 35 Diagram SequenceLogin Alternatif ... 77

Gambar 37 Diagram Sequence Manajemen Password User ... 79

Gambar 38 Diagram Sequence Manajemen Password User Alternatif ... 80

Gambar 39 Interface, Controller, Entity Update User ... 80

Gambar 40 Diagram Snsequence Insert ... 82

Gambar 41 Digram Sequence Manajemen Data User - Insert Alternatif ... 83

Gambar 42 Interface, Controller, Entity Insert ... 83

Gambar 43 Diagram Sequence Manajemen Data User - Update ... 85

Gambar 44 Diagram Sequence Manajemen Data User - UpdateAlternatif ... 86

Gambar 45 Interface, Controller, Entity Update ... 86

Gambar 46 Diagram Sequence Manajemen Data User - Delete ... 88

Gambar 47 Diagram Sequence ManajemenData User - Delete Alternatif ... 89

Gambar 48 Interface, Controller, Entity Delete ... 89

Gambar 49 Diagram Sequence Manajemen Data User - Search ... 91

Gambar 50 Diagram Sequence ManajemenData User - Search Alternatif ... 92

Gambar 51 Interface, Controller, Entity Search ... 92

Gambar 52 Diagram Sequence Server dan Server Database... 94

Gambar 53 Interface, Controller, Entity Otentikasi Sistem ... 95

Gambar 54 Diagram Kelas Keseluruhan ... 96

Gambar 55 Antarmuka Halaman Registrasi ... 97

Gambar 56 Antarmuka Halaman Login User dan Administrator ... 98

Gambar 57 Antarmuka Halaman Update... 99

Gambar 58 Antarmuka Halaman Update... 100

Gambar 59 Antarmuka Halaman Utama Administrator ... 101

Gambar 60 Antarmuka Halaman Insert ... 102

Gambar 61 Antarmuka Halaman Update ... 103

Gambar 62 Antarmuka Halaman Delete ... 104

Gambar 63 Antarmuka Halaman Search ... 104

Gambar 64 Antarmuka TrayIconServerController ... 106

Gambar 65 Antarmuka TrayIconServerDatabase ... 107

Gambar 66 Halaman LoginUser ... 158

Gambar 67 Halaman Registrasi ... 158

Gambar 68 Halaman Update ... 159

Gambar 69 Halaman Utama Administrator ... 159

Gambar 70 Halaman InsertAdministrator... 160

Gambar 71 Halaman UpdateAdministrator ... 161

Gambar 72 Halaman Delete Administrator... 161

Gambar 73 Halaman SearchAdministrator ... 162

Gambar 74 GUI ServerController ... 162

Gambar 75 GUI Server Database ... 163

Gambar 77 Informasi Server Database ... 171

Gambar 78 MenuServer Database ... 171

Gambar 79 Menu Konfigurasi Server Database... 171

Gambar 80 Menu Server Database ... 172

Gambar 81 Hasil pada NetBean 6.9 untuk Server Database ... 172

Gambar 82 Informasi ServerController ... 172

Gambar 83 Menu Server Controller ... 173

Gambar 84 Menu Konfigurasi Server Controller ... 173

Gambar 85 Menu ServerController ... 173

Gambar 86 Hasil pada NetBean 6.9 untuk Server Controller ... 174

Gambar 87 Pengujian Login User ... 174

Gambar 88 Hasil Login User ... 175

Gambar 89 Pengujian LoginAdministrator ... 175

Gambar 90 Hasil Login Administrator ... 176

Gambar 91 Pengujian Login User Gagal ... 176

Gambar 92 Pengujian Login Administrator Gagal ... 177

Gambar 93 Pengujian Registrasi Sukses... 177

Gambar 94 Pengujian Registrasi Gagal ... 178

Gambar 95 Pengujian Update User ... 178

Gambar 96 Menu Utama Administrator Memilih Insert ... 179

Gambar 97 Menu Insert ... 179

Gambar 98 Menu Utama Administrator Memilih Update ... 180

Gambar 99 Menu Update ... 180

Gambar 100 Menu Utama Administrator Memilih Delete ... 181

Gambar 101 Menu Delete ... 181

Gambar 102 Menu Utama Administrator Memilih Search ... 181

Gambar 103 Pengujian Menu Search untuk User yang ada di Database ... 182

Gambar 104 Pengujian Menu Search untuk User yang tidak ada di Database ... 182

Gambar 105 Memasukkan JavaLibAuthClient.jar pada project ... 183

Gambar 106 Contoh GUI ... 183

Gambar 107 Hasil Pengujian Login Aplikasi Desktop ... 184

Gambar 108 Pemasangan JavaLibAuthClient.jar untuk Aplikasi Web... 185

Gambar 109 Contoh Aplikasi Web ... 186

BAB I PENDAHULUAN

1.1. Latar Belakang Masalah

Banyak program aplikasi sekarang yang menggunakan otentikasi contohnya: jejaring sosial seperti facebook, plurk, google mail, dan sebagainya. Tentunya banyak sekali data otentikasi yang dibutuhkan (username dan password)/account. Bayangkan berapa banyak data yang dimiliki oleh satu macam sistem saja. Hal ini tentunya membuat kesulitan bila seseorang harus memanajemen seluruh data otentikasi tersebut.

Selain dari aplikasi-aplikasi diatas, masih banyak contoh-contoh lain seperti aplikasi yang menggunakan otientikasi, contohnya di Universitas Sanata Dharma. Di Universitas ini terdapat beberapa program aplikasi yang memiliki cara tersendiri dalam mengatur otentikasinya, seperti SIA (Sistem Informasi Akademik), penggunaan HotSpot, dan SIP (Sistem Informasi Perpustakaan). Baik SIA, HotSpot, dan SIP memiliki masing-masing database database dan proses otentikasi masing-masing. Masing-masing sistem di Universitas tersebut memakai data yang sama untuk setiap otentikasinya. Sehingga dapat dilakukan pengembangan untuk melakukan proses otentikasinya.

Selain daripada pengaturan otentikasi yang terpusat, dibutuhkan sebuah pengamanan khusus untuk menjaga agar data dapat disembunyikan sedemikian rupa, agar data yang dimiliki oleh pemilik account hanya dapat diakses oleh dan hanya oleh pemilik account itu sendiri. Salah satunya adalah dengan menggunakan algoritma Diffie-HellmanKey Exchange Protocol.

pengecekan antara pengirim dan penerima juga diperhatikan sungguh-sungguh dan selain itu dikarenakan adakalanya dimana seorang pengirim/penerima bukan benar-benar sebagai pengirim/penerima itu sendiri. Oleh karena itu, fungsi orang ke tiga disini sebagai saksi bahwa seorang pengirim/penerima adalah orang yang benar-benar patut menerima/mengirim sebuah data.

Sistem juga membuat keseluruhan data tidak harus disebar lagi (setiap aplikasi 1 database) dan menjadi lebih efisien, yaitu dengan memanfaatkan teknologi SingleSign-On. Hal ini dimaksudkan dengan sebuah data otentikasi, seseorang dapat mengkases beberapa program aplikasi yang terdaftar padanya untuk digunakan. Hal ini membantu mencegah human-error dan kegagalan lainnya.

Ada banyak cara untuk mengirimkan data, salah satunya dengan menggunakan Remote Method Invocation(RMI)[1].RMI adalah sebuah sistem yang memungkinkan objek yang running di satu JVM(Java Virtual Machine) untuk memanggil suatu method/fungsi dari satu objek yang berjalan di JVM yang lain, sehingga JVM memungkinkan komunikasi remote antar program Java.

Sistem ini juga tentunya membutuhkan sebuah tempat penyimpanan data dari tiap account milik tiap user yang sudah terdaftar. Tempat menyimpan data tersebut biasanya berupa sebuah DBMS(Database Management System) atau biasa disebut juga aplikasi database. Sebuah sistem manajemen database, atau DBMS, adalah software yang dirancang untuk membantu dalam menjaga dan memanfaatkan koleksi data yang besar[2]. Beberapa software atau perangkat lunak DBMS adalah MySQL dan Oracle

bantuan algoritma Diffie-Hellman untuk enkripsi datanya dibandingkan dengan LDAP yang menggunakan SSL (Secure Socket Layer) serta fungsi enkripsi seperti SSHA (Salted SHA1), crypt (OS dependent encription), MD5, SMD5 (Salted MD5), dan SHA1[5]. Kelebihannya yang paling nampak adalah pada saat pengiriman data pribadi user yang berupa password, dimana data pengiriman password akan selalu berubah tergantung dari penghitungan data yang diberikan oleh client sebelumnya.

Sistem ini dibuat pada sektor pembuatan aplikasi, dimana seorang developer aplikasi desktop maupun web tidak perlu membuat otentikasi tersendiri. Seorang developer hanya diharuskan untuk meletakkan library yang nantinya pada pembuatan programnya hanya sedikit memasukan code utama sistem.

1.2. Rumusan Masalah

Dari uraian diatas dapat dirumuskan masalah pada sistem ini adalah bagaimana membuat sistem otentikasi java class library dengan pendekatan orang ke-tiga dengan sistem basis data terdistribusi dan datanya tersimpan dibeberapa database sekaligus serta memiliki kapasitas yang besar sekaligus menjamin keamanan data di dalamnya.

1.3. Tujuan Penelitian

Adapun tujuan dari penyusunan Tugas Akhir ini adalah sebuah sistem otentifikasi user dalam bentuk java class library, dimana para pembuat aplikasi(developer) tidak perlu membuat suatu layanan otentifikasi tersendiri untuk aplikasi yang mereka buat.

1.4. Batasan Masalah

Terdapat batasan masalah pada pembuatan sistem ini mengenai kemampuan dari program yang dibuat:

 Bahasa pemrograman yang digunakan menggunakan pemrograman

 Pada fungsi search pada aplikasi admin, hanya menunjukkan password dari database berupa password user yang telah dienkripsi.

 Penggunaan bilangan prima pada program hanya mencakup angka

hingga 512

 Penggunaan Topologi jaringan hanya sebatas jaringan lab.

 Pemeliharaan database langsung dari database databasenya masing-masing (DBMS), langsung dengan menggunakan aplikasi yang sudah ada seperti SQLyog, dsb.

 Penyediaan fungsi admin pada program hanya pada fungsi insert, update, dan delete.

 Penyebaran data pada database menggunakan penyebaran dengan Round-Robin

1.5. Luaran yang Diharapkan

Harapan dari penyusunan Tugas Akhir ini adalah sebuah class library, aplikasi web server, aplikasi server otentikasi dan aplikasi server database

yang merupakan sebuah konektor dengan database yang mengatur

konektivitas dan proses otentikasi untuk aplikasi dari developer.

1.6. Metodologi Penelitian

Metode penelitian yang dilakukan yaitu dengan melakukan studi kasus dengan langkah-langkah sebagai berikut:

1. Analisis Kebutuhan

 Studi Penggunaan RMI

i. Mencari sumber-sumber tentang metode-metode dalam menggunakan RMI (Remote Method Invocation) baik berupa buku maupun internet sebagai bahan kajian utama.

i. Mencari sumber-sumber tentang metode-metode dalam menggunakan algoritma Diffie-Hellman berupa buku maupun internet sebagai bahan kajian utama.

 Studi Prosedur Sigle Sign-On

i. Mencari sumber-sumber tentang metode-metode dalam menggunakan teknologi Single Sign-On baik berupa buku maupun internet sebagai bahan kajian utama.  Studi Database Terdistribusi

i. Mencari sumber-sumber tentang macam-macam metode distribusi data pada DBMS(Database Manajement System) untuk nantinya dikembangkan dengan RMI agar menjadi satu kesatuan system otentifikasi.

2. Analisis dan Design Sistem

 Mengumpulkan seluruh data kemudian dianalisis untuk

menentukan kebutuhan dan desain baik untuk antarmuka maupun kerja dari sistem.

3. Implementasi sistem

 Menerapkan metode Unified Process (UP) [6]untuk pembuatan perangkat lunak, dimana pengerjaannya mengikuti life-cycle dari metode Unified Process yang hasil penerapannya menghasilkan sebuah aplikasi yang dapat mengatur otentifikasi dengan database yang tersebar dan menggunakan RMI sebagai fungsi kontrolnya.

4. Pengujian sistem

1.7. Sistematika Penulisan

Sistematika dalam penulisan tugas akhir ini adalah sebagai berikut : BAB I : PENDAHULUAN

Pada bab ini berisi tentang latar belakang masalah, rumusan masalah, batasan masalah, tujuan penulisan, metodologi penelitian dan sistematika penulisan.

BAB II : LANDASAN TEORI

Pada bab ini berisi berbagai acuan dan bahan-bahan yang bisa digunakan untuk menjawab permasalahan yang di hadapi seperti teori-teori mengenai konsep dasar sistem yang mendukung dalam menyelesaikan masalah yang terjadi.

BAB III : ANALISIS DAN PERANCANGAN

Perancangan sistem ini menjelaskan tentang rancangan dari sistem secara mendetail.

BAB IV : IMPLEMENTASI SISTEM

Pada bagian ini membahas tenteng implementasi program yang akan dibuat.

BAB V : ANALISIS DAN HASIL

Pada bagian ini berisi analisa hasil yang telah didapat selama proses implementasi sistem.

BAB VI : KESIMPULAN DAN SARAN

Pada bab ini berisi kesimpulan dari semua kegiatan penyusunan tugas akhir ini serta saran untuk pengembangan yang lebih lanjut.

DAFTAR PUSTAKA

BAB II LANDASAN TEORI

2.1. Otentikasi

Otentikasi berasal dari bahasa Yunani dan terdiri dari dua kata, yaitu αυθεντικός yang artinya nyata atau asli dan authentes yang artinya penulis. Otentikasi adalah suatu tindakan untuk mengkonfirmasikan suatu kebenaran dari sebuah entitas. Semua ini melibatkan konfirmasi identitas seseorang, menelusuri asal-usul artefak, memastikan bahwa sebuah produk sesuai dengan apa yang di klaim, atau menjami bahwa sebuah program computer dapat dikatakan terpercaya(trusted).

Fungsi otentikasi yang dibangun pada sistem yaitu sebagai sarana untuk membangun sebuah sistem database yang bersifat parallel (parallel DBMS), dimana proses otentikasi digunakan untuk melakukan pengecekan data yang telah diisi terlebih dahulu.

2.1.1. Single Sign-On

Gambar 1. Otentikasi yang tidak menggunakan Single Sign-On[7]

Hasil pertimbangan baik antara kegunaan dan keamanan yang dibutuhkan untuk mengkoordinasikan, kemudian bagaimana mengintegrasikan account pengguna serta memanajemen account tersebut dan manajemen account untuk beberapa domain yang berbeda sekarang ini, sebuah layanan diharuskan menyediakan koordinasi dan integrasi yang secara langsung menguntukan para enterprise, yaitu:

 Pengurangan waktu yang dibutuhkan pengguna untuk sign-on di sebuah domain, termasuk mengurangi kemungkinan gagal sign-on yang disebabkan kesalahan pengguna.

 Meningkatkan keamanan dengan mengurangi kebutuhan pengguna

 Pengurangan waktu yang digunakan, peningkatan respon oleh

sistem administrator dalam menambahkan dan menghapus

pengguna untuk sistem atau memodifikasi karakteristik mereka.

 Meningkatkan keamanan melalui peningkatan kemampuan

administrator sistem untuk menjaga integritas dari konfigurasi account pengguna, termasuk kemampuan untuk mengubah atau menghapus akses pengguna untuk semua sumber daya sistem dengan cara yang terkoordinasi dan konsisten.

Gambar 2. Sistem yang menggunakan Single Sign-On[7]

2.1.2. Trusted Third-Party

Menurut buku Microsoft® Exchange Resources Kit[8], trusted third-party disini adalah sebuah cara penanganan dalam bagaimana cara bertransaksi dengan menggunakan pihak ketiga, dimana pihak ketiga disini dinyatakan trusted oleh masing-masing pihak yang bertransaksi. Sebuah trusted third-party dibutuhkan ketika sebuah transaksi saling membutuhkan kepercayaan antara orang yang bertransaksi dan orang yang ditransaksi. Dengan bantuan pihak ketiga, masing-masing pihak memberikan suatu kata kunci yang masing-masing dimiliki oleh kedua belah pihak, kemudian pihak ke tiga memeriksa apakah kata kunci tersebut benar atau tidak. Trusted third-party disini berfungsi sebagai pem-verify sebuah integrity dari pihak yang bersangkutan.

Gambar 3. Trusted Third-Party[8]

2.1. Diffie-Hellman Key-Exchange Protocol

Diffie-Hellman key exchange adalah sebuah fungsi spesifik dalam pertukaran kunci. Ini adalah salah satu contoh praktis paling awal dari sebuah fungsi pertukaran kunci yang diimplementasikan dalam bidang kriptografi. Diffie-Hellmankey exchange memungkinkan kedua pihak yang tidak memiliki pengetahuan satu sama lain untuk bergabung membuat sebuah kunci rahasia bersama melalui jaringan komunikasi yang tidak aman. Kunci ini kemudian dapat digunakan untuk mengenkripsi komunikasi berikutnya menggunakan symmetric key chiper.

Dengan kriptografi symmetric sangat diperlukan adanya pengiriman kunci rahasia untuk kedua belah pihak yang berkomunikasi sebelum komunikasi yang aman dapat terbentuk. Sebelum munculnya kriptografi yang menggunakan kunci publik, pembentukan kunci rahasia bersama antar pihak yang berkomunikasi selalu menjadi masalah yang sulit, sebab pekerjaan/tugas yang dilakukan membutuhkan saluran/channel yang benar-benar aman, dan sering dikatakan bahwa saluran tersebut berarti penyerahan fisik kunci oleh kurir khusus. Keuntungan paling penting dari kriptografi public key yang menyediakan symmetric public key adalah pencapaian pertukaran kunci rahasia antara pihak komunikasi jarak jauh tanpa membutuhkan suatu saluran yang aman.

Gambar 4. Algoritma Diffie-Hellman key exchange[9]

Pelaksanaan sederhanan dan implementasi asli dari protokol ini menggunakan kelompok perkalian bilangan bulat dengan modulo(p), dimana p adalah bilangan prima dan g adalah akar primitif mod p. Berikut adalah contoh protokol, dimana nilai non-secret diberi warna hijau dan yang nilai secret diberi warna merah dengan cetak tebal.

Gambar 5. Pengiriman data pada Diffie-Hellman key exchang[9]

1. Alice dan Bob setuju menggunakan bilangan prima p = 23 dan g = 5

2. Alice memilih angka rahasia a = 6, kemudian mengirimkan kepada Bob A = ga mod p

3. Bob memilih angka rahasia b = 15, kemudian mengirimkan kepada Alice B

6. Alice dan Bob sekarang sama-sama memiliki kunci yang sama, s =2. Hal ini dikarenakan 16 x 5 = 15 x 6. Jadi, ketika seseorang yang mengetahui angka rahasia ini juga dapat mengkalkulasi s dengan cara:

* s = 56 x 15 mod 23

2.2. Message Digest 5

Menurut Wenbo Mao[9], MD5 di desain oleh Ronald Rives pada tahun 1991 untuk menggantikan hash function sebelumnya, yaitu MD4. MD5 ialah fungsi kriptografi yang digunakan secara luas dengan hash value 128-bit. MD5 menerima masukan pesan dengan ukuran sembarang dan kemudian mengkonversi pesan tersebut dengan algoritma hash menjadi message digest berukuran 128 bit, yang merupakan rangkaian 32 digit karakter hexadesimal. Pada standard internet, MD5 telah dimanfaatkan secara bermacam-macam pada aplikasi keamanan dan MD5 juga umum digunakan untuk melakukan pengujian integritas sebuah file. MD5 digunakan secara luas dalam dunia perangkat lunak untuk menyediakan jaminan bahwa file yang diunduh belum terdapat perubahan. Dalam hal ini MD5 melakukan error-checking. MD5 dapat mengetahui file yang di diunduh tidak lengkap.

Pada sistem manajemen ini penggunaan MD5 hanya digunakan sebagai enkripsi data. Data yang dienkripsi tersebut akan dicocokkan satu sama lain, yaitu milik client dan milik database. Hasil dari pencocokan data yang sudah dienkripsikan tersebut dapat digunakan untuk mengetahui apakah pengguna yang sebenarnya atau tidak.

2.3. DBMS (Database Management System)

Menurut buku [2], sebuah sistem manajemen database atau DBMS adalah software yang dirancang untuk menjaga dan membatu dalam memanfaatkan koleksi data yang besar. Kebutuhan untuk sistem ini serta penggunaannya saat ini sedang berkembang pesat. Cara alternatif lainnya dalam menyimpan data adalah menyimpannya dalam sebuah file dan menulis aplikasi-kode khusus untuk mengelola data tersebut. Pada penggunaannya DBMS memiliki beberapa keuntungan penting, yaitu:

DBJVIS menyediakan sebuah abstract view dari sebuah data yang menyembunyikan detail tersebut.

 Efficient Data Access: sebuah DBMS menggunakan berbagai macam teknik canggih untuk menyimpan dan mengambil sebuah data dengan efisien. Fitur ini sangat penting bila sebuah data disimpan dalam sebuah tempat penyimpanan eksternal.

 Data Integrity and Security: bila data selalu diakses melalui DBMS, DBMS dapat memberikan suatu batasan integritas. Misalnya, sebelum memasukkan informasi gaji untuk karyawan, DBMS dapat memeriksa bahwa anggaran departemen tidak melebihi yang tersedia. Selain itu dapat mengatur akses kontrol data tersebut mengenai data apa saja yang dapat diliah oleh kelompok/kelas yang berbeda dari pengguna

 Administrasi Data: ketika beberapa pengguna berbagi data, pemusatan administrasi dapat dapat menawarkan perbaikan yang signifikan. Seseorang yang professional/berpengalaman bagaimana sebuah data di kelola, dan mengerti bagaimana perbedaan kelompok yang menggunakannya, dapat bertanggung jawab untuk mengatur representasi data untuk meminimalkan redudansi serta untuk fine-tuning tempat penyimpanan datanyanya untuk membuat pengambilan data menjadi efisien.

 Concurrent Access and Crash Recovery: sebuah DBMS menjadwalkan akses yang secara serentak sedemikian rupa sehingga seorang pengguna dapat berpikir bahwa datanya hanya diakses oleh seorang pengguna dalam suatu waktu. Lebih lanjut, DBMS melindungi pengguna dari kegagalan sistem.

yang cepat. Aplikasi DBMS juga lebih kuat daripada aplikasi stand-alone yang serupa dikarenakan banyak tugas penting yang ditangani oleh DBMS itu sendiri (dan tidak perlu di debug dan di tes di dalam aplikasinya).

2.3.1. Struktur DBMS

DBMS menerima perintah SQL, dan diizinkan dihasilkan dari berbagai antarmuka pengguna, untuk menghasilkan query evaluation plans, kemudian mengeksekusi query evaluation plans ini ke database dan mengembalikan jawaban tersebut(untuk penyederhanaannya: perintah SQL dapat ditambahkan di dalam host-language sebuah program/aplikasi, misalnya: Java atau COBOL program). Arsitektur yang digunakan pada DBMS adalah sebagai berikut:

2.3.2. Parallel DBMS

Menurut buku [4], Banyak aplikasi data-intensive memerlukan dukungan database yang sangat besar(misalnya, ratusan terabyte atau petabyte). Contoh aplikasinya adalah e-commerce, data pergudangan, dan data mining. Database yang sangat besar biasanya diakses melalui nomor transaksi dengan konkuren tinggi(misalnya, melakukan pemesanan secara on-line di sebuah took elektronik) atau dengan query yang kompleks(misalnya, query pengambilan keputusan).

Ide utama dari parallel DBMS ini adalah untuk membangun sebuah computer yang sangat kuat dari banyak komputer kecil, yang masing-masing memiliki rasio kinerja dan harga yang sangat baik, dengan rasio biaya yang jauh lebih rendah bila dibandingkan dengan sebuah komputer mainframe. Dengan penggunaan parallel DBMS, distribusi data dapat dimanfaatkan untuk meningkatkan kinerja(melalui paralelisme) dan ketersediaan akan data(melalui replikasi data). Prinsip ini dapat digunakan untuk menerapkan sistem database paralel, yaitu sistem dabase pada komputer paralel [DeWitt dan Gray, 1992;Valduriez,1993].

Sistem database dapat mengeksploitasi paralelisme dalam pengelolaan data dalam rangka untuk memberikan database database kinerja tinggi dan kemampuan ketersediaan data yang tinggi. Dengan demikian, mereka dapat mendukung database yang sangat besar dengan beban yang sangat tinggi. Idealnya, sebuah parallel DBMS harus mampu memberikan hal-hal berikut:

 High Performance: hal ini dapat diperoleh dengan beberapa solusi, yaitu: database-oriented operating system support, manajemen data paralel, optimisasi query, dan load balancing.

setiap saat dapat relatif tinggi. Data replikasi di beberapa node berguna untuk mendukung sistem fail-over, yaitu teknik toleransi kesalah yang memungkinkan pengalihan otomatis transaksi dari node yang gagal ke node lain yang menyimpan salinan dari data.  Extensibility: dalam sistem paralel, meningkatkan ukuran database

atau meningkatkan kinerja(troughput) akan lebih mudah. Extensibility adalah kemampuan untuk memperluas sistem dengan menambahkan kemampuan pengolahan dan kekuatan penyimpanan untuk sistem. Idealnya, sistem yang paralel ini harus mampu menunjukkan dua kemampuan extensibility, yaitu: linear speedup dan linear scaleup. Linear speedup mengacu kepada penambahan performa/kinerja sesuai dengan penambahan jumlah node. Sedangkan linear scaleup mengacu kepada ketetapan performa yang dimiliki baik itu dari ukuran database serta jumlah node yang dimiliki.

Gambar 7. Rasio Extensibility, baik dalam bentuk speedup(a) maupun scaleup(b) [2]

2.3.2.1. Arsitektur Fungsional

Melalui asumsi arsitektur client/database, fungsi yang didukung oleh paralel database dapat dibagi menjadi 3 subsistem yang hampir serupa dengan DBMS, yaitu:

pengguna dengan subsistem lainnya baik untuk masalah koneksi dan diskoneksi.

 Transaction Manager: menerima transmisi dari pengguna yang berhubungan dengan kompilasi query dan eksekusinya.

 Data Manager: menyediakan semua fungsi low-level yang dibutuhkan untuk menjalankan semua fungsi query di dalam paralel database.

Perbedaannya hanya bagaimana cara melakukannya dengan kondisi paralel, data partisinya, replikasi data, serta penyebaran transaksinya yang tergantung dari arsitekturnya.

2.3.2.2. Partisi Data Paralel

Solusi alternatif untuk penempatan data partisi penuh, dimana setiap relasi terfragmentasi di semuad node dalam sistem ada tiga macam, yaitu:

 Round-robin partitioning: penyimpanan tersebar paling sederhana, dimana distribusi data seragam.

 Hash partitioning: menerapkan fungsi hash untuk beberapa atribut yang memakai nomor partisi.

 Range partitioning: mendistribusikan data berdasarkan interval nilai(rentang) atribut tertentu.

Gambar 9. Macam-macam penyebaran data [2]

2.4. Client Server

Menurut buku [11], terminologi MIS(Management Information System), Client/Server computing adalah teknologi baru yang menghasilkan solusi untuk masalah manajemen data yang dihadapi oleh organisasi modern. Clien/Server adalah istilah yang digunakan untuk menggambarkan sebuah model komputasi untuk pengembangan sistem komputerisasi ini. Model ini didasarkan pada fungsi distribusi antara dua jenis proses independen dan otonom, yaitu: Server dan Client. Client adalah setiap proses yang yang meminta layanan tertentu dari sebuah database proses. Server adalah proses yang menyediakan layanan untuk client.

Ketika client dan database melakukan proses antara dua atau lebih komputer yang independen, database dapat memberikan layanan lebih dari satu client. Selain itu, client dapat meminta layanan dari beberapa database dari sebuah jaringan tanpa memperhatikan lokasi atau karakteristik fisik dari komputer dimana database proses berada. Jaringan antara client dan database terhubung bersamaan dan terikat satu sama lainnya, menyediakan media dimana client dan database saling terhubung dan berkomunikasi.

Gambar 10. Client/Server computing model p [1]

 Fax Server

Tujuan utama dari client adalah sebagai berikut:  Mengelola user interface

 Menerima dan memeriksa sintaks input pengguna  Proses aplikasi logika

 Menghasilkan permintaan database dan mengirimkan ke database  Menerima respon kembali dari database

Tujuan utama dari database adalah:

 Menerima dan memproses permintaan database dari pengguna  Memeriksa otorisasi

 Memastikan integritas tidak dilanggar

 Mengerjakan proses query dan mengirimkan responnya kembali ke client

 Menjaga sistem katalog

 Menyediakan akses database secara bersamaan  Menyediakan recovery control

2.5. RMI (Remote Method Invocation)

Metode pemanggilan objek bukanlah sebuah konsep yang baru. Bahkan sebelum pemrograman berorientasi objek, teknologinya sudah ada dimana digunakan untuk memanggil fungsi dan prosedur secara remote/jarak jauh. Sistem ini seperti remote procedure calls (RPCs) telah digunakan selama bertahun-tahun dan terus digunakan sampai saat ini. Implementasi populer RPC dikembangkan oleh Sun MicroSystem dan diterbitkan sebagai RFC 1057(yang membuat ulang versi sebelumnya, yang di terbitkan sebaga RFC 1050). Remote prosedure calls dirancang sebagai cara platform-neutral berkomunikasi antar aplikasi, terlepas dari sistem operasi atau perbedaan bahasa pemrograman.

2.5.1. Cara Kerja RMI

Sistem yang menggunakan RMI untuk berkomunikasi biasanya dibagi menjadi dua kategori: client dan database. Sebuah database menyediakan layanan RMI, dan client memanggil metode objek dari layanan ini.

Gambar 11. Arsitektur RMI, hubungan antara client dan host [1]

Sebuah database RMI harus mendaftarkan database tersebut dengan layanan pencarian(lookup service), yang mengizinkan sebuah client untuk menemukan mereka, atau mereka dapat membuat sebuah referensi ke layanan tersebut dengan cara yang lain.

sebuah aplikasi untuk mendaftarkan layanan RMI atau mendapatkan sebuah referensi ke sebuah layanan khusus. Setelah database telah terdaftar, database akan menunggu permintaan dari client RMI.

Gambar 12. menggambarkan mendaftarkan layanan dengan RMI registri tunggal [1]

Terkait dengan setiap layanan pendaftaran adalah nama (direpresentasikan sebagai string), untuk mengizinkan client memilih layanan yang sesuai. Jika layanan berpindah dari satu database ke database yang lain, client hanya perlu melihat registri lagi untuk menemukan lokasi baru. Hal ini membuat lebih fault-tolerant sistem jika sebuah layanan tidak dapat diakses yang dikarenakan mesin sedang down, seorang administrator sistem dapat meluncurkan sebuah sistem baru yang memberikan layanan yang sama pada sistem lain dan mendaftarkanya pada RMI registry. Dengan menyediakan registri tetap aktif, database dapat dimatikan atau dinyalakan atau berpindah dari sebuah host ke host. Registri disini tidak peduli dari mana layanan dari sebuah host diberikan.

Client RMI akan mengirim RMI sebuah pesan untuk memanggil sebuah fungsi objek secara remote. Sebelum pemanggilan fungsi secara remote, client harus memiliki referensi remote object. Hal ini biasanya diperoleh dengan mencari sebuah layanan di registri RMI.

dapat di representasikan menggunakan sintak URL. Format ini digunakan oleh RMI untuk merepresentasikan sebuah remote object:

Dimana hostname merepresentasikan sebuah database (atau alamat IP), port sebuah lokasi dari sebuah layanan tersebut, dan servicename adalah sebuah deskripsi dari layanan yang dipilih.

Setelah sebuah referensi objek diperoleh (baik melalui rmiregistry, sebuah layanan pencari, atau dengan membaca URL referensi objek dari file), client dapat berinteraksi dengan remote service. Rincian jaringan dari sebuah permintaan benar-benar transparan bagi para pengembang aplikasi, dimana bekerja secara remote object menjadi semudah bekerja dengan sistem lokal. Hal ini dicapai melalui pemikiran cerdas dari divisi RMI yang membagi sistem RMI menjadi dua komponen, yaitu stub dan skeleton.

Stub disini berfungsi sebagai sebuah proxy, menyampaikan permintaan objek ke RMI database. Layanan RMI didefinisikan sebagai sebuah interface, bukan sebagai suatu implementasi. Stub mengimplementasikan inteface tertentu, dimana aplikasi client dapat menggunakannya sama seperti implementasi objek yang lainnya. Namun, daripada melakukan proses itu sendiri, stub mengirimkan pesannya itu ke penyedia layanan RMInya, menunggu respon, dan mengembalikan hasil respon tesebut kepada pengirimnnya.

Gambar 13. cara kerja stub dan skeleton [1]

Pada database RMI, skeleton bertanggung jawab untuk mendengarkan permintaan yang masuk dan memberikannya pada penyedia layanan RMI. Skeleton tidak menyediakan implementasi layanan RMI. Namun hanya bertindak sebagai penerima permintaan. Setelah pengembang membuat RMI interface, pengembang masih harus menyediakan implementasi yang nyata dari interface-nya. Implementasi ini akan dipanggil oleh skeleton yang fungsinya dilakukan secara tepat dan hasilnya dikirimkan kembali kepada stub di RMI client. Model ini membuat pemrograman lebih sederhana.

2.5.2. Java Library

Java Library melayani 3 tujuan dalam Java Platform:

 Menyediakan programmer satu set fasilitas yang berguna, seperti container classes (berisi sebuah kelas) dan regular expressions (berisi sebuah method)

 Menyediakan antar muka abstrak kedalam sebuah tugas yang biasanya tergantung pada perangkat keras dan sistem operasi seperti network access dan file access yang biasanya tergantung dari kemampuan asli platform itu sendiri.

BAB III

ANALISIS DAN PERANCANGAN SISTEM

3.1. Metode Pengembangan Perangkat Lunak

Sebuah software development process (SDP), yang juga dikenal sebagai software engineering process (SEP), menentukan who, what, when, dan how dalam mengembangkan perangkat lunak. Dimana proses pengembangannya dijelaskan dalam gambar berikut:

Gambar 14. pengembangan perangkat lunak [6]

Dalam pengembangannya terdapat beberapa metode yang digunakan, salah satunya adalah Unified Process (UP).

3.1.1. Unified Process (UP)

Menurut Jim Arlow dan Ila Neustadt[6], UP adalah generic software development process yang biasa digunakan dalam sebuah organisasi dan untuk proyek tertentu. UP memiliki tiga aksioma dasar, yaitu:

Risk atau faktor resiko adalah salah satu yang menggerakkan UP, karena bila kita tidak secara langsung memikirkan resikonya, maka suatu saat resiko yang tidak dipikirkan tersebut dapat berbalik menyerang. Tentunya semua orang yang bekerja untuk mengembangkan perangkat lunak akan setuju mengenai hal ini, dan UP mengenali hal ini dengan memprediksi konstruksi perangkan lunak pada bagian anlisa resiko.

Tujuan UP pada arsitektur pengembangan sistem perangkat lunak (architecture centric) adalah untuk mengembangkan dan merubah sistem arsitektur yang kasar. Arsitektur mendeskripsikan aspek strategi mengenai bagaimana sebuah sebuah sistem dipilah menjadi beberapa komponen, dan bagaimana masing-masing komponen tersebut berinteraksi dan ditempatkan pada hardware. Kualitas sistem arsitektur akan mempengaruhi kualitas sistem.

UP itu iterative dan incremental. Aspek iterative dari UP berarti kita memecah sebuah projek menjadi beberapa subprojek yang membuat sebuah sistem yang berfungsi dari sebuah bagian kecil, yang akhirnya menuju bentuk sistem yang berfungsi secara penuh. Dengan kata lain, kita membuat sebuah perangkat lunak dengan proses yang perlahan agar sampai ke tujuan.

Lima inti kerja dari UP:

 Requirements: mengenai apa yang dibutuhkan sistem  Analysis: mengenai bagaimana membuat dan penataannya

 Design: mengenai bagaimana merealisasikannya di dalam sistem arsitekturnya

 Implementation: membuat perangkat lunak

 Test: memverifikasikan bahwa implementasinya sesuai dengan keinginan.

UP memiliki empat fase, yang masing-masing berakhir sebagai tonggak utama:

 Inception: proses pembuatan proyek, Life Cycle Objectives

 Elaboration: mengevolusikan sistem arsitekturnya, Life Cycle Architecture

 Construction: membuat perangkat lunak, Initial Operational Capability

 Transition: menyebarkan perangkat lunak kepada pengguna: Product Release.

3.2. Analisa Sistem

Sesuai dengan uraian pada latar belakang, penggunaan account sangat dibutuhkan sebagai tanda pengenal pada suatu aplikasi, terutama aplikasi yang ada di internet. Sistem manajemen ini dirancang dengan menggunakan

teknologi Remote Method Invocation (RMI), menggunakan bahasa

Gambar 16. Arsitektur sistem yang akan dibuat

Sistem yang dibangun ini diharapkan dapat memenuhi permintaan pengguna dalam memproses/memiliki sebuah account yang dapat digunakan dalam beberapa aplikasi tersebut. Dengan catatan bahwa aplikasi tersebut menggunakan sistem manajemen ini serta terkoneksi dengan database yang menyediakan fasilitas ini.

3.3. Proses Sistem

Sistem bekerja melalui beberapa tahap, yaitu:  Proses otentikasi

 Proses Manajemen Data account

o Proses Manajemen Data account Pengguna

o Proses Manajemen Data accountAdministrator

o Proses Konfigurasi DatabaseServer dan Controller Server

3.3.1. Proses Otentikasi

Salah satu fungsi di aplikasi ini adalah proses otentikasi, dimana terjadi pencocokan antara data yang terdapat pada database sistem dengan data yang dimasukkan. Pada proses ini terjadi beberapa tahapan:

Gambar 17. Prosedur Otentikasi

2. Pengiriman status angka random untuk bagian status ‘p’ dan ‘g’ pada algoritma Diffie-Hellman kepada database untuk penghitungan yang serupa pada password yang terdapat pada database.

3. Pengolahan data yang telah diberikan sesuai dengan prinsip kerja dari algoritma Diffie-Hellman menjadi sebuah data untuk dicocokkan antara client dan database. Disana terjadi penghitungan antara data MD5 yang kemudian dihitung dengan bantuan status ‘p’ dan ‘g’ yang

digunakan pada algoritma Diffie-Hellman, kemudian hasil

penghitungan tersebut di enkripsi kembali dengan menggunakan MD5. 4. Dilakukan pencocokan hasil enkripsi pada client, bila hasil enkripsi sama dengan yang dimiliki oleh database maka client akan membalas dengan memberikan status TRUE. Namun, bila hasil enkripsi tidak sama, maka client akan memberikan status FALSE.

Gambar 18. Proses Otentikasi, data dikirimkan antar aplikasi

3.3.2. Proses Manajemen Data Account 3.3.2.1. Proses Manajemen Password User

database di distribusikan secara merata sesuai dengan jumlah database yang ada. Proses yang dilakukan adalah sebagai berikut:

Gambar 19. Proses Distribusi Data

1. Pembacaan index terakhir dari total database yang digunakan, angka 1 untuk database pertama, angka 2 untuk database kedua, dan seterusnya. Hasil dari pembacaan index digunakan untuk menentukan dimana data tersebut akan diletakkan.

2. Setelah pembacaan index, dilakukan pengecekan mengenai query yang diberikan, baik query untuk insert, update, maupun delete. Setelah query diperiksa maka akan dilakukan pengiriman pengolahan fungsi ke databasedatabase dimana pengerjaan untuk query tersebut dilakukan. 3. Pelaporan kepada user mengenai keberhasilan dalam melakukan kerja

query.

Seperti terlihat pada gambar diatas, proses ini diberlakukan kepada pengguna. Baik pengguna yang akan melakukan registrasi maupun pengguna yang akan melakukan perubahan pada data registrasinya. Sehingga pada proses disini dapat dibedakan menjadi dua macam manajemen pengguna, yaitu:

 Manajemen Registrasi

3.3.2.2. Proses Manajemen Data User

Proses pembacaan seluruh data dapat dilakukan dengan dua cara, yaitu dengan langsung menggunakan aplikasi pengecekan database seperti MySQL, atau dengan aplikasi pembacaan database yang dimiliki oleh Administator. Proses yang dilakukan adalah :

Gambar 20. Proses Pembacaan

1. Proses pencarian dengan memanggil fungsi select pada database yang dituju. Proses ini dilakukan dengan cara memberikan tugas kepada masing-masing database database untuk memanggil fungsi select dan

kemudian mengembalikan nilai seluruh datanya kepada

Administratornya.

2. Bila administrator akan melakukan editing terhadap data di database database. Maka tiap tabel dari database tersebut akan merujuk langsung ke tempat dimana data yang diubah berada.

3.4. Deskripsi Umum Sistem

Sistem otentikasi ini memiliki dua jenis aktor, yaitu sebagai user dan sebagai administrator. User adalah sebagai pengguna yang akan melakukan otentikasi pada sistem, sedangkan administrator adalah sebagai pihak yang memiliki akses penuh terhadap sistem database otentikasi sekaligus sebagai pengelola sistem

3.5. Use-Case Proses Manajemen Data Account 3.5.1. Use-Case Diagram

Dari spesifikasi rancangan sistem diatas maka menghasilkan use case yaitu:

Gambar 21 Use Case Diagram

3.5.1. Use-Case Model

Sistem Penelusuran Skripsi yang akan dikembangkan dapat diakses oleh 2 aktor pengguna yaitu administrator dan user. Pada tabel di bawah ini akan

dipaparkan mengenai deskripsi untuk tiap-tiap aktor pengguna :

Tabel 1 Use-Case Model

3.5.1. Use-Case scenario 1. Registrasi

Aktor Keterangan

Administrator

1) Menangani manajemen data user meliputi

penambahan, pengubahan, dan penghapusan data user.

User

1) Dapat melakukan registrasi.

2) Dapat melakukan login sebagai user (otentikasi). 3) Dapat mengubah password milik user itu sendiri.

Nama Use case Registrasi User

ID use case 1

Prioritas High

Pelaku bisnis utama User

Deskripsi Use case ini menggambarkan proses registrasi pada user

Pemicu Use case ini digunakan apabila ada user yang mengakses situs registrasi sistem

Langkah umum Aksi actor Respon sistem

Step 1:User memilih menu

Step 6: Sistem kembali ke halaman utama. Langkah alternatif Step 3:User memilih tombol batal

2. Login

Kesimpulan Use case ini berhenti apabila user telah berhasil melakukan registrasi atau mengklik tombol cancel pada halaman registrasi

Pasca kondisi User berhasil masuk ke dalam halaman registrasi.

Nama Use case Login (Otentikasi)

ID use case 2

Prioritas High

Pelaku bisnis utama User

Deskripsi Use case ini menggambarkan proses login yang

dilakukan user

Pra-kondisi Pengguna berada pada halaman login aplikasi yang

sudah terdaftar pada sistem

Pemicu Use case ini digunakan apabila ada user yang

mengakses aplikasi yang menggunakan proses otentikasi sistem

Langkah umum Aksi actor Respon sistem

Step 1:User mengisi username dan password Step 2:User menekan tombol login

Step 3: Sistem

3. Manajemen Password User

Step 4: Sistem

menampilkan halaman yang dituju

Langkah alternatif Step 4: Bila hasi validasi gagal, maka muncul pesan login gagal kepada user

Kesimpulan Use case ini berhenti apabila user telah berhasil melakukan login atau mengklik tombol cancel pada halaman login

Pasca kondisi User berhasil masuk ke dalam halaman utama aplikasi.

Nama Use case Updatepassword user

ID use case 1

Prioritas High

Pelaku bisnis utama User

Deskripsi Use case ini menggambarkan proses merubah password

pada user

Pra-kondisi Pengguna berada pada halaman login

Pemicu Use case ini digunakan apabila ada user yang

mengakses situs registrasi sistem

Langkah umum Aksi actor Respon sistem

Step 1:User melakukan login pada sistem

4. Manajemen Data User - Insert

Step 3:User mengisi form registrasi dengan username, password, dan retype update, reset dan logout

Step 5: Sistem memberi pesan password sudah dirubah,

Step 6: Sistem kembali ke halaman update. Langkah alternatif Step 3:User memilih tombol logout

Step 4: Sistem kembali ke halaman login

Kesimpulan Use case ini berhenti apabila user telah berhasil melakukan ubah password atau mengklik tombol cancel pada halaman registrasi

Pasca kondisi User berhasil masuk ke dalam halaman registrasi.

ID use case 5

Prioritas High

Pelaku bisnis utama Administrator

Deskripsi Use case ini menggambarkan proses insert

Pra-kondisi Administrator sudah berada pada halaman utama Admin

Pemicu Use case ini digunakan apabila ada Administrator ingin menambah user

Langkah umum Aksi actor Respon sistem

5. Manajemen Data User - Update mengklik tombol insert.

Step 7: Sistem menampilkan pesan bahwa user sudah dibuat.

Step 8: Sistem kembali ke menu utama

Langkah alternatif Step 3:Administrator mengklik logout. Step 5: Sistem kembali ke halaman utama.

Kesimpulan Use case ini berhenti apabila Administrator telah berhasil melakukan insert atau menekan tombol back to main menu pada halaman insert

Pasca kondisi Administrator menerima pesan bahwa proses insert

berhasil

Nama Use case Manajemen Data User - Update

ID use case 6

Prioritas High

Deskripsi Use case ini menggambarkan proses update

Pra-kondisi Administrator sudah berada pada halaman utama Admin

Pemicu Use case ini digunakan apabila ada Administrator ingin meng-updateuser

Langkah umum Aksi actor Respon sistem

6. Manajemen Data User - Delete

Step 8: Sistem kembali ke halaman utama Langkah alternatif Step 3:Administrator mengklik logout.

Step 5: Sistem kembali ke halaman utama.

Kesimpulan Use case ini berhenti apabila Administrator telah berhasil melakukan update atau menekan tombol back to main menu pada halaman update

Pasca kondisi Administrator menerima pesan bahwa proses update

berhasil

Nama Use case Manajemen Data User - Delete

ID use case 7

Prioritas High

Pelaku bisnis utama Administrator

Deskripsi Use case ini menggambarkan proses delete

Pra-kondisi Administrator sudah berada pada halaman utama Admin

Langkah umum Aksi actor Respon sistem mengklik tombol delete.

Step 2: Sistem delete. Pada halaman ini terdapat form pengisian username serta tiga

7. Manajemen Data User - Search

Step 5: Sistem kembali ke halaman utama.

Kesimpulan Use case ini berhenti apabila Administrator telah berhasil melakukan delete atau menekan tombol back to main menu pada halaman delete

Pasca kondisi Administrator menerima pesan bahwa proses delete

berhasil

Nama Use case Manajemen Data User - Delete

ID use case 7

Prioritas High

Pelaku bisnis utama Administrator

Deskripsi Use case ini menggambarkan proses melihat password

Pra-kondisi Administrator sudah berada pada halaman utama Admin

Pemicu Use case ini digunakan apabila ada Administrator ingin melihat password user

Langkah umum Aksi actor Respon sistem

Step 1:Administratorlogin pada sistem

Step 2: Sistem

Step 3:Administrator mengklik tombol search.

search serta logout

Step 8: Sistem kembali ke halaman utama Langkah alternatif Step 3:Administrator mengklik logout.

Step 5: Sistem kembali ke halaman utama.

Kesimpulan Use case ini berhenti apabila Administrator telah berhasil melakukan search atau menekan tombol back to main menu pada halaman delete

Pasca kondisi Administrator menerima pesan bahwa proses delete

8. Setting dan Start/StopServer

Pra-kondisi Administrator sudah menjalankan aplikasi server

Pemicu Use case ini digunakan apabila nAdministrator ingin

menjalankan program.

Langkah umum Aksi actor Respon sistem

Step 5:Administrator

Langkah alternatif Step 5:Administrator memilih tombol exit Step 6: Sistem dimatikan

Step 10: Administrator memilih stopserver Step 11: Sistem menampilkan pesan server mati.

9. Setting dan Start/StopServer Database exit

Pasca kondisi Administrator menerima pesan bahwa server sudah

berjalan

Nama Use case Setting dan Start/StopServer Database

ID use case 8

Prioritas High

Pelaku bisnis utama Administrator

Deskripsi Use case ini menggambarkan proses setting, start dan stopserver

Pra-kondisi Administrator sudah menjalankan aplikasi server

Pemicu Use case ini digunakan apabila nAdministrator ingin

menjalankan program.

Langkah umum Aksi actor Respon sistem

Step 5:Administrator

3.6. Diagram Activity

Merupakan diagram yang menjelaskan aktivitas antara user dengan sistem.

3.6.1. Registrasi

Gambar 22 Diagram Activity Registrasi User Step 6: Sistem dimatikan

Step 10: Administrator memilih stopserver Step 11: Sistem menampilkan pesan server mati.

Kesimpulan Use case ini berhenti apabila Administrator telah berhasil melakukan start server atau menekan tombol exit

Pasca kondisi Administrator menerima pesan bahwa server sudah

3.6.1. Login

3.6.2. Manajemen Password User

3.6.3. Manajemen Data User - Insert

3.6.4. Manajemen Data User - Update

3.6.5. Manajemen Data User - Delete

3.6.6. Manajemen Data User - Search

3.6.7. Setting dan Start/Stop Server

3.6.8. Setting dan Start/Stop Server Database

Gambar 30 Diagram Activity Setting dan Start/Stop Server Database

3.7. Model Analisis

Merupakan suatu proses untuk menterjemahkan skenario usecase menjadi kelas analisis. Dalam kelas analisis terdapat tiga jenis, yaitu form/boundary, Controller, dan entity.

3.7.1. Relasi Use-Case

3.7.1.1. Diagram Sequence Registrasi