All Products
Search
Document Center

API Gateway:Konfigurasikan authorizer kustom

Last Updated:Jun 04, 2026

Cloud-native API Gateway mendukung layanan otorisasi kustom yang memusatkan kontrol akses di gerbang, bukan mengintegrasikannya secara terpisah dengan setiap backend.

Cara kerja otorisasi kustom

Server mengamankan API dengan memvalidasi token yang disertakan dalam permintaan klien.

  • Jika token berupa JWT, Anda dapat memvalidasi signature-nya di mana saja menggunakan kunci publik tanpa perlu memanggil layanan terpusat.

  • Jika token menggunakan format kustom, server harus memanggil layanan otorisasi terpusat. Cloud-native API Gateway mendukung skenario ini.

Diagram berikut menunjukkan alur permintaan ketika sebuah instans gateway menggunakan layanan otorisasi kustom.

Request flow for Cloud-native API Gateway with custom authorization

  1. Klien mengirim permintaan autentikasi, seperti operasi login, ke gateway.

  2. Gateway meneruskan permintaan autentikasi tersebut langsung ke layanan autentikasi.

  3. Layanan autentikasi memvalidasi kredensial dalam permintaan, seperti username dan password. Jika validasi berhasil, layanan tersebut mengembalikan token ke gateway, yang kemudian mengirim token tersebut ke klien.

  4. Klien mengirim permintaan bisnis, seperti operasi order pada /order, termasuk token yang diperoleh pada langkah sebelumnya.

  5. Gateway mengekstrak path (termasuk parameter kueri), metode HTTP, dan token dari permintaan asli, lalu mengirim permintaan otorisasi ke layanan kustom. Konfigurasikan header token di Konsol gateway. Anda juga dapat menyertakan badan permintaan asli.

    Sebagai contoh, jika API otorisasi adalah /validateToken dan path permintaan asli adalah /order, maka path permintaan otorisasi menjadi /validateToken/order.

  6. Saat layanan otorisasi menerima permintaan otorisasi, layanan tersebut memvalidasi token dan juga dapat melakukan otorisasi berdasarkan path permintaan asli.

    • Jika layanan otorisasi Anda dapat mengubah kode status HTTP dalam responsnya, gunakan kode status tersebut untuk menunjukkan hasil otorisasi.

      • Kode status 200 berarti permintaan diizinkan. Gateway meneruskan permintaan asli ke layanan backend dan mengembalikan respons ke klien.

      • Kode status 401 atau 403 berarti permintaan tidak diizinkan. Gateway langsung mengembalikan respons layanan otorisasi ke klien.

    • Jika layanan otorisasi Anda harus selalu mengembalikan HTTP 200 untuk semua respons karena batasan bisnis, gunakan header HTTP bawaan x-mse-external-authz-check-result.

      • Header respons x-mse-external-authz-check-result bernilai true: token valid atau memiliki izin untuk mengakses resource backend. Gateway meneruskan permintaan ke backend dan mengembalikan respons ke klien.

      • Header respons x-mse-external-authz-check-result bernilai false: token tidak valid atau tidak memiliki izin. Gateway langsung mengembalikan respons layanan otorisasi ke klien.

