TUGAS 2

KEAMANAN JARINGAN KOMPUTER

Kerberos, X.509, dan SSO

Dosen Pengampu : Dr. Tri Kuntoro Priyambodo, M.Sc.

ADITYA WIJAYANTO

13/357253/PPA/04465

PROGRAM STUDI MAGISTER ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS GADJAH MADA
YOGYAKARTA
2014

1. DASAR KERBEROS

1.1 Authentication, Integrity, Confidentiality, dan Authorization

Authentication atau autentikasi adalah proses verifikasi identitas dari seorang anggota yang
memberikan suatu data, dan integritas dari data tersebut. Principal adalah anggota yang
identitasnya telah diverifikasi. Verifier adalah anggota yang meminta jaminan identitas dari
principal. Integritas data adalah jaminan bahwa data yang diterima adalah data yang sama
dengan data yang dikirimkan. Mekanisme autentikasi berbeda dalam jaminan yang mereka
berikan: beberapa menyatakan bahwa data dibuat oleh principal pada satu titik di masa lampau,
beberapa menyatakan bahwa data dibuat oleh principal di masa sekarang (present), dan beberapa
yang lainnya lagi menyatakan bahwa data baru saja dibuat oleh principal ketika dikirimkan.
Mekanisme juga berbeda dalam hal jumlah verifier: beberapa ada yang menggunakan verifier
tunggal untuk setiap message, ada yang menggunakan multiple verifiers. Perbedaan ketiga
adalah dalam hal apakah mekanisme tersebut mendukung non-repudiation, yaitu kemampuan
verifier untuk membuktikan kepada pihak ketiga bahwa pesan tersebut benar-benar dibuat oleh
principal. Karena perbedaan-perbedaan ini mempengaruhi performa, maka kita perlu melihat
kebutuhan-kebutuhan yang dibutuhkan oleh masing-masing aplikasi sebelum kita menentukan
metoda mana yang akan digunakan. Contohnya, autentikasi untuk electronic mail (email)
membutuhkan multiple verifiers dan non- repudiation, tetapi toleran terhadap latensi waktu.

Layanan

keamanan

lainnya

adalah

kerahasiaan

(confidentiality)

dan

autorisasi

(authorization). Confidentiality adalah perlindungan informasi terhadap mereka yang tidak

seharusnya menerima informasi tersebut. Kebanyakan metode autentikasi yang baik memberikan
pilihan untuk confidentiality ini. Authorization adalah proses dimana seseorang menentukan
apakah principal dapat melakukan suatu operasi. Autorisasi biasanya dilakukan setelah principal
melalui proses autentikasi.

1.2 Apa itu Kerberos

Kerberos merupakan layanan autentikasi yang dikembangkan oleh MIT (Massachusetts

Institute of Technology) Amerika Serikat, dengan bantuan dari Proyek Athena. Tujuannya
adalah untuk

memungkinkan pengguna (user) dan layanan (service) untuk

saling

mengautentikasi satu dengan yang lainnya. Dengan kata lain, saling menunjukkan identitasnya.
Tentu saja ada banyak cara untuk menunjukkan identitas pengguna kepada layanan tersebut.
Salah satu cara yang paling umum adalah dengan penggunaan password. Seseorang log in ke
dalam server dengan mengetikkan username dan password, yang idealnya hanya diketahui oleh
pengguna dan server tersebut.
Server tersebut kemudian diyakinkan bahwa orang yang sedang berusaha mengaksesnya
adalah benar-benar pengguna. Namun, penggunaan password ini memiliki banyak kelemahan.
Misalnya seseorang memilih password yang mudah ditebak oleh orang lain dalam beberapa kali
usaha percobaan. Dalam hal ini dikatakan bahwa password tersebut lemah. Masalah lainnya
timbul ketika password ini akan dikirimkan melalui jaringan: Password tersebut harus melalui
jaringan tanpa dienkripsi. Dengan kata lain, jika ada orang lain yang mendengarkan jaringan
tersebut dapat mencegat password itu dan mendapatkannya kemudian menggunakannya untuk
masuk sebagai pengguna.
Inovasi utama dalam Kerberos adalah gagasan bahwa password tersebut dapat dilihat
sebagai suatu shared secret, sesuatu rahasia yang hanya pengguna dan server yang
mengetahuinya. Menunjukkan identitas dilakukan tanpa pengguna harus membuka rahasia
tersebut. Ada suatu cara untuk membuktikan bahwa kita mengetahui rahasia tersebut tanpa
mengirimnya ke jaringan.
1.3 Dasar Dasar Kerberos

