Model desain untuk OPA

Menggunakan PDP terpusat dengan on PEPs APIs

Titik keputusan kebijakan terpusat (PDP) dengan poin penegakan kebijakan (PEPs) pada APIs model 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. PEPs diimplementasikan sama sekali APIs 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 apa pun. JWTs

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, PEPs minta 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-nya secara lokal sehingga API hanya dapat diakses oleh layanan otorisasi. Layanan otorisasi mengekspos API terpisah yang tersedia untuk. PEPs Memiliki layanan otorisasi bertindak sebagai perantara antara PEPs dan OPA memungkinkan penyisipan logika transformasi apa pun antara PEPs 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 PEPs on APIs menyediakan opsi mudah untuk membuat sistem otorisasi yang kuat. APIs Mudah diimplementasikan dan juga menyediakan antarmuka yang dapat diulang untuk membuat keputusan otorisasi untuk easy-to-use, layanan mikro APIs, 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 PEPs on APIs

Titik keputusan kebijakan terdistribusi (PDP) dengan poin penegakan kebijakan (PEPs) pada APIs model mengikuti praktik terbaik industri untuk menciptakan sistem yang efektif untuk kontrol akses dan otorisasi API. Seperti PDP terpusat dengan APIs model PEPs on, pendekatan ini mendukung prinsip-prinsip kunci 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 PDPs memberikan keputusan kontrol akses yang sama dengan masukan yang sama. PEPs diimplementasikan sama sekali APIs untuk membuat permintaan otorisasi ke PDP. Gambar berikut menunjukkan bagaimana model terdistribusi ini dapat diimplementasikan dalam aplikasi SaaS multi-penyewa hipotetis.

Dalam pendekatan ini, PDPs diimplementasikan di beberapa tempat dalam aplikasi. Untuk komponen aplikasi yang memiliki kemampuan komputasi onboard yang dapat menjalankan OPA dan mendukung PDP, seperti layanan kontainer dengan sespan atau instans Amazon Elastic Compute Cloud (Amazon EC2), keputusan PDP dapat diintegrasikan langsung ke dalam komponen aplikasi tanpa harus melakukan panggilan API ke layanan PDP terpusat. RESTful 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 apa pun. JWTs

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, PEPs minta keputusan otorisasi di titik akhir layanan untuk CloudFront dan API 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 EC2 (Amazon). 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. PEPs Memiliki layanan otorisasi bertindak sebagai perantara antara PEPs dan OPA memungkinkan penyisipan logika transformasi apa pun antara PEPs 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 PEPs on APIs menyediakan opsi untuk membuat sistem otorisasi yang kuat untuk. APIs Sangat mudah untuk menerapkan dan menyediakan antarmuka yang dapat diulang untuk membuat keputusan otorisasi untuk easy-to-use, layanan mikro APIs, 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.