Quarkus Security: konsep dasar security pada quarkus

Fitur Security Aplikasi Quarkus

Quarkus dirancang untuk membuat pengembangan aplikasi Java menjadi lebih efisien dan menyenangkan. Hal ini juga berlaku untuk aspek keamanannya dengan menawarkan solusi yang out-of-the-box (siap pakai) namun tetap fleksibel untuk kustomisasi mendalam.

Filosofi dan Arsitektur Keamanan

Keamanan di Quarkus didasarkan pada konsep kontekstual dan identity-driven. Setiap keputusan keamanan—baik otentikasi maupun otorisasi—didasarkan pada objek SecurityIdentity, sebuah representasi dari pengguna yang sedang berinteraksi dengan aplikasi Anda. Objek ini berisi semua informasi yang diperlukan, seperti nama pengguna (principal), peran (roles), dan atribut lainnya.

Secara umum, alur keamanan di Quarkus bekerja seperti ini:

1. Permintaan HTTP Masuk: Setiap permintaan yang masuk akan diintersep oleh mekanisme otentikasi.

2. Otentikasi: Mekanisme otentikasi (misalnya, JWT, OIDC, atau Basic Auth) akan memvalidasi kredensial pengguna.

3. Pembuatan SecurityIdentity: Jika kredensial valid, Quarkus akan menciptakan objek SecurityIdentity yang berisi data pengguna.

4. Otorisasi: Objek SecurityIdentity ini kemudian digunakan untuk menentukan apakah pengguna memiliki izin untuk mengakses resource tertentu, biasanya melalui anotasi seperti @RolesAllowed atau @PermitAll.

Arsitektur ini memastikan bahwa keputusan keamanan dibuat berdasarkan identitas pengguna yang valid, bukan sekadar data mentah dari permintaan.

Komponen Utama

Quarkus menggunakan beberapa komponen inti untuk menjalankan arsitektur keamanannya:

• HttpAuthenticationMechanism: Komponen ini adalah titik masuk untuk otentikasi. Tugasnya adalah mengekstrak kredensial (seperti token JWT atau username/password) dari permintaan HTTP. Anda dapat mengaktifkan beberapa mekanisme sekaligus, dan Quarkus akan mencoba masing-masing hingga ada yang berhasil.

  
  
  

• IdentityProvider: Setelah kredensial berhasil diekstrak, komponen ini memverifikasinya terhadap penyimpanan data pengguna. Ini bisa berupa basis data, berkas properti, atau layanan otentikasi eksternal seperti Keycloak. Jika verifikasi berhasil, IdentityProvider akan mengembalikan SecurityIdentity. 

  
  
  

• SecurityIdentityAugmentor: Ini adalah komponen opsional yang memungkinkan Anda memodifikasi atau memperkaya objek SecurityIdentity setelah otentikasi berhasil. Misalnya, Anda bisa menambahkan peran (roles) tambahan atau atribut khusus yang tidak tersedia di IdentityProvider. 

  
  
  

Kustomisasi Tingkat Lanjut

Meskipun Quarkus menyediakan banyak fitur keamanan out-of-the-box, Anda mungkin perlu melakukan kustomisasi untuk memenuhi kebutuhan spesifik.

1. Implementasi Otentikasi Khusus (HttpAuthenticationMechanism)

Jika Anda memerlukan otentikasi yang tidak didukung secara bawaan, Anda bisa membuat implementasi HttpAuthenticationMechanism sendiri. Anda hanya perlu membuat kelas yang mengimplementasikan antarmuka HttpAuthenticationMechanism dan mendaftarkannya sebagai bean CDI.

2. Kustomisasi SecurityContext

Dalam lingkungan JAX-RS, Anda dapat menginjeksi SecurityContext untuk mendapatkan informasi tentang pengguna yang diautentikasi. Anda bisa mendapatkan nama principal pengguna dan memeriksa peran (roles) secara programatik, memberikan Anda kontrol penuh atas logika otorisasi.

3. Enkripsi dan Algoritma Kriptografi

