Gateway cloud-native dapat menggunakan layanan otentikasi kustom untuk memusatkan kontrol akses, sehingga menghilangkan kebutuhan menerapkan otentikasi dan otorisasi di setiap layanan backend. Topik ini menjelaskan cara mengonfigurasi otentikasi dan otorisasi kustom untuk gateway cloud-native.
Latar Belakang
Server biasanya melindungi API dengan memvalidasi kredensial berupa token yang dikirim dalam permintaan klien. Format token tidak didefinisikan secara ketat dan umumnya bergantung pada persyaratan bisnis tertentu.
-
Jika token tersebut merupakan JSON Web Token (JWT), tanda tangannya dapat diverifikasi menggunakan kunci publik tanpa perlu menghubungi layanan otentikasi terpusat.
-
Jika token menggunakan format kustom, server harus memanggil layanan otentikasi terpusat untuk memvalidasinya.
Contoh berikut menunjukkan alur permintaan saat gateway cloud-native terhubung ke layanan otentikasi kustom.

-
Klien mengirim permintaan otentikasi, seperti upaya login, ke gateway.
-
Gateway meneruskan permintaan otentikasi tersebut langsung ke layanan otentikasi.
-
Layanan otentikasi memvalidasi kredensial, seperti username dan password, dari permintaan tersebut. Jika kredensial valid, layanan mengembalikan token ke gateway, yang kemudian meneruskannya ke klien.
-
Klien mengirim permintaan bisnis ke gateway, seperti membuat pesanan di /order. Permintaan tersebut menyertakan token dari langkah sebelumnya.
-
Gateway mengekstraksi path (termasuk parameter kueri), metode HTTP, dan token dari permintaan bisnis asli untuk membuat permintaan otorisasi baru, yang kemudian dikirim ke layanan otentikasi kustom. Anda harus mengonfigurasi Header HTTP yang berisi token di Konsol MSE. Anda juga dapat mengaktifkan opsi untuk menyertakan badan permintaan asli dalam permintaan otorisasi.
Sebagai contoh, jika API otentikasi layanan otentikasi kustom Anda adalah /validateToken, gateway menggabungkan path API otentikasi dan path permintaan bisnis asli untuk membentuk path otorisasi baru: /validateToken/order.
-
Saat layanan otentikasi menerima permintaan otorisasi, layanan tersebut memvalidasi token dan juga dapat melakukan otorisasi berdasarkan path permintaan aslinya.
-
Layanan otentikasi Anda dapat menggunakan kode status HTTP yang berbeda untuk menunjukkan hasil otentikasi dan otorisasi.
-
Kode status HTTP 200 menunjukkan token valid dan diizinkan. Gateway kemudian meneruskan permintaan bisnis asli ke layanan backend yang dilindungi. Setelah menerima respons bisnis, gateway meneruskannya ke klien.
-
Jika layanan otentikasi mengembalikan kode status HTTP 401 atau 403, hal ini menunjukkan token tidak valid atau tidak diizinkan. Gateway segera mengembalikan respons dari layanan otentikasi ke klien, dan permintaan asli gagal.
-
-
Jika layanan otentikasi Anda selalu mengembalikan kode status HTTP 200, gunakan Header HTTP bawaan
x-mse-external-authz-check-result.-
Jika nilai header
x-mse-external-authz-check-resultdalam respons dari layanan otentikasi adalahtrue, hal ini menunjukkan token valid dan diizinkan. Gateway kemudian meneruskan permintaan bisnis asli ke layanan backend yang dilindungi dan meneruskan respons layanan backend tersebut ke klien. -
Jika nilai header
x-mse-external-authz-check-resultadalahfalse, hal ini menunjukkan token tidak valid atau tidak diizinkan. Gateway segera mengembalikan respons dari layanan otentikasi ke klien, dan permintaan asli gagal.
-
-
Buat aturan otentikasi kustom
-
Masuk ke Konsol MSE.
-
Di panel navigasi kiri, pilih Cloud-native Gateway > Gateways. Di bilah navigasi atas, pilih wilayah.
-
Pada halaman Gateways, klik nama gateway yang dituju.
-
Di panel navigasi kiri, pilih Security Management > Global Authentication.
-
Pada halaman global authentication, klik create authentication. Di panel Create authentication, konfigurasikan parameter otentikasi gateway lalu klik OK.
Parameter
Deskripsi
Authentication name
Masukkan nama kustom untuk aturan otentikasi.
Authentication type
Pilih user-created authentication.
Authentication service
Pilih layanan backend untuk otentikasi. Anda dapat menambahkan layanan di bagian manajemen layanan. Untuk informasi lebih lanjut, lihat Add a service.
Catatan-
Hanya layanan yang menggunakan protokol HTTP yang didukung. Protokol lain seperti Dubbo tidak didukung.
-
Secara default, gateway menggunakan port pertama dari layanan Kubernetes. Untuk menggunakan port berbeda, buat layanan Kubernetes lain di Container Service for Kubernetes (ACK) yang hanya mengekspos port yang diinginkan.
Authentication API
Tentukan path API layanan otentikasi. Path API harus mendukung pencocokan awalan (prefix matching).
Sebagai contoh, jika layanan otentikasi Anda dibangun di atas Spring MVC dan API otentikasinya adalah /check, konfigurasikan agar menangani permintaan untuk /check/ dan subpath-nya:
@RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}Token location
Tentukan header permintaan yang berisi token. Header umum termasuk
AuthorizationdanCookie. Anda dapat memilih header dari drop-down list atau menggunakan manual input untuk menentukan nama header.Allowed headers in authentication request
Tentukan nama header permintaan client yang harus diteruskan ke layanan otentikasi.
CatatanHeader Host, Method, Path, dan Content-Length sudah disertakan secara default dan tidak perlu ditambahkan secara manual.
Allowed headers from authentication response
Tentukan nama header respons otentikasi yang harus ditambahkan ke permintaan asli sebelum dikirim ke layanan backend.
CatatanJika permintaan client sudah berisi header dengan nama yang sama, nilainya akan ditimpa.
Allow body in authentication request
Pilih opsi ini untuk menyertakan badan permintaan asli dalam permintaan otentikasi.
Maximum body bytes menentukan ukuran maksimum badan permintaan, dalam byte, yang dapat dikirim dalam permintaan otentikasi.
Timeout
Waktu maksimum, dalam detik, untuk menunggu respons dari layanan otentikasi. Default: 10.
Mode
Menentukan mode penanganan kegagalan. Mode
loose modedanstrict modedidukung. Kami merekomendasikan penggunaanloose mode.-
loose mode: Gateway mengizinkan permintaan client jika layanan otentikasi tidak tersedia (gagal terhubung atau mengembalikan error 5xx).
-
strict mode: Gateway menolak permintaan client jika layanan otentikasi tidak tersedia.
Simple rule
Di sebelah kanan Grant, klik simple rule. Mode ini mendukung whitelist mode dan blacklist mode.
-
whitelist mode: Permintaan yang sesuai dengan host dan path yang ditentukan melewati otentikasi. Semua permintaan lainnya memerlukannya.
-
blacklist mode: Hanya permintaan yang sesuai dengan host dan path yang ditentukan yang memerlukan otentikasi. Semua permintaan lainnya melewatinya.
Klik + Rule condition untuk mengatur nama domain permintaan, path, dan header permintaan.
-
Domain name: Nama domain (host) yang diminta.
-
Path: Path API yang diminta.
-
Path match condition: Path mendukung pencocokan eksak, pencocokan awalan, dan pencocokan ekspresi reguler.
-
Exact match: Masukkan path lengkap, misalnya, /app/v1/order.
-
Prefix match: Masukkan awalan path yang diakhiri dengan tanda bintang (*). Misalnya, untuk mencocokkan semua permintaan yang dimulai dengan /app, atur nilainya menjadi /app/*.
-
Regular expression match: Ekspresi reguler harus mengikuti sintaks RE2. Untuk informasi lebih lanjut, lihat RE2 syntax.
Case sensitive: Jika opsi ini dipilih, pencocokan path bersifat case-sensitive.
-
-
Request header: Informasi header permintaan. Header digabungkan dengan logika AND. Klik + Request Header untuk mengonfigurasi beberapa header.
-
Header key: Nama bidang header.
-
Condition: Kondisi pencocokan yang didukung untuk header.
-
Equal To: Nilai header key yang ditentukan dalam permintaan sama dengan nilai input.
-
Not Equal To: Nilai header key yang ditentukan tidak sama dengan nilai input.
-
Exists: Permintaan berisi header key yang ditentukan.
-
Does Not Exist: Permintaan tidak berisi header key yang ditentukan.
-
Contains: Nilai header key yang ditentukan berisi nilai input.
-
Does Not Contain: Nilai header key yang ditentukan tidak berisi nilai input.
-
Prefix: Nilai header key yang ditentukan diawali dengan nilai input.
-
Suffix: Nilai header key yang ditentukan diakhiri dengan nilai input.
-
Regex: Nilai header key yang ditentukan cocok dengan ekspresi reguler input. Ekspresi reguler harus mengikuti sintaks RE2. Untuk informasi lebih lanjut, lihat RE2 syntax.
-
-
Value: Nilai bidang header.
-
Complex rule
Di sebelah kanan Grant, klik complex rule.
Mode ini memungkinkan Anda mengonfigurasi aturan otorisasi dengan logika gabungan AND/OR/NOT, menggunakan
permission data structureEnvoy dalam format YAML. Otentikasi hanya diperlukan untuk permintaan yang sesuai dengan kondisi ini; semua permintaan lainnya melewati otentikasi.Catatan-
Untuk deskripsi lengkap tentang bidang dalam struktur data permission, lihat dokumentasi resmi Envoy.
-
Untuk contoh konfigurasi, lihat Complex rule examples.
Anda akan dikembalikan ke halaman global authentication. Jika aturan otentikasi gateway baru muncul dalam daftar, berarti aturan tersebut telah berhasil dibuat.
-
Lihat dan kelola aturan otentikasi
-
Masuk ke Konsol MSE.
-
Di panel navigasi kiri, pilih Cloud-native Gateway > Gateways. Di bilah navigasi atas, pilih wilayah.
-
Pada halaman Gateways, klik nama gateway yang dituju.
-
Di panel navigasi kiri, pilih Security Management > Global Authentication.
-
Pada halaman global authentication, temukan aturan otentikasi yang dituju dan klik Details di kolom Actions. Anda dapat melihat Basic Information dan Authentication Configuration layanan saat ini, serta melihat dan mengelola Authorization Information-nya.
Bagian Authentication configuration menampilkan bidang seperti authentication service, authentication API, token location, timeout, mode, allow body in authentication request, allowed headers in authentication request, dan allowed headers from authentication response. Bagian Authorization information berada dalam mode daftar putih. Kondisi aturan digabungkan dengan logika OR, sedangkan item yang cocok dalam satu aturan digabungkan dengan logika AND. Tabel aturan otorisasi mencakup kolom Request domain name, Request path match items, Case sensitive, Request header match items, dan Actions.
Di bagian Authorization Information, klik Create authorization info. Di kotak dialog yang muncul, masukkan Request domain name dan Request path, pilih Match mode, lalu klik OK untuk menambahkan aturan otorisasi.
Operasi terkait
Anda juga dapat melakukan operasi berikut untuk mengelola aturan otentikasi dan otorisasi:
-
Aktifkan aturan: Pada halaman Global Authentication, temukan aturan yang dituju dan klik Enable di kolom Actions untuk mengaktifkannya.
-
Nonaktifkan aturan: Pada halaman Global Authentication, temukan aturan yang dituju dan klik Close di kolom Actions untuk menonaktifkannya.
-
Edit aturan: Pada halaman Global Authentication, temukan aturan yang dituju dan klik Edit di kolom Actions untuk mengubah konfigurasinya.
-
Hapus aturan: Pada halaman Global Authentication, temukan aturan yang dituju dan klik Delete di kolom Actions untuk menghapusnya.
Anda harus menonaktifkan aturan sebelum dapat menghapusnya.
Contoh aturan kompleks
Cocokkan nama domain dengan ekspresi reguler
Pada contoh ini, logika otentikasi hanya dijalankan untuk permintaan ke domain exampleA.com dan exampleB.com yang memiliki awalan path yang sesuai. Perhatikan bahwa ekspresi reguler yang dikonfigurasi di bidang regex memerlukan pencocokan penuh (full match), bukan pencocokan sebagian.
Sebagai contoh, permintaan ke test.exampleA.com tidak memenuhi kondisi dan melewati otentikasi.
-
Ekspresi reguler harus mengikuti sintaks RE2. Untuk informasi lebih lanjut, lihat RE2 syntax.
-
Untuk deskripsi lengkap tentang bidang dalam struktur data permission, lihat dokumentasi resmi Envoy.
permissions:
# and_rules menentukan bahwa otentikasi dilakukan ketika semua aturan berikut terpenuhi.
- and_rules:
rules:
- url_path:
# Pencocokan awalan untuk path.
path:
prefix: /
- header:
# Pencocokan ekspresi reguler.
safe_regex_match:
regex: "(exampleA\\.com|exampleB\\.com)"
# Header pseudo-HTTP didukung. Anda dapat menggunakan header ":authority" untuk mendapatkan nama domain.
name: ":authority"
Gabungkan kondisi AND, OR, dan NOT
Contoh ini memenuhi kondisi berikut:
-
Permintaan yang diawali dengan awalan
exampleA.com/apimemerlukan otentikasi, kecuali untuk:-
exampleA.com/api/appa/bbb, yang tidak memerlukan otentikasi. -
exampleA.com/api/appb/ccc, yang tidak memerlukan otentikasi.
-
-
Semua permintaan di bawah
exampleB.commemerlukan otentikasi, kecuali untuk:-
exampleB.com/api/appa/bbb, yang tidak memerlukan otentikasi. -
exampleB.com/api/appb/ccc, yang tidak memerlukan otentikasi. -
Permintaan yang diawali dengan awalan
exampleB.com/api/appctidak memerlukan otentikasi, kecuali untuk:-
exampleB.com/api/appc/bbb/ccc, yang memerlukan otentikasi. -
exampleB.com/api/appc/ccc/ddd, yang memerlukan otentikasi.
-
-
Gambar berikut merangkum logika ini.

Konfigurasi YAML yang sesuai adalah sebagai berikut:
permissions:
# or_rules menentukan bahwa otentikasi dilakukan jika salah satu aturan berikut terpenuhi.
- or_rules:
rules:
# and_rules menentukan bahwa aturan ini terpenuhi hanya jika semua sub-aturan berikut terpenuhi.
# Aturan 1
- and_rules:
rules:
- url_path:
path:
exact: /api/appc/bbb/ccc
- header:
exact_match: "exampleB.com"
name: ":authority"
# Aturan 2
- and_rules:
rules:
- url_path:
path:
exact: /api/appc/ccc/ddd
- header:
exact_match: "exampleB.com"
name: ":authority"
- and_rules:
rules:
# Aturan 3
- url_path:
path:
prefix: /api/
# not_rule menentukan bahwa aturan ini terpenuhi hanya jika konfigurasi berikut tidak terpenuhi.
# Aturan 4
- not_rule:
url_path:
path:
exact: /api/appa/bbb
# Aturan 5
- not_rule:
url_path:
path:
exact: /api/appb/ccc
- header:
exact_match: "exampleA.com"
name: ":authority"
- and_rules:
rules:
# Aturan 6
- url_path:
path:
prefix: /
# not_rule menentukan bahwa aturan ini terpenuhi hanya jika konfigurasi berikut tidak terpenuhi.
# Aturan 7
- not_rule:
url_path:
path:
exact: /api/appa/bbb
# Aturan 8
- not_rule:
url_path:
path:
exact: /api/appb/ccc
# Aturan 9
- not_rule:
url_path:
path:
prefix: /api/appc/
- header:
exact_match: "exampleB.com"
name: ":authority"