Pendekatan dasar dari Kerberos adalah menciptakan suatu layanan yang tujuan satu-satunya
adalah untuk autentikasi. Alasannya adalah untuk membebaskan layanan tersebut dari keharusan
untuk mengurusi record akun pengguna. Dalam pendekatan ini, pengguna dan layanan harus
memercayai Kerberos authentication server (AS). AS ini berperan sebagai pengenal kepada
mereka. Untuk melakukan hal ini, pengguna dan layanan harus mempunyai shared secret key

yang telah terdaftar di AS. Key tersebut dinamakan long-term keys, karena memang digunakan
dalam jangka waktu yang cukup lama, yaitu berminggu-minggu atau berbulan-bulan. Ada tiga
langkah dasar dalam proses autentikasi pengguna kepada layanan. Pertama, pengguna
mengirimkan request kepada AS, meminta untuk mengautentikasi dirinya terhadap layanan.
Dalam langkah kedua, AS bersiap untuk memperkenalkan pengguna dan layanan satu sama
lainnya. Hal ini dilakukan dengan cara menciptakan suatu secret key yang baru dan random yang
akan dibagikan hanya kepada pengguna dan layanan.
AS mengirimkan pesan kepada pengguna yang terdiri atas dua bagian. Satu bagian
mengandung random key bersama nama layanan, yang dienkripsi dengan long-term key milik
pengguna. Bagian lainnya mengandung random key yang sama bersama nama pengguna, yang
dienkripsi dengan long-term key milik layanan. Dalam bahasa Kerberos, pesan yang pertama
sering disebut credentials, sedangkan pesan yang kedua disebut ticket, dan random key tersebut
disebut dengan session key.
Pada tahap ini, hanya pengguna yang mengetahui session key. Pengguna membuat suatu
pesan, misalnya timestamp, kemudian dienkripsi menggunakan session key. Pesan ini disebut
authenticator. Pesan authenticator ini dikirimkan bersama dengan ticket kepada layanan.
Kemudian layanan mendekripsikan ticket dengan long-term key-nya, mendapatkan session key,
yang pada gilirannya digunakan untuk mendekripsikan authenticator. Layanan tersebut
memercayai AS, sehingga ia dapat yakin bahwa hanya pengguna yang terdaftar yang dapat
membuat authenticator semacam itu. Hal ini mengakhiri proses autentikasi pengguna terhadap
layanan. Bagaimana Kerberos beroperasi atau bekerja akan dijelaskan dengan lebih detail pada
bab selanjutnya.

1.4 Ticket Granting Server

Salah satu ketidaknyamanan dalam penggunaan password adalah setiap kali kita mengakses
layanan, maka kita harus mengetikkan password tersebut. Hal tersebut dapat menjadi
menyulitkan jika kita memiliki banyak akun dan kita harus memasukkan password tersebut satu
per satu. Mungkin kita akan mencoba membuat password yang mudah untuk diketik, dan sebagai
akibatnya maka password kita tersebut akan menjadi mudah untuk ditebak. Dan jika kita
menggunakan password yang sama untuk setiap akun kita, maka jika password kita tersebut

terbongkar, seluruh akun kita menjadi rentan ditembus. Kerberos mengatasi masalah ini dengan
memperkenalkan suatu layanan baru, yaitu Ticket Granting Server (TGS). TGS secara logika
berbeda dari AS, meskipun mungkin mereka berada dalam satu mesin yang sama (keduanya
sering disebut sebagai KDC Key Distribution Center) Tujuan dari TGS adalah untuk
menambahkan layer tambahan sehingga pengguna hanya perlu untuk memasukkan password
sebanyak satu kali saja.
Ticket dan session key yang didapat dari password tersebut digunakan untuk ticket
selanjutnya. Jadi, sebelum mengakses suatu layanan regular, pengguna meminta ticket dari AS
untuk berbicara dengan TGS. Ticket ini disebut ticket granting ticket (TGT) , sering juga
disebut sebagai initial ticket. Session key untuk TGT dienkripsi menggunakan long- term key
milik pengguna, sehingga password dibutuhkan untuk mendekripsikannya kembali dari respon
AS kepada pengguna. Setelah menerima TGT, kapanpun pengguna ingin mengakses layanan,
dia meminta ticket bukan dari AS tetapi dari TGS. Lebih jauh lagi, jawabannya tidak dienkripsi
menggunakan secret key milik pengguna, tetapi menggunakan session key yang datang bersama
TGT, sehingga password pengguna tidak diperlukan untuk mendapatkan session key yang baru.
Hal tersebut dapat diilustrasikan sebagai berikut. Bayangkan Anda adalah seorang karyawan di
sebuah gedung. Anda

menunjukkan kartu ID regular untuk mendapatkan kartu ID guest.