Untuk memastikan data yang sensitif tetap aman, Quarkus mendukung provider kriptografi seperti Bouncy Castle. Ini sangat berguna saat Anda perlu melakukan operasi kriptografi kompleks, seperti enkripsi data di sisi server atau validasi tanda tangan digital yang lebih canggih. Anda dapat mengintegrasikannya dengan mudah menggunakan ekstensi yang tersedia.

Dengan memahami konsep dan komponen ini, Anda bisa membangun aplikasi Quarkus yang tidak hanya cepat dan efisien, tetapi juga sangat aman dan mudah dikelola. 

Memahami Perbedaan antara Form-Based Login (Browser) dan Otentikasi JWT (API)

 

Form-based login dan JSON Web Token (JWT) adalah dua pendekatan populer untuk otentikasi dalam aplikasi web dan API. Meskipun keduanya bertujuan untuk memverifikasi identitas pengguna, cara kerjanya sangat berbeda dan biasanya digunakan dalam skenario yang berbeda.

Form-Based Login untuk Aplikasi Browser

Metode ini adalah cara otentikasi yang paling tradisional dan umum untuk aplikasi web berbasis server-side rendering.

Cara Kerjanya:

1. Permintaan Halaman Login: Pengguna mengunjungi aplikasi dan diarahkan ke halaman login.

2. Pengisian Formulir: Pengguna memasukkan nama pengguna dan kata sandi di formulir HTML dan mengirimkannya ke server.

3. Verifikasi Sesi: Server menerima data, memverifikasi kredensial, dan jika berhasil, membuat sesi (session) untuk pengguna tersebut. Informasi sesi ini disimpan di server dan terkait dengan ID sesi unik yang dikirim ke browser pengguna, biasanya dalam bentuk cookie.

4. Akses Terproteksi: Pada setiap permintaan berikutnya, browser secara otomatis mengirimkan cookie sesi. Server menggunakan ID sesi di dalam cookie untuk menemukan sesi pengguna yang tersimpan, memverifikasi identitasnya, dan memberikan akses ke halaman atau resource yang dilindungi.

Kelebihan:

• Mudah diimplementasikan untuk aplikasi web tradisional.

• Keamanan dikelola di sisi server, membuat status otentikasi pengguna tetap aman.

Kekurangan:

• Berbasis Sesi: Model ini bergantung pada penyimpanan sesi di server, yang bisa menjadi tantangan dalam arsitektur mikroservis atau saat melakukan penskalaan (scaling).

• Tidak Stateless: API menjadi tidak stateless karena harus menyimpan dan mengelola status sesi pengguna. 

Login Berbasis Sesi (Session-Based Login) pada Aplikasi Web Modern

Login berbasis sesi adalah metode otentikasi paling umum untuk aplikasi web tradisional yang menggunakan HTML page dan formulir. Metode ini sangat cocok untuk situs web di mana server bertanggung jawab untuk rendering halaman dan mengelola status pengguna.

Cara Kerja

Proses login berbasis sesi melibatkan interaksi antara browser dan server melalui mekanisme yang disebut sesi (session).

1. Permintaan Login: Pengguna mengunjungi situs web dan masuk ke halaman login. Mereka memasukkan nama pengguna dan kata sandi di dalam formulir HTML.

2. Verifikasi Kredensial: Saat formulir dikirimkan, data akan sampai di server. Server kemudian memverifikasi kredensial ini terhadap database atau penyimpanan data pengguna lainnya.

3. Pembuatan Sesi: Jika kredensial valid, server tidak hanya merespons dengan halaman berhasil, tetapi juga membuat objek sesi di sisi server. Objek ini menyimpan informasi tentang pengguna yang telah login (misalnya, ID pengguna, peran, atau preferensi).

4. Pengiriman ID Sesi: Untuk menghubungkan browser pengguna dengan sesi yang baru dibuat, server membuat ID sesi unik. ID ini kemudian dikirim kembali ke browser dan disimpan di sana, biasanya dalam bentuk cookie yang disebut session cookie.