Buat authorizer kustom

  1. Masuk ke Konsol API Gateway.

  2. Di panel navigasi kiri, klik Cloud-native API Gateway > Instance. Di bilah navigasi atas, pilih wilayah.

  3. Pada halaman Instance, klik nama instans gateway target.

  4. Di panel navigasi kiri, klik Security Management > Global Authentication.

  5. Pada halaman Global Authentication, klik Create Authentication. Pada panel Create Authentication, konfigurasikan parameter dan klik OK.

    Parameter

    DescriptionCustom Authentication Service

    Enable

    Mengaktifkan atau menonaktifkan otorisasi untuk instans gateway ini.

    Authentication Name

    Nama kustom untuk aturan otorisasi.

    Authentication Type

    Pilih Custom Authentication Service.

    Authentication Service

    Layanan backend yang melakukan otorisasi. Anda dapat menambahkan layanan di modul manajemen layanan. Add a service.

    Catatan
    • Hanya layanan HTTP yang didukung.

    • Jika Kubernetes Service memiliki beberapa port, gateway menggunakan port pertama secara default. Untuk menggunakan port yang berbeda, buat Kubernetes Service terpisah di ACK yang hanya mengekspos port target.

    Authentication API

    Path API otorisasi. Memerlukan pencocokan awalan (prefix match).

    Sebagai contoh, jika layanan otorisasi Anda dibangun dengan Spring MVC dan mengekspos API otorisasi di /check, pengaturan berikut menangani permintaan untuk /check/**:

    @RequestMapping("/check/**")
    public ResponseEntity<RestResult<String>> check(){}

    Token Location

    Header permintaan yang berisi token, seperti Authorization dan Cookie. Anda dapat memilih header dari daftar dropdown dengan memilih Select atau menambahkannya secara manual dengan memilih Add Manually.

    Allowed Headers in Authentication Rrequest

    Header dari permintaan client asli yang akan diteruskan ke layanan otorisasi.

    Catatan

    Header Host, Method, Path, dan Content-Length diteruskan secara default. Anda tidak perlu menambahkannya.

    Allowed Headers in Authentication Response

    Header dari respons layanan otorisasi yang akan ditambahkan ke permintaan upstream yang dikirim ke backend.

    Catatan

    Jika header yang ditentukan di sini sudah ada dalam permintaan client, nilainya akan ditimpa.

    Allow Body in Authentication Request

    Jika Anda memilih Allow Body in Authentication Request, permintaan otorisasi akan menyertakan badan permintaan asli.

    Maximum Body Size menentukan ukuran maksimum badan permintaan yang dapat diteruskan ke layanan otorisasi, dalam byte.

    Timeout Period

    Waktu tunggu maksimum untuk respons layanan otorisasi, dalam detik. Default: 10 detik.

    Mode

    Mendukung mode Loose dan Strict. Mode Loose direkomendasikan.

    • Loose Mode: Jika layanan otorisasi tidak tersedia (misalnya, gagal terhubung atau mengembalikan error 5xx), gateway tetap mengizinkan permintaan client dilanjutkan.

    • Strict Mode: Jika layanan otorisasi tidak tersedia, gateway menolak permintaan client.

    Simple Conditions

    Di sebelah kanan Authorization, klik Simple Conditions. Mode otorisasi ini mendukung Whitelist Mode dan Blacklist Mode.

    • Whitelist Mode: Permintaan yang sesuai dengan host dan path dalam allowlist melewati otorisasi. Semua permintaan lain memerlukan otorisasi.

    • Blacklist Mode: Hanya permintaan yang sesuai dengan host dan path dalam denylist yang memerlukan otorisasi. Semua permintaan lain melewati otorisasi.

    Klik Rule Condition untuk mengatur domain permintaan, path, dan header permintaan.

    • Domain Name: 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, seperti /app/v1/order.

      • Prefix Match: Masukkan awalan path yang diakhiri tanda bintang (*). Misalnya, untuk mencocokkan semua permintaan yang dimulai dengan /app, masukkan /app/*.

      • Regular Expression Match: Sintaks ekspresi reguler mengikuti standar RE2 syntax.

      Case sensitive: Jika Anda mencentang kotak ini, pencocokan path menjadi peka huruf besar/kecil.

    • Header: Informasi header permintaan. Klik Request Header untuk menambahkan beberapa kondisi header. Semua kondisi digabungkan dengan logika AND.

      • HeaderKey: Nama bidang header.

      • Condition: Kondisi pencocokan untuk header.

        • Equals To: Nilai kunci header yang ditentukan persis sama dengan nilai input.

        • Does Not Equal To: Nilai kunci header yang ditentukan tidak sama dengan nilai input.

        • Exists: Kunci header yang ditentukan ada dalam permintaan.

        • Does Not Exist: Kunci header yang ditentukan tidak ada dalam permintaan.

        • Contains: Nilai kunci header yang ditentukan mengandung nilai input.

        • Excludes: Nilai kunci header yang ditentukan tidak mengandung nilai input.

        • Prefix: Nilai kunci header yang ditentukan diawali dengan nilai input.

        • Suffix: Nilai kunci header yang ditentukan diakhiri dengan nilai input.

        • Regular Expression Match: Nilai kunci header yang ditentukan cocok dengan ekspresi reguler input. Sintaks mengikuti standar RE2 syntax.

      • Value: Nilai bidang header yang akan dicocokkan.

    Complex Conditions

    Di sebelah kanan Authorization, klik Complex Conditions.

    Mode ini memungkinkan Anda mengonfigurasi aturan otorisasi dengan logika gabungan AND, OR, dan NOT menggunakan konfigurasi YAML dari struktur data izin Envoy. Otorisasi hanya diterapkan ketika kondisi yang dikonfigurasi terpenuhi; permintaan lain melewati otorisasi.

    Catatan

    Kembali ke halaman Global Authentication. Aturan dianggap telah dibuat jika muncul dalam daftar.

Lihat dan kelola authorizer

  1. Masuk ke Konsol API Gateway.

  2. Di panel navigasi kiri, klik Cloud-native API Gateway > Instance. Di bilah navigasi atas, pilih wilayah.

  3. Pada halaman Instance, klik nama instans gateway target.

  4. Di panel navigasi kiri, klik Security Management > Global Authentication.

  5. Pada halaman Authentication, temukan aturan otorisasi target dan klik Description di kolom Actions. Anda dapat melihat Basic Information dan Authentication Configuration, serta mengelola Authorization Information.

    image

    Pada bagian Authorization Information, klik Create Authorization. Pada kotak dialog yang muncul, masukkan Request Domain Name dan Request Path, pilih Match Mode, lalu klik OK untuk menambahkan aturan otorisasi baru.

Operasi terkait

Anda dapat mengelola aturan otorisasi gateway sebagai berikut:

  • Aktifkan otorisasi: Pada halaman Global Authentication, temukan aturan otorisasi target dan klik Enable di kolom Actions untuk mengaktifkan aturan.

  • Nonaktifkan otorisasi: Pada halaman Global Authentication, temukan aturan otorisasi target dan klik Close di kolom Actions untuk menonaktifkan aturan.

  • Edit otorisasi: Pada halaman Global Authentication, temukan aturan otorisasi target dan klik Edit di kolom Actions untuk mengubah aturan.

  • Hapus otorisasi: Pada halaman Global Authentication, temukan aturan otorisasi target dan klik Delete di kolom Actions untuk menghapus aturan.

Catatan

Anda hanya dapat menghapus aturan otorisasi setelah aturan tersebut dinonaktifkan.

Contoh otorisasi kompleks

Pencocokan domain dengan regex

Pada contoh ini, otorisasi hanya diterapkan pada permintaan ke exampleA.com dan exampleB.com yang sesuai dengan awalan path. Ekspresi reguler dalam field regex harus merupakan pencocokan eksak, bukan pencocokan parsial.

Dalam kasus ini, permintaan ke test.exampleA.com tidak memenuhi kondisi dan karenanya melewati otorisasi.

Catatan
permissions:
# and_rules: Otorisasi dilakukan jika semua aturan berikut terpenuhi.
- and_rules:
    rules:
      - url_path:
          # Cocokkan awalan path.
          path:
            prefix: /
      - header:
          # Cocokkan ekspresi reguler.
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # Header :authority dapat digunakan untuk mendapatkan nama domain,
          # mengikuti spesifikasi pseudo-header HTTP.
          name: ":authority"

Menggabungkan kondisi dengan and, or, dan not

Logika berikut menentukan kapan otorisasi diperlukan:

  1. Permintaan dengan awalan exampleA.com/api memerlukan otorisasi, dengan pengecualian berikut:

    1. exampleA.com/api/appa/bbb tidak memerlukan otorisasi.

    2. exampleA.com/api/appb/ccc tidak memerlukan otorisasi.

  2. Semua permintaan ke exampleB.com memerlukan otorisasi, dengan pengecualian berikut:

    1. exampleB.com/api/appa/bbb tidak memerlukan otorisasi.

    2. exampleB.com/api/appb/ccc tidak memerlukan otorisasi.

    3. Permintaan dengan awalan exampleB.com/api/appc tidak memerlukan otorisasi, dengan pengecualian berikut:

      1. exampleB.com/api/appc/bbb/ccc memerlukan otorisasi.

      2. exampleB.com/api/appc/ccc/ddd memerlukan otorisasi.

Diagram berikut menggambarkan logika tersebut:

Konfigurasi YAML berikut sesuai dengan logika ini:

permissions:
# or_rules: Otorisasi dilakukan jika salah satu aturan berikut terpenuhi.
- or_rules:
    rules:
      # and_rules: Aturan ini terpenuhi 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: Aturan ini terpenuhi jika kondisi 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: Aturan ini terpenuhi jika kondisi 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"