Sekarang, ketika Anda ingin memasuki berbagai ruangan di gedung tersebut, Anda tidak
menunjukkan kartu ID regular lagi dan lagi, yang mungkin dapat mudah sekali hilang atau dicuri
orang, tetapi Anda tinggal menunjukkan kartu ID guest yang hanya berlaku untuk suatu waktu
yang singkat saja.
Jika kartu ID guest tersebut hilang atau dicuri, Anda dapat dengan segera memblokirnya dan
membuat kartu yang baru, suatu hal yang tidak dapat dilakukan terhadap kartu ID regular.
Keuntungan dari hal ini adalah jika password biasanya valid untuk jangka waktu yang panjang,
misalnya berminggu-minggu atau berbulan-bulan, maka TGT hanya valid untuk jangka waktu
yang pendek, misalnya hanya delapan hingga sepuluh jam saja. Setelah itu, TGT tidak dapat
digunakan lagi oleh siapapun. TGT ini disimpan dalam credentials cache.

1.5 Operasi Kerberos

Pada bab ini akan dijelaskan operasi atau cara kerja Kerberos secara lebih detail. Sebelum
menjelaskan bagaimana kerberos beroperasi atau bekerja, kita harus mengetahui paket apa saja
yang dikirim di antara pengguna dan KDC (AS dan TGS), dan antara pengguna dengan layanan
selama proses autentikasi. Perlu diingat bahwa layanan tidak pernah berkomunikasi secara
langsung dengan KDC (Key Distribution Center). Berikut adalah daftar paket-paket:

AS_REQ adalah request autentikasi pengguna awal. Pesan ini ditujukan kepada
komponen KDC, yaitu AS.

AS_REP adalah jawaban dari AS terhadap pesan sebelumnya. Pada dasarnya pesan
ini mengandung TGT (dienkripsi menggunakan TGS secret key) dan session key
(dienkripsi menggunakan secret key dari pengguna).

TGS_REQ adalah request dari pengguna kepada Ticket Granting Server (TGS)
untuk mendapatkan service ticket. Paket ini mengandung TGT yang didapat dari
pesan sebelumnya dan authenticator yang dibuat oleh pengguna dan dienkripsi
dengan session key.

TGS_REP adalah jawaban dari Ticket Granting Server terhadap pesan sebelumnya.
Dalam paket ini terdapat service ticket yang diminta (dienkripsi dengan secret key
dari layanan) dan session key milik layanan yang dibuat oleh TGS dan dienkripsi
dengan session key sebelumnya yang dibuat oleh AS.

AP_REQ adalah request yang dikirimkan oleh pengguna kepada layanan/aplikasi

agar dapat mengakses layanannya. Komponennya adalah service ticket yang didapat
dari TGS dengan jawaban sebelumnya dan authenticator yang dibuat oleh pengguna,
tetapi kali ini dienkripsi menggunakan session key milik layanan (dibuat oleh TGS).

AP_REP adalah jawaban yang diberikan oleh layanan kepada pengguna untuk
membuktikan bahwa layanan tersebut adalah benar merupakan layanan yang ingin
diakses oleh pengguna. Paket ini tidak selalu diminta.

1.5.1 Authentication Server Request (AS_REQ)

Pada tahap ini, pengguna meminta AS untuk mendapatkan Ticket Granting Ticket. Request
ini tidak dienkripsi dan tampak seperti ini:

1.5.2 Authentication Server Reply (AS_REP)

Ketika

pesan

sebelumnya

masuk,

AS

memeriksa

apakah

PrincipalClient

dan

PrincipalService berada di database KDC. Jika salah satu saja dari antaranya tidak ada, maka
pesan error dikirimkan kepada pengguna. Jika keduanya ada, maka AS akan memroses sebagai
berikut:

Secara random, AS akan membuat session key yang akan menjadi rahasia antara
pengguna dan TGS, sebutlah SKTGS.

AS membuat Ticket Granting Ticket. Di dalamnya terdapat request dari principal

pengguna, principal layanan, daftar IP address, tanggal dan waktu, lifetime, dan
SKTGS.

AS membuat dan mengirimkan balasan yang berisi: ticket yang dibuat

sebelumnya yang dienkripsi menggunakan secret key untuk layanan (KTGS),
principal layanan, timestamp, lifetime, dan session key semuanya dienkripsi
menggunakan secret key untuk pengguna melakukan request terhadap layanan
(KUSER)

1.5.3 Ticket Granting Server Request (TGS_REQ)

Pada tahap ini, pengguna yang sudah terautentikasi (artinya dalam credential cache nya
terdapat TGT dan session key SKTGS) dan ingin mengakses layanan tetapi belum mempunyai
tiket yang sesuai, mengirimkan request (TGS_REQ) kepada Ticket Granting Service dengan
konstruksi sebagai berikut:

Membuat authenticator dengan principal pengguna, timestamp dari mesin

pengguna dan mengenkripsi semuanya dengan session key yang dibagi bersama
dengan TGS.