5. Akses Terproteksi: Pada setiap permintaan berikutnya ke halaman yang terproteksi, browser secara otomatis menyertakan session cookie ini. Server membaca cookie tersebut, menggunakan ID sesi untuk mencari objek sesi pengguna yang sesuai, dan memverifikasi identitas pengguna. Jika sesi valid, server akan melayani permintaan; jika tidak, server akan mengarahkan pengguna kembali ke halaman login.

Analogi Sederhana Bayangkan Anda mendapatkan tiket masuk (session ID) setelah berhasil verifikasi identitas (login). Setiap kali Anda ingin masuk ke ruangan terbatas (halaman terproteksi), Anda hanya perlu menunjukkan tiket tersebut, tanpa perlu menunjukkan KTP Anda lagi. Selama Anda memiliki tiket itu, Anda bisa masuk ke mana pun.

Kelebihan

• Keamanan Terkelola Server: Informasi sesi pengguna disimpan di sisi server, menjadikannya lebih aman dari serangan seperti XSS (Cross-Site Scripting) yang dapat mencuri data di sisi klien.

• Kontrol Penuh: Pengembang memiliki kontrol penuh atas masa berlaku sesi dan dapat langsung membatalkannya (invalidate) dari server kapan saja (misalnya, saat pengguna logout).

• Sederhana untuk Aplikasi Tradisional: Pendekatan ini adalah standar industri dan mudah diimplementasikan pada aplikasi web yang dibangun dengan teknologi seperti JSP, PHP, atau ASP.NET.

Kekurangan

• Ketergantungan Status Server: Karena server harus menyimpan status sesi setiap pengguna, pendekatan ini menjadi tidak stateless. Hal ini dapat menjadi tantangan dalam arsitektur yang sangat terdistribusi atau saat mencoba melakukan penskalaan horizontal karena sesi harus disinkronkan di antara banyak server.

• Resiko Pencurian Sesi: Jika session cookie dicuri (melalui serangan seperti man-in-the-middle), penyerang dapat menggunakan cookie tersebut untuk menyamar sebagai pengguna yang sah. Namun, ini dapat dimitigasi dengan penggunaan HTTPS.

Penggunaan Session-Based Security di Quarkus

Di Quarkus, implementasi session-based authentication untuk formulir HTML melibatkan penggunaan ekstensi bawaan dan sedikit konfigurasi. Proses ini mengandalkan mekanisme otentikasi berbasis formulir yang terintegrasi penuh.

Konfigurasi Dasar

Untuk mengaktifkan otentikasi berbasis formulir, Anda perlu mengonfigurasi Quarkus di berkas application.properties:

• quarkus.http.auth.form.enabled=true: Mengaktifkan mekanisme otentikasi berbasis formulir.

• quarkus.http.auth.form.login-page=login.html: Menentukan halaman HTML yang akan digunakan sebagai formulir login.

• quarkus.http.auth.form.error-page=error.html: Menentukan halaman yang ditampilkan jika login gagal.

• quarkus.http.auth.form.landing-page=index.html: Menentukan halaman yang akan dituju setelah login berhasil.

• quarkus.http.auth.form.cookie-name=q_session: Mengatur nama cookie yang akan menyimpan ID sesi.

Implementasi Komponen Session Base Form HTML

Untuk melengkapi alur ini, Anda memerlukan tiga hal:

1. Halaman HTML

Anda harus membuat halaman login (login.html), halaman error (error.html), dan halaman utama (index.html) di dalam folder src/main/resources/META-INF/resources.

• login.html: Halaman ini harus berisi formulir HTML dengan action ke URI khusus j_security_check. Quarkus akan secara otomatis memproses formulir yang dikirim ke URI ini. Nama input untuk nama pengguna dan kata sandi haruslah j_username dan j_password.

<form action="j_security_check" method="post">
    <input type="text" name="j_username" placeholder="Username"/>
    <input type="password" name="j_password" placeholder="Password"/>
    <button type="submit">Login</button>
</form> 

 

2. Konfigurasi Pengguna

