Model desain untuk OPA

Menggunakan PDP terpusat dengan PEP pada API

Titik keputusan kebijakan terpusat (PDP) dengan poin penegakan kebijakan (PEP) pada model API mengikuti praktik terbaik industri untuk menciptakan sistem yang efektif dan mudah dipelihara untuk kontrol akses dan otorisasi API. Pendekatan ini mendukung beberapa prinsip utama:

• Otorisasi dan kontrol akses API diterapkan di beberapa titik dalam aplikasi.

• Logika otorisasi tidak tergantung pada aplikasi.

• Keputusan kontrol akses terpusat.

Model ini menggunakan PDP terpusat untuk membuat keputusan otorisasi. PEP diimplementasikan di semua API untuk membuat permintaan otorisasi ke PDP. Diagram berikut menunjukkan bagaimana Anda dapat menerapkan model ini dalam aplikasi SaaS multi-penyewa hipotetis.

Alur aplikasi (diilustrasikan dengan callout bernomor biru dalam diagram):

1. Pengguna yang diautentikasi dengan JWT menghasilkan permintaan HTTP ke Amazon. CloudFront

2. CloudFront meneruskan permintaan ke Amazon API Gateway, yang dikonfigurasi sebagai CloudFront asal.

3. Authorizer kustom API Gateway dipanggil untuk memverifikasi JWT.

4. Layanan mikro menanggapi permintaan tersebut.

Alur kontrol akses otorisasi dan API (diilustrasikan dengan callout bernomor merah dalam diagram):

1. PEP memanggil layanan otorisasi dan meneruskan data permintaan, termasuk JWT apa pun.

2. Layanan otorisasi (PDP) mengambil data permintaan dan menanyakan API REST agen OPA, yang berjalan sebagai sespan. Data permintaan berfungsi sebagai masukan ke kueri.

3. OPA mengevaluasi input berdasarkan kebijakan relevan yang ditentukan oleh kueri. Data diimpor untuk membuat keputusan otorisasi jika perlu.

4. OPA mengembalikan keputusan ke layanan otorisasi.

5. Keputusan otorisasi dikembalikan ke PEP dan dievaluasi.

Dalam arsitektur ini, PEP meminta keputusan otorisasi di titik akhir layanan untuk Amazon CloudFront dan Amazon API Gateway, dan untuk setiap layanan mikro. Keputusan otorisasi dibuat oleh layanan otorisasi (PDP) dengan sespan OPA. Anda dapat mengoperasikan layanan otorisasi ini sebagai wadah atau sebagai contoh server tradisional. Sidecar OPA mengekspos RESTful API secara lokal sehingga API hanya dapat diakses oleh layanan otorisasi. Layanan otorisasi mengekspos API terpisah yang tersedia untuk PEP. Memiliki layanan otorisasi bertindak sebagai perantara antara PEP dan OPA memungkinkan penyisipan logika transformasi apa pun antara PEP dan OPA yang mungkin diperlukan—misalnya, ketika permintaan otorisasi dari PEP tidak sesuai dengan input kueri yang diharapkan oleh OPA.

Anda juga dapat menggunakan arsitektur ini dengan mesin kebijakan khusus. Namun, keuntungan apa pun yang diperoleh dari OPA harus diganti dengan logika yang disediakan oleh mesin kebijakan khusus.

PDP terpusat dengan PEP pada API menyediakan opsi mudah untuk membuat sistem otorisasi yang kuat untuk API. Mudah diimplementasikan dan juga menyediakan antarmuka yang easy-to-use dapat diulang untuk membuat keputusan otorisasi untuk API, layanan mikro, lapisan Backend for Frontend (BFF), atau komponen aplikasi lainnya. Namun, pendekatan ini mungkin membuat terlalu banyak latensi dalam aplikasi Anda, karena keputusan otorisasi memerlukan pemanggilan API terpisah. Jika latensi jaringan menjadi masalah, Anda dapat mempertimbangkan PDP terdistribusi.

Menggunakan PDP terdistribusi dengan PEP pada API

Titik keputusan kebijakan terdistribusi (PDP) dengan poin penegakan kebijakan (PEP) pada model API mengikuti praktik terbaik industri untuk menciptakan sistem yang efektif untuk kontrol akses dan otorisasi API. Seperti PDP terpusat dengan PEP pada model API, pendekatan ini mendukung prinsip-prinsip utama berikut:

• Otorisasi dan kontrol akses API diterapkan di beberapa titik dalam aplikasi.

• Logika otorisasi tidak tergantung pada aplikasi.

• Keputusan kontrol akses terpusat.

Anda mungkin bertanya-tanya mengapa keputusan kontrol akses terpusat ketika PDP didistribusikan. Meskipun PDP mungkin ada di beberapa tempat dalam aplikasi, PDP harus menggunakan logika otorisasi yang sama untuk membuat keputusan kontrol akses. Semua PDP memberikan keputusan kontrol akses yang sama dengan masukan yang sama. PEP diimplementasikan di semua API untuk membuat permintaan otorisasi ke PDP. Gambar berikut menunjukkan bagaimana model terdistribusi ini dapat diimplementasikan dalam aplikasi SaaS multi-penyewa hipotetis.