Membuat paket request yang berisi: principal layanan yang mana dibutuhkan
ticket dan lifetime yang tidak dienkripsi, Ticket Granting Ticket yang sudah
dienkripsi menggunakan key dari TGS, dan authenticator yang baru saja dibuat

1.5.4 Ticket Granting Server Reply (TGS_REP)

Ketika pesan sebelumnya tiba, pertama-tama TGS memverifikasi bahwa principal dari
layanan yang diminta ada di dalam database KDC. Jika ada, TGS membuka TGT dan
mengekstrak session key SKTGS yang digunakan untuk mendekipsikan authenticator. Agar
service ticket dapat dibuat, TGS memeriksa apakah kondisi-kondisi ini tercapai:

TGT belum kadaluwarsa

PrincipalCLIENT yang terdapat pada authenticator cocok dengan yang ada pada
TGT

Authenticator tidak terdapat pada replay cache dan belum kadaluwarsa

Jika IP_List tidak kosong, maka TGS memeriksa apakah alamat IP sumber dari
paket request terdapat pada list tersebut

Kondisi-kondisi tersebut di atas membuktikan bahwa TGT benar- benar kepunyaan

pengguna yang melakukan request dan kemudian TGS memulai proses sebagai berikut:

Secara random, TGS membuat session key yang akan menjadi rahasia antara
pengguna dengan layanan, sebutlah SKSERVICE.

TGS membuat service ticket yang di dalamnya berisi principal pengguna, principal
layanan, daftar alamat IP, tanggal dan waktu, lifetime, dan SKSERVICE. Ticket ini
disebut TSERVICE

TGS mengirim pesan balasan yang berisi: ticket yang baru saja dibuat yang
dienkripsi menggunakan secret key milik layanan (KSERVICE), principal
layanan, timestamp, lifetime, dan session key yang baru, semuanya dienkripsi
menggunakan session key yang diekstrak dari TGT.

1.5.5 Application Request (AP_REQ)

Pengguna, yang mempunyai credential untuk mengakses layanan, dapat meminta server
layanan agar ia dapat mengakses sumber-sumber melalui pesan AP_REQ. Tidak seperti pesanpesan sebelumnya dimana KDC terlibat, AP_REQ bukanlah standar tetapi bervariasi bergantung
aplikasi yang digunakan. Oleh karena itu, programmer aplikasi harus membuat strategi dimana
pengguna dapat menggunakan credentialnya untuk membuktikan identitasnya kepada server.
Contoh strategi yang dapat digunakan adalah sebagai berikut:

Pengguna membuat authenticator yang berisi principal pengguna dan timestamp,

dan mengenkripsi semuanya dengan menggunakan session key SKSERVICE

Membuat paket request yang berisi ticket layanan TSERVICE yang dienkripsi
menggunakan secret key nya dan authenticator yang baru saja dibuat.

Ketika request sebelumnya tiba, server layanan membuka ticket menggunakan secret key
untuk layanan yang diminta dan mengekstrak session key SK yang digunakan untuk
mendekripsikan authenticator. Untuk mengautentikasi pengguna, maka server memeriksa
kondisi-kondisi sebagai berikut:

Ticket belum kadaluwarsa

PrincipalCLIENT yang ada dalam authenticator cocok dengan yang ada di ticket

Authenticator tidak terdapat dalam replay cache dan belum kadaluwarsa

Jika IP_List (diekstrak dari ticket) tidak kosong, maka diperiksa apakah alamat IP
dari AP_REQ berada dalam daftar tersebut

2. X.509

2.1 Authentication Service

Rekomendasi ITU-T X.509 merupakan bagian dari rekomendasi seri X.500 yang
mendefinisikan sebuah layanan direktori. Direktori tersebut, pada dasarnya, sebuah server atau
himpunan server terdistribusi yang me-maintain database yang berisi informasi user. Informasi
tersebut meliputi mapping nama user pada alamat jaringan, serta atribut lainnya dan informasi
mengenai user.
X.509 mendefinisikan framework untuk penyediaan layanan otentikasi pada direktori X.500
bagi user-nya. Direktori tersebut dapat berfungsi sebagai penyimpanan sertifikat kunci publik
(public-key certificates). Setiap sertifikat berisi kunci publik user dan ditandatangani dengan
private key dari otoritas sertifikat terpercaya. Selain itu, X.509 mendefinisikan alternatif protokol
otentikasi yang berdasarkan pada penggunaan sertifikat kunci publik.
X.509 merupakan standar penting karena struktur dan otentikasi protokol yang didefinisikan
dalam X.509 digunakan di dalam berbagai konteks. Sebagai contoh, format sertifikat X.509
digunakan di S/MIME, IP Security, dan SSL/TLS. X.509 awalnya dikeluarkan pada tahun 1988.
Standar

ini

kemudian