Quarkus perlu tahu kredensial pengguna mana yang valid. Anda dapat mengonfigurasinya di application.properties untuk kasus sederhana:

quarkus.security.users.file.enabled=true
quarkus.security.users.file.users.alice=supersecret
quarkus.security.users.file.users.bob=secret
quarkus.security.users.file.roles.alice=admin
quarkus.security.users.file.roles.bob=user

3. Keamanan pada Kode

Terakhir, Anda mengamankan endpoint REST atau halaman web menggunakan anotasi keamanan standar. Saat pengguna mencoba mengakses endpoint yang dilindungi tanpa sesi yang valid, Quarkus akan secara otomatis mengarahkan mereka ke halaman login yang telah Anda konfigurasikan.

@Path("/secure")
public class SecureResource {

    @Inject
    SecurityIdentity identity;

    @GET
    @RolesAllowed("admin")
    public String getAdminData() {
        return "Halo, " + identity.getPrincipal().getName() + "! Ini adalah konten rahasia.";
    }
}

Alur Kerja Login

1. Pengguna mengakses /secure.

2. Quarkus mendeteksi bahwa endpoint ini memerlukan autentikasi, dan karena tidak ada sesi yang valid, ia mengarahkan pengguna ke /login.html.

3. Pengguna memasukkan kredensialnya di formulir dan menekan Login.

4. Formulir mengirimkan data ke URI j_security_check.

5. Quarkus memproses data ini, memverifikasi kredensial, dan jika berhasil, membuat sesi baru.

6. Session cookie dikirim ke browser pengguna.

7. Quarkus kemudian mengarahkan pengguna ke landing page (index.html) atau kembali ke resource /secure yang awalnya diminta.

8. Pada setiap permintaan berikutnya, browser menyertakan session cookie, dan Quarkus menggunakannya untuk mengenali pengguna tanpa perlu login ulang.

Otentikasi JWT untuk API (Stateless)

 

JWT adalah metode otentikasi yang populer untuk API RESTful, aplikasi satu halaman (Single-Page Application / SPA), dan arsitektur mikroservis. Ini adalah pendekatan stateless, yang berarti server tidak perlu menyimpan informasi sesi pengguna.

Cara Kerjanya:

1. Login Awal: Pengguna mengirimkan kredensial (nama pengguna dan kata sandi) ke API login.

2. Pembuatan Token: Server memverifikasi kredensial. Jika berhasil, ia tidak membuat sesi, melainkan menciptakan dan menandatangani JWT yang berisi informasi pengguna (misalnya, ID pengguna, peran) di dalam payload-nya.

3. Pengiriman Token: Server mengirimkan token ini kembali ke klien (misalnya, browser atau aplikasi seluler). Klien bertanggung jawab untuk menyimpan token ini (misalnya di localStorage atau cookie).

4. Permintaan ke API: Pada setiap permintaan ke API yang dilindungi, klien menyertakan token ini di header Authorization dengan skema Bearer.

5. Verifikasi Token: Server menerima token, memverifikasi tanda tangannya (untuk memastikan token tidak dimodifikasi), dan mengekstrak informasi pengguna langsung dari payload. Tidak ada panggilan basis data atau pencarian sesi yang diperlukan.

Kelebihan:

• Stateless: Server tidak perlu menyimpan status sesi. Hal ini sangat ideal untuk penskalaan horizontal karena permintaan dapat dilayani oleh server mana pun.

• Ringkas: Token JWT berisi semua informasi yang dibutuhkan, mengurangi jumlah permintaan ke basis data.

• Terstandarisasi: JWT adalah standar terbuka (RFC 7519), sehingga mudah digunakan di berbagai platform dan bahasa pemrograman.

Kekurangan:

• Ukuran: Token dapat menjadi besar jika terlalu banyak data dimasukkan ke dalam payload.

• Keamanan Token: Jika token dicuri, token tersebut dapat digunakan hingga kedaluwarsa. Strategi seperti token yang berumur pendek dan refresh token diperlukan untuk mitigasi.

Kesimpulan