Dalam pendekatan ini, PDP diimplementasikan di banyak tempat dalam aplikasi. Untuk komponen aplikasi yang memiliki kemampuan komputasi onboard yang dapat menjalankan OPA dan mendukung PDP, seperti layanan kontainer dengan sespan atau Amazon Elastic Compute Cloud (Amazon EC2) Elastic Cloud (Amazon EC2), keputusan PDP dapat diintegrasikan langsung ke dalam komponen aplikasi tanpa harus melakukan panggilan RESTful API ke layanan PDP terpusat. Ini memiliki manfaat mengurangi latensi yang mungkin Anda temui dalam model PDP terpusat, karena tidak setiap komponen aplikasi harus melakukan panggilan API tambahan untuk mendapatkan keputusan otorisasi. Namun, PDP terpusat masih diperlukan dalam model ini untuk komponen aplikasi yang tidak memiliki kemampuan komputasi onboard yang memungkinkan integrasi langsung PDP—seperti layanan Amazon atau Amazon CloudFront API Gateway.

Diagram berikut menunjukkan bagaimana kombinasi PDP terpusat dan PDP terdistribusi ini dapat diimplementasikan dalam aplikasi SaaS multi-penyewa hipotetis.

Alur aplikasi (diilustrasikan dengan callout bernomor biru dalam diagram):

1. Pengguna yang diautentikasi dengan JWT menghasilkan permintaan HTTP ke Amazon. CloudFront

2. CloudFront meneruskan permintaan ke Amazon API Gateway, yang dikonfigurasi sebagai CloudFront asal.

3. Authorizer kustom API Gateway dipanggil untuk memverifikasi JWT.

4. Layanan mikro menanggapi permintaan tersebut.

Alur kontrol akses otorisasi dan API (diilustrasikan dengan callout bernomor merah dalam diagram):

1. PEP memanggil layanan otorisasi dan meneruskan data permintaan, termasuk JWT apa pun.

2. Layanan otorisasi (PDP) mengambil data permintaan dan menanyakan API REST agen OPA, yang berjalan sebagai sespan. Data permintaan berfungsi sebagai masukan ke kueri.

3. OPA mengevaluasi input berdasarkan kebijakan relevan yang ditentukan oleh kueri. Data diimpor untuk membuat keputusan otorisasi jika perlu.

4. OPA mengembalikan keputusan ke layanan otorisasi.

5. Keputusan otorisasi dikembalikan ke PEP dan dievaluasi.

Dalam arsitektur ini, PEP meminta keputusan otorisasi di titik akhir layanan untuk dan API CloudFront Gateway, dan untuk setiap layanan mikro. Keputusan otorisasi untuk layanan mikro dibuat oleh layanan otorisasi (PDP) yang beroperasi sebagai sespan dengan komponen aplikasi. Model ini dimungkinkan untuk layanan mikro (atau layanan) yang berjalan pada container atau instans Amazon Elastic Compute Cloud (Amazon EC2). Keputusan otorisasi untuk layanan seperti API Gateway dan CloudFront masih perlu menghubungi layanan otorisasi eksternal. Terlepas dari itu, layanan otorisasi mengekspos API yang tersedia untuk PEP. Memiliki layanan otorisasi bertindak sebagai perantara antara PEP dan OPA memungkinkan penyisipan logika transformasi apa pun antara PEP dan OPA yang mungkin diperlukan—misalnya, ketika permintaan otorisasi dari PEP tidak sesuai dengan input kueri yang diharapkan oleh OPA.

Anda juga dapat menggunakan arsitektur ini dengan mesin kebijakan khusus. Namun, keuntungan apa pun yang diperoleh dari OPA harus diganti dengan logika yang disediakan oleh mesin kebijakan khusus.

PDP terdistribusi dengan PEP pada API menyediakan opsi untuk membuat sistem otorisasi yang kuat untuk API. Sangat mudah untuk menerapkan dan menyediakan antarmuka yang easy-to-use dapat diulang untuk membuat keputusan otorisasi untuk API, layanan mikro, lapisan Backend for Frontend (BFF), atau komponen aplikasi lainnya. Pendekatan ini juga memiliki keuntungan mengurangi latensi yang mungkin Anda temui dalam model PDP terpusat.

Menggunakan PDP terdistribusi sebagai pustaka

Anda juga dapat meminta keputusan otorisasi dari PDP yang tersedia sebagai pustaka atau paket untuk digunakan dalam aplikasi. OPA dapat digunakan sebagai pustaka pihak ketiga Go. Untuk bahasa pemrograman lain, mengadopsi model ini umumnya berarti Anda harus membuat mesin kebijakan khusus.