revisi

untuk

menangani

beberapa

masalah

keamanan

yang

didokumentasikan dalam [IANS90] dan [MITC90][1]; rekomendasi revisi dikeluarkan pada

tahun 1993.
Versi ketiga dikeluarkan pada tahun 1995 dan direvisi tahun 2000. X.509 didasarkan pada
penggunaan kriptografi kunci publik dan tanda tangan digital (digital signature). Standar tersebut
tidak mengharuskan penggunaan algoritma tertentu tetapi merekomendasikan penggunaan RSA.
Skema tanda tangan digital diasumsikan mengharuskan penggunaan fungsi hash. Sekali lagi,
standar tersebut tidak mengharuskan algoritma hash tertentu. Rekomendasi 1988 menyertakan
uraian tentang anjuran algoritma hash; algoritma ini karena telah terbukti tidak aman dan tidak
dimasukkan dari rekomendasi 1993.

2.2 Certificates
Inti dari skema X.509 adalah sertifikat kunci publik yang terhubung dengan setiap user. Sertifikatsertifikat user ini dibuat oleh beberapa Certification Authority (CA) terpercaya dan ditempatkan di dalam
direktori oleh CA atau oleh user. Direktori server itu sendiri tidak bertanggung jawab untuk menciptakan
kunci publik atau untuk fungsi sertifikasi; namun hanya menyediakan lokasi yang mudah diakses untuk
memperoleh sertifikat.

Keterangan :

Version: Versi X.509

Serial Number: Nomor ini plus nama CA secara unik digunakan untuk mengidentifikasi
sertifikat.

Signature Algorithm: Algoritma yang digunakan untuk menandatangani sertifikat.

Issuer: Nama pemberian X.509 untuk CA.

Validity Period: Waktu awal dan akhir periode valid

Subject Name: Entitas (individu atau organisasi) yang disertifikasi.

Public Key: Kunci publik subjek dan ID dari algoritma yang menggunakannya.

Issuer ID: ID opsional yang secara unik mengidentifikasi certificates issuer.

Subject ID: ID opsional yang secara unik mengidentifikasi certificates subject.

Extensions: Banyak ekstensi yang telah didefinisikan.

Signature: Tanda-tangan sertifikat (ditandatangani dengan kunci privat CA).

2.2 Memperoleh Sertifikat User

Sertifikat user di-generate oleh CA yang memiliki karakteristik sebagai berikut:

Setiap user dengan akses kunci publik dari CA dapat memverifikasi kunci publik
user yang telah disertifikasi.

Tidak ada pihak lain selain Certification Authority (CA) yang dapat memodifikasi
sertifikat tanpa terdeteksi.

Karena sertifikat bersifat tidak dapat dipalsukan (Unforgeable), mereka dapat ditempatkan di
dalam sebuah direktori tanpa perlu melakukan cara khusus untuk melindungi mereka.

3. Single Sign-On
3.1 Teknologi Single Sign-On (sering disingkat menjadi SSO)
Adalah sistem yang mengizinkan pengguna agar dapat mengakses seluruh sumber daya
dalam jaringan hanya dengan menggunakan satu credential saja. Sistem ini tidak memerlukan
interaksi yang manual, sehingga memungkinkan pengguna melakukan proses sekali login untuk
mengakses seluruh layanan aplikasi tanpa berulang kali mengetikan password-nya. Teknologi ini
sangat diminati dalam jaringan yang sangat besar dan bersifat heterogen, dimana sistem operasi
serta aplikasi yang digunakan berasal dari banyak vendor, dan pengguna diminta untuk mengisi
informasi dirinya ke dalam setiap multi-platform yang hendak diakses.
Sistem Single Sign-On menghindari login ganda dengan cara mengidentifikasi subjek secara
ketat dan memperkenankan informasi otentikasi untuk digunakan dalam sistem atau kelompok
sistem yang terpercaya. Sistem SSO dapat meningkatkan kegunaan jaringan secara keseluruhan
dan pada saat yang sama dapat memusatkan pengelolaan dari parameter sistem yang relevan.
Pengguna layanan dapat lebih menyukai sistem Single Sign-On dari pada sistem sign-on
biasa, namun pengelola layanan jaringan memiliki banyak tugas tambahan yang harus dilakukan,
seperti perlunya perhatian ekstra untuk menjamin bukti-bukti otentikasi agar tidak tersebar dan
tidak disadap pihak lain ketika melintasi jaringan.

Gambaran Sistem Sign-On

Sistem Single Sign On

Beberapa arsitektur dari sistem SSO telah muncul, masing-masing dengan berbagai
keunggulan dan infrastruktur yang berbeda. Pada umumnya sistem SSO memiliki beberapa
keuntungan, ntara lain :