Pilihan antara form-based login dan otentikasi JWT bergantung pada jenis aplikasi Anda.

• Gunakan Form-based Login jika Anda membangun aplikasi web tradisional dengan banyak halaman yang dirender di sisi server.

• Gunakan JWT jika Anda membangun API stateless yang akan dikonsumsi oleh aplikasi modern seperti SPA, aplikasi seluler, atau mikroservis.

Penggunaan Token-Based Security di Quarkus

Quarkus menyediakan dukungan yang kuat dan terintegrasi untuk otentikasi berbasis token, menjadikannya pilihan ideal untuk membangun API RESTful, layanan mikro, dan aplikasi modern. Pendekatan ini memungkinkan arsitektur yang stateless, di mana server tidak perlu menyimpan informasi sesi pengguna. Ini sangat efisien dan mudah diskalakan secara horizontal.

Quarkus menggunakan ekstensi SmallRye JWT untuk memproses token, yang mematuhi standar MicroProfile JWT.

1. Cara Kerja Otentikasi Berbasis Token di Quarkus

Secara umum, alur kerja otentikasi berbasis token di Quarkus mengikuti langkah-langkah ini:

1. Penerbitan Token: Setelah pengguna berhasil login (misalnya, dengan kredensial username/password), layanan otentikasi (seperti Keycloak atau Microprofile JWT) akan menerbitkan JSON Web Token (JWT).

2. Penyimpanan Klien: Klien (aplikasi web atau seluler) menerima token ini dan menyimpannya, biasanya di localStorage atau cookie HttpOnly.

3. Permintaan API: Untuk mengakses endpoint yang dilindungi, klien menyertakan token ini di header Authorization dengan format Bearer <token>.

4. Verifikasi Token: Saat permintaan tiba di Quarkus, ia akan secara otomatis:

   • Mengekstrak token dari header.

   • Memvalidasi tanda tangan token menggunakan kunci publik yang telah dikonfigurasi.

   • Menganalisis klaim (claims) dalam payload untuk mendapatkan informasi pengguna, seperti peran (roles) dan nama.

5. Otorisasi: Berdasarkan informasi dari token yang sudah tervalidasi, Quarkus akan mengambil keputusan otorisasi, misalnya mengizinkan atau menolak akses ke sebuah endpoint berdasarkan peran pengguna.

2. Implementasi di Quarkus

Untuk memulai, Anda perlu menambahkan ekstensi quarkus-smallrye-jwt ke proyek Maven atau Gradle Anda.

Konfigurasi Dasar

Di berkas src/main/resources/application.properties, Anda harus mengonfigurasi cara Quarkus memvalidasi token yang masuk. Cara termudah adalah mengarahkan Quarkus ke URL server otorisasi (misalnya, Keycloak) yang berisi kunci publik.

3. Keunggulan Pendekatan Ini

Pendekatan ini sangat menguntungkan karena:

• Stateless: Tidak perlu menyimpan sesi di server, sehingga ideal untuk arsitektur mikroservis dan cloud-native.

• Keamanan Terstandarisasi: Menggunakan standar industri JWT dan MicroProfile, yang memastikan interoperabilitas dengan berbagai sistem otorisasi.

• Otomasi: Sebagian besar proses validasi token, pembuatan identitas, dan otorisasi dilakukan secara otomatis oleh Quarkus, mengurangi kode boilerplate yang harus ditulis pengembang.

• Performa: Verifikasi tanda tangan JWT sangat cepat dan efisien, karena tidak memerlukan panggilan database tambahan untuk setiap permintaan.

Dengan dukungan bawaan ini, Quarkus memungkinkan Anda untuk membangun aplikasi yang sangat aman, cepat, dan mudah diskalakan menggunakan token-based security.

 

Sumber 

https://quarkus.io/guides/security-overview

https://quarkus.io/guides/security-architecture 

https://quarkus.io/guides/security-customization

https://quarkus.io/guides/security-customization#jaxrs-security-context

https://quarkus.io/guides/security-customization#bouncy-castle