1 LMPIRN2 16 Lampiran 1 uthorization grant pada Outh 2.0 Dalam Outh 2.0 terdapat empat grant type yang dapat digunakan. Grant type tersebut adalah seb...
Lampiran 1 Authorization grant pada OAuth 2.0 Dalam OAuth 2.0 terdapat empat grant type yang dapat digunakan. Grant type tersebut adalah sebagai berikut: 1 Authorization Code Authorization Code diperoleh dengan menggunakan authorization server sebagai perantara antara client dan resource owner. Client tidak secara langsung meminta otorisasi dari resource owner tetapi mengarahkan resource owner ke authorization server melalui user agent. Authorization server mengarahkan resource owner kembali ke client dengan membawa sebuah authorization code yang berfungsi sebagai intermediate credential. Resource owner hanya melakukan autentikasi dengan authorization server sehingga credential tidak pernah dibagikan kepada client. Authorization code memberikan keuntungan sekuriti seperti kemampuan untuk mengautentikasi client dan transmisi access token dilakukan secara langsung ke client tanpa perantara user agent. Resource Owner
B
A Authorization Server
B C User Agent
A
C
D Client E
Aliran data pada penggunaan authorization code adalah sebagai berikut: A
Client me-redirect resource owners’s user-agent ke authorization server. Client mengikutsertakan client identifier, scope, state, dan redirection URI.
B
Authorization server meminta autentikasi kepada resource owner melalui user-agent dan menentukan apakah resource owner menerima atau menolak perminataan akses dari client.
C
Apabila resource owner memberikan akses, authorization server me-redirect user-agent kembali ke client dengan menggunakan redirection URI. Authorization code dan state dari client diikutsertakan pada redirection URI.
D
Client meminta access token dari authorization server berdasarkan authorization code yang telah diperoleh.
E
Authorization server melakukan validasi terhadap client dan authorization code. Authorization server memberikan respons kepada client berupa token.
17
Lampiran 1 Lanjutan 2 Implicit Grant Implicit grant optimal digunakan untuk client yang diimplementasikan pada browser dengan scripting languange seperti javascript. Client tidak menerima authorization code, melainkan langsung menerima access token melalui user tanpa intermediate credentials. Kekurangan implicit grant antara lain client tidak terautentikasi, tetapi identitas client dapat diverifikasi berdasarkan redirection URI ketika mengirimkan access token kepada client. Access token pada implicit grant dapat dilihat oleh resource owner atau aplikasi lain yang memiliki akses terhadap user agent. Sebaliknya, implicit grant memberikan efisiensi karena mengurangi beberapa langkah untuk memperoleh access token.
Resource Owner
B
A B
Authorization Server
C User Agent
A
C
Client
Aliran data pada penggunaan implicit grant adalah sebagai berikut: A
Authorization server meminta autentikasi kepada resource owner dan menentukan apakah resource owner mengizinkan atau melarang permintaan akses resource dari client.
C
Apabila resource owner mengizinkan akses dari client, authorization server me-redirect user agent ke client. Token diikutsertakan pada redirection URI.
18
Lampiran 1 Lanjutan 3 Resource Owner Password Credentials Jenis grant ini menggunakan credential (username dan password) milik resource owner untuk memperoleh access token. Credential sebaiknya hanya digunakan ketika resource owner dan client memiliki tingkat kepercayaan yang tinggi dan jenis authorization grant yang lain tidak tersedia. Aliran data pada penggunaan resource owner password credentials adalah sebagai berikut: A
Resource owner memberikan username dan password kepada client.
B
Client meminta access token kepada authorization server berdasarkan username dan password yang telah diperoleh dari resource owner.
C
Authorization server mengautentikasi client dan melakukan validasi terhadap username dan password. Apabila username dan password valid, authorization server memberikan token kepada client.
Resource Owner
A B Authorization Server C Client
4 Client Credentials Client credential dapat digunakan sebagai authorization grant ketika protected resource di bawah kontrol client. Client credential digunakan sebagai authorization grant ketika client berperan sekaligus sebagai resource owner atau meminta akses terhadap protected resource dalam sebuah otorisasi yang sebelumnya telah disepakati dengan authorization server. A Authorization Server
Client B
Aliran data pada penggunaan client credential adalah sebagai berikut: A
Client melakukan autentikasi dan meminta access token kepada authorization server.
B
Authorization server mengautentikasi client. Apabila autentikasi valid, authorization server memberikan token kepada client.
19
Lampiran 2 Topologi jaringan IPB serta interkoneksinya dengan jaringan eksternal
20
Lampiran 3 Arsitektur aliran data sistem autentikasi di IPB
proxy1
internet 172.17.0.11 (Load balancer) proxy2
Proxy3 172.17.0.18 (Load Balancer) Server-server web proxy4
LDAP
21
Lampiran 4 Arsitektur aliran data sistem SSO IPB
Proxy1 (Squid) internet 172.17.0.11 (Load balancer) proxy2 (Squid)
Proxy3 (Squid) 172.17.0.18 (Load Balancer) Server-server web proxy4 (Squid)
Server SSO
LDAP (Fedora DS)
22
Lampiran 5 Rancangan proses login SSO IPB Start
User memasukkan username dan password
Username dan password kosong?
yes
Username dan password tidak boleh kosong
no
Username di LDAP > 1?
yes
Username kembar, akun bermasalah
no
Username dan password cocok?
no
Kesalahan password
yes
Hapus session di MySQL dan Codeigniter
yes
Username ada di MySQL?
no
Buat session di codeigniter
Simpan data dari LDAP ke MySQL
Finish
Login gagal
23
Lampiran 6 Rancangan proses autentikasi web SSO IPB Start
Load halaman web client dan script dari server SSO pada browser
APLIKASI (CLIENT)
Client meminta token ke SSO IPB melalui script
No
Token berhasil diperoleh?
Tampilkan halaman web normal dengan tombol link ke SSO IPB
No
User menekan link ke SSO IPB Yes
User menyetujui autentikasi untuk client?
SERVER SSO IPB (AUTH SERVER)
Yes
Server SSO memberikan token melalui URI string
Lakukan autentikasi lokal sesuai permintaan client
Finish
24
Lampiran 7 Directory Information Tree IPB
25
Lampiran 8 Struktur tabel application Field
Tipe
Keterangan
apps_id
Varchar (32)
ID aplikasi
apps_domain
Varchar (50)
Domain aplikasi
apps_secret
Varchar (32)
Kode aplikasi (sejenis password)
user_id
Varchar (50)
User ID yang mendaftarkan aplikasi
apps_name
Varchar (50)
Nama aplikasi
redirect_uri
Varchar (100)
Redirect URI
base_dn
Text
Base DN pada LDAP
apps_icon
Varchar (50)
URL icon aplikasi
26
Lampiran 9 Struktur tabel application_user Field
Tipe
Keterangan
id
Int (11)
ID
apps_id
Varchar (50)
ID aplikasi
user_id
Varchar (50)
ID user
status
Tinyint (1 )
Status koneksi aplikasi dengan user
27
Lampiran 10 Struktur tabel token Field
Tipe
Keterangan
access_token
Varchar (32)
user_id
Varchar (50)
ID user
apps_id
Varchar (32)
ID aplikasi
token_type
Varchar (20)
Jenis token (MAC)
mac_algorithm
Varchar (50)
Algoritme MAC (sha1, sha256, dsb.)
issue_time
Varchar (10)
Waktu pembuatan token
Penguji : 1. Ir. Sri Wahjuni, M.T. 2. Hendra Rahmawan, S. Kom, M.T.