Pengguna tidak perlu mengingat banyak username dan password. Cukup dengan satu
credential, sehingga pengguna cukup melakukan proses otentikasi sekali saja untuk
mendapatkan izin akses terhadap semua layanan aplikasi yang tersedia di dalam jaringan.

Kemudahan pemrosesan data.

masing-masing,

maka

Jika setiap layanan aplikasi memiliki data pengguna

pemrosesan

data

pengguna

(penambahan,

pengurangan,

perubahan) harus dilakukan pada setiap aplikasi yang ada. Sedangkan dengan
menggunakan sistem SSO, cukup hanya melakukan sekali pemrosesan pada server
database backend-nya. Hal ini menyatakan bahwa penggunaan sistem SSO meningkatkan
efisiensi waktu dan kepraktisan dalam memproses data.

Tidak perlu membuat data pengguna yang sama di setiap aplikasi Karena setiap layanan
aplikasi dalam jaringan dapat terhubung langsung dengan server database backend ini,
maka hanya dengan sekali saja meng-input data kedalam database, credential pengguna
akan valid di seluruh layanan aplikasi.

Menghemat biaya untuk pemeliharaan password. Ketika harus me-reset password karena
pengguna lupa pada password-nya, pengelola layanan tidak perlu menghabiskan waktu
dan bandwith untuk menemukan data credential pengguna.

Selain mendatangkan manfaat, sistem SSO juga dapat mendatangkan kerugian, antara lain:
1. Pentingnya kesadaran pengguna untuk merahasiakan data credential dan menjaga
keadaan login-nya. Bila masih dalam keadaan login, pengguna yang tidak sah dapat
memakai mesin yang ditinggalkan pengguna sahnya.
2. Kerumitan mengimplementasikan sistem SSO kedalam sebuah jaringan yang heterogen
dan multiplatform, sehingga banyak pengelola layanan jaringan kurang begitu giat dalam
mengimplementasikannya.
3. Kelemahan dalam hal keamanan. Jika password sistem pengelola layanan jaringan
diketahui oleh orang yang tidak berhak, maka orang tersebut dapat melakukan perubahan
terhadap semua data yang ada didalam system
4. Titik Kegagalan Tunggal (Single point failure). Karena setiap layanan aplikasi
bergantung kepada sistem Single Sign-On, sistem ini dapat menjadi suatu titik kegagalan
bila tidak dirancang dengan baik. Kondisi apapun yang dapat menyebabkan sistem SSO
padam, mengakibatkan pengguna tidak dapat mengakses seluruh layanan aplikasi yang
dilindungi oleh sistem SSO tersebut.

3.2 Pendekatan Sistem Single Sign-On

Secara umum SSO diimplementasikan sebagai sebuah model otentikasi yang independen
yang mana seluruh aplikasinya menggunakan modul otentikasi berbasis SSO untuk mengesahkan
pengguna. Ketika pengelola layanan memilih untuk mengaplikasikan sistem SSO, maka dapat
dipilih salah satu dari tiga pendekatan SSO berikut:
1. Pendekatan Terpusat (Centralized Approaches)
Pendekatan ini mempunyai sebuah lokasi yang terpusat dimana seluruh
identifikasi

disimpan.

Server

SSO

bertindak

sebagai

perantara

untuk

mendistribusikan identifikasi ketika dibutuhkan dan sampai pada otentikasi /

otorisasi pengguna jika diperlukan. Biasanya hal ini membutuhkan pergantian

aplikasi untuk mengintegrasikan dengan server SSO. Teknologi pada Microsofts

.NET Passport menggunakan pendekatan ini.
2. Pendekatan Distribusi (Distributed Approaches)
Pendekatan

ini

mengijinkan

kumpulan

pernyataan

identifikasi

yang

dilokalisasikan dari tiap-tiap aplikasi dengan diteruskan menggunakan komponen

client-based (berbasis klien). Oleh karena itu pengguna memiliki kendali penuh
terhadap komponen klien dan profil/password disinkronkan ke pusat server. Satu dari
keuntungan pendekatan ini adalah bahwa jika seorang penyerang (attacker)
mendapatkan akses informasi dari sistem, dia hanya akan menemukan akses ke
informasi dari database yang sedang berjalan dari sistem tersebut.
3.

Pendekatan Federasi (Federation Approches)

Pendekatan ini menyediakan identifikasi terpusat dan layanan manajemen
otentikasi

yang

sejalan

dengan

kumpulan

pernyataan

identifikasi

yang

dilokalisasikan. Hampir seluruh dari produk dan arsitektur SSO yang sekarang
berdasarkan pada model ini. Pendekatan ini menyediakan manfaat yang paling besar
dari kedua pendekatanterpusat dan distribusi.
Model yang dari sistem SSO yang digunakan berdasarkan pada pendekatan federasi, dan
pendekatan ini menggunakan konsep cookie untuk aplikasi berbasis web.

Pendekatan system SSO Berbasis Konsep Cookie

3.2 Arsitektur Sistem Single Sign-On

Solusi sistem SSO didasarkan pada salah satu dari dua tingkat pendekatan, yaitu pendekatan
cript dan pendekatan agent. Pendekatan agent lebih digunakan dalam Tugas Akhir ini karena
dianggap lebih cocok untuk layanan aplikasi berbasis web atau dikenal juga sebagai service
provider (SP).

Pendekatan Sistem SSO

Agent merupakan sebuah program kecil yang berjalan pada tiap-tiap web server. Agent ini
embantu mengkoordinir aliran kerja dari sistem SSO dalam hal otentikasi pengguna dan
penanganan sesi.

Arsitektur Sistem SSO

Arsitektur Sistem SSO memiliki dua bagian utama, yaitu agent yang berada di web server
/Layanan aplikasi dan sebuah server SSO berdedikasi yang mana akan dijelaskan berikut ini:

Agent: Sebuah agent akan menterjemahkan setiap permintaan HTTP yang asuk
ke web server. Hanya ada satu agent di tiap-tiap web server, yang mana host
bagi layanan aplikasi. Agent tersebut akan berinteraksi dengan web browser
pada sisi pengguna, dan dengan server SSO pada sisi layanan aplikasi.

SSO server: Server SSO menggunakan cookies temporer (sementara) untuk

menyediakan fungsi manajemen sesi. Sebuah cookies terdiri dari informasi
seperti user-id, session-id, session creation time, session expiration time dan
lain-lain.

Produk-produk sistem SSO yang berbasis open source yang umum digunakan saat ini seperti
CAS (Central Authentication Service), OpenAM (Open Access Manager), dan JOSSO (Java
Open Single Sign-On).

3.3 OpenAM (Open Access Manager)

OpenAM adalah produk sistem SSO yang berbasis open source, merupakan infrastruktur
yang mendukung layanan berbasis identitas dan implementasi solusi dari Single Sign-on (SSO)
ransparan sebagai komponen keamanan dalam infrastruktur jaringan. OpenAM ini berbasis pada
solusi Identity Management yang dikembangkan oleh Sun Microsystems, Inc. Tujuan dari
OpenAM adalah untuk memberikan landasan yang luas sebagai infrastruktur pelayanan identitas
dalam ranah publik dan untuk memfasilitasi sistem Single Sign-On untuk layanan aplikasi
web dalam server. Keunggulan OpenAM dibandingkan produk SSO lainnya terletak pada
Agent yang dapat ditempatkan ke berbagai aplikasi server seperti Apache, Sun Java System
Web Server, Microsoft IIS, dan Domino. Konfigurasinya dapat dilakukan dengan menulis
otentikasi modul yang dilengkapi dengan keamanan layanan web menggunakan SAML (Security
Assertion Markup Language). OpenAM merupakan pilihan yang tepat jika dibutuhkan dukungan
terhadap lingkungan yang terpisah dan memerlukan otentikasi menggunakan SSL (Secure Socket
Layer).
OpenAM bekerja seperti gerbang utama pada sistem Single Sign-On, karena terhubung
langsung dengan pengguna dan seluruh aplikasi yang ada dalam jaringan. OpenAM bekerja sama
dengan aplikasi backend melakukan proses otentikasi dan otorisasi berdasarkan database
credential pengguna. Beberapa tipe aplikasi yang sering dijadikan Backend database pada
jaringan dengan OpenAM antara lain seperti Kerberos, Active Directory, LDAP, OpenDS, NIS,
dan MySql.

Panduan Pertanyaan :
1. Apakah Kerberos dan X.509 masih digunakan saat ini ?
Jawaban :
Semua masih digunakan baik Kerberos maupun X.509,bahkan sudah dikeluarkannya
aplikasi seri terbaru, seperti : Kerberos V5 Release 1.6.1 dan Kerberos V5 Release 1.5.3 maintenance release
2. Kelemahan dari masing masing metode tersebut ?
Jawaban :
1. Kelemahan Kerberos
Kelemahan di sini diartikan sebagai lubang-lubang keamanan pada protokol ini. Beberapa
diantaranya, yaitu:

Clock synchronization service yang aman

Kerberos menggunakan time-stamp untuk mengetahui apakah authenticator yang
dikirimkan masih baru (bukan replay attack). Untuk itu dibutuhkan sinkronisasi
waktu di seluruh jaringan. Program sinkronisasi waktu yang digunakan umumnya
adalah ntpd. Namun, seperti halnya service lain di jaringan, service ini juga
memerlukan otentikasi. Jika tidak, maka dapat terjadi lubang keamanan dalam
bentuk replay attack.

Trojan horse attack

Terjadi jika workstation sudah tidak aman lagi. Jika penyerang memodifikasi
program dimana user memasukkan username dan passwordnya, maka penyerang
dapat memperoleh informasi yang cukup untuk melakukan impersonation attack
pada sistem ini. Oleh karena itu, Kerberos menuntut jalur yang aman antara user dan
workstation.

Kerberizing application program / client / server

Program-program aplikasi yang menggunakan otentikasi Kerberos harus diubah
source code-nya (di-kerberized) sehingga dapat berkomunikasi dengan librarylibrary Kerberos. Hal ini menjadi masalah sehubungan ukuran dan desain dari
program aplikasi, khususnya pada program yang source code-nya tidak
dipubikasikan. Tidak hanya program, semua client/server dalam jaringan tersebut
harus di-kerberized.

Pilihannya hanya satu: di-kerberized atau tidak digunakan sama sekali.

2. Kelemahan X.509
Serangan terhadap X509 salah satunya dapat dilakukan dengan memanfaatkan
kelemahan dalam fungsi hash yang memungkinkan pembuatan pesan yang berbeda tapi
memiliki nilai Md5 hash yang sama. Fenomena ini sering disebut dengan hash collision.
Fenomena ini dapat dimanfaatkan untuk melakukan beberapa skenario serangan yang
realistis dan mungkin untuk dilakukan di dunia nyata (tidak hanya teori).
Serangan ini dapat berhasil dengan dibuatnya sertifikat palsu dari suatu CA dan sertifikat
tersebut akan diterima sebagai sertifikat valid dan dipercaya oleh browser-browser,
karena sertifikat dibuat seolah-olah ditandatangani oleh salah satu root CA yang
dipercaya oleh browser. Maka sertifikat website apapun yang ditandatangani oleh CA
palsu kita akan dipercaya juga. Jika seorang user adalah korban dari serangan MITM
(Man-in-The-Middle) yang menggunakan sertifikat palsu tersebut, korban tidak akan
dapat mengetahui bahwa ia sedang menjadi korban MITM karena status sertifikat
berbohong kepada korban bahwa sertifikatnya baik-baik saja.
Jika serangan berhasil dilakukan, penyerang dapat mengetahui lalulintas dan
bahkan melakukan modifikasi terhadap lalulintas data. Infrastruktur CA dibuat untuk
mencegah serangan seperti ini.
Skenario serangan dapat dilakukan sebagai berikut. Karena algoritma tandatangan
digital tidak dapat menandatangani data dengan jumlah besar secara efisien, banyak dari
implementasi menggunakan fungsi hash untuk mengurangi besarnya data yang harus
ditandatangani, agar ukurannya menjadi konstan. Skema tandatangan digital sering rentan
terhadap

hash

collision

kecuali

digunakan

teknik

randomized

hashing.

3. Kelemahan SSO ( Single Sight On )

1. Pentingnya kesadaran pengguna untuk merahasiakan data credential dan menjaga
keadaan login-nya. Bila masih dalam keadaan login, pengguna yang tidak sah dapat
memakai mesin yang ditinggalkan pengguna sahnya.

2. Kerumitan mengimplementasikan sistem SSO kedalam sebuah jaringan yang heterogen

dan multiplatform, sehingga banyak pengelola layanan jaringan kurang begitu giat dalam
mengimplementasikannya.
3. Kelemahan dalam hal keamanan. Jika password sistem pengelola layanan jaringan
diketahui oleh orang yang tidak berhak, maka orang tersebut dapat melakukan perubahan
terhadap semua data yang ada didalam sistem.
4. Titik Kegagalan Tunggal (Single point failure). Karena setiap layanan aplikasi
bergantung kepada sistem Single Sign-On, sistem ini dapat menjadi suatu titik kegagalan
bila tidak dirancang dengan baik. Kondisi apapun yang dapat menyebabkan sistem SSO
tidak berfungsi, mengakibatkan pengguna tidak dapat mengakses seluruh layanan aplikasi
yang dilindungi oleh sistem SSO tersebut.
3. Manakah ketiganya yang baik diterapkan ?
Jawaban :
Menurut saya yang paling baik diterapkan karena :
Single Sign On (SSO) adalah sebuah sistem yang memfasilitasi penanganan user account
untuk beberapa server dengan hanya menggunakan satu username dan password saja.
user tidak perlu mengingat banyak username dan password. Sistem ini mempunyai
banyak keuntungan antara lain :
1. User tidak perlu mengingat banyak username dan password.
2. Kemudahan pemrosesan data. Jika setiap server memiliki data user masing-masing, maka
pemrosesan data user (penambahan, pengurangan, perubahan) harus dilakukan pada
setiap server yang ada. Sedangkan dengan menggunakan SSO, cukup hanya melakukan 1
kali pemrosesan.