View a markdown version of this page

Otentikasi pengguna akhir ke Memori dengan OAuth - Batu Dasar Amazon AgentCore
Bagaimana gateway menjembatani OAuth ke MemoriMenerapkan akses per pengguna ke Memori

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Otentikasi pengguna akhir ke Memori dengan OAuth

Bidang data Amazon Bedrock AgentCore Memory mengautentikasi penelepon dengan Sig AWS nature Version 4 (SIGv4) saja. Ketika backend atau agen Anda memanggil Memori atas nama banyak pengguna, Memory hanya melihat peran IAM backend Anda — Memory tidak dapat memverifikasi atau menegakkan pengguna akhir mana permintaan yang diberikan. Menjaga data satu pengguna terpisah dari yang lain sepenuhnya bergantung pada kode aplikasi Anda yang mengatur ruang nama yang benar actorId pada setiap permintaan; tidak ada di lapisan Memori yang mencegah permintaan penanganan Pengguna A membaca data Pengguna B.

Dengan mengawali Memori dengan AgentCore Gateway yang dikonfigurasi untuk otentikasi masuk OAuth (CUSTOM_JWT), Anda menambahkan dukungan OAuth yang tidak dimiliki Memory sendiri. Penelepon menyajikan permintaan JWT pengguna akhir, gateway memvalidasinya, dan kebijakan kontrol akses menegakkan isolasi berdasarkan klaim token - di lapisan infrastruktur, terlepas dari logika aplikasi Anda. Gateway kemudian memanggil Memory di bawah peran eksekusi gateway-nya, bertindak sebagai jembatan antara OAuth-authenticated pemanggil dan bidang IAM-authenticated data Memori.

catatan

Halaman ini dibangun di atas konektor AgentCore Memori. Siapkan gateway dengan target konektor Memori terlebih dahulu. Untuk informasi selengkapnya, lihat Mengakses AgentCore Memori melalui gateway.

Bagaimana gateway menjembatani OAuth ke Memori

Ketika gateway menggunakan oten CUSTOM_JWT tikasi masuk di depan target konektor Memori:

  1. Penelepon mengirimkan permintaan ke gateway dengan token pembawa JWT yang dikeluarkan oleh penyedia OpenID Connect Anda. Tergantung pada aplikasi Anda, token dapat mewakili pengguna akhir atau agen itu sendiri, dan dapat membawa informasi pengguna akhir dalam klaimnya.

  2. Gateway memvalidasi token terhadap penyedia yang Anda konfigurasikan, dan klaim token (seperti sub danclient_id) tersedia untuk kebijakan kontrol akses gateway sebagai tag utama.

  3. Jika kebijakan mengizinkan permintaan, gateway meneruskannya ke bidang data Memori di bawah peran eksekusi gatewaynya (mode kreden GATEWAY_IAM_ROLE si keluar).

Tip

Dalam chatbot atau arsitektur agen yang khas, pengguna akhir tidak memanggil Memory secara langsung. Agen atau layanan backend Anda adalah pemanggil HTTP, dan melewati JWT pengguna akhir bersama dengan setiap permintaan Memori - token “bepergian dengan” permintaan tersebut. Gateway mengautentikasi token itu dan mengevaluasi kebijakan terhadap klaimnya, sehingga akses diberlakukan untuk pengguna akhir yang diwakili token, meskipun agen adalah entitas yang melakukan panggilan.

Inilah sebabnya mengapa kontrol akses yang halus penting: dengan itu, Anda dapat memastikan permintaan hanya mencapai data Memori milik pengguna akhir yang diautentikasi yang dibawa dalam token, daripada mempercayai agen untuk mengatur namespace yang benar actorId dan itu sendiri.

Dengan aplikasi agen, pengguna akhir Anda dapat masuk melalui penyedia identitas OAuth standar — misalnya, Amazon Cognito atau penyedia OpenID Connect mana pun — dan Anda dapat menerapkan isolasi Memori per pengguna berdasarkan identitas pengguna akhir yang diautentikasi. Aplikasi Anda tidak mendistribusikan AWS kredenSIAL kepada pengguna akhir, dan Memori tidak perlu memahami OAuth secara asli.

Mengkonfigurasi otor CUSTOM_JWT isasi (URL penemuan OpenID Connect, audiens dan klien yang diizinkan, dan cakupan) adalah tugas otorisasi masuk gateway standar dan tidak khusus untuk Memori. Untuk konfigurasi otorizer, lihat Membuat AgentCore gateway. Untuk bagaimana klaim JWT dipetakan ke prinsi AgentCore::OAuthUser pal dan tagnya, lihat Konsep Konsep inti inti.

catatan

OAuth (CUSTOM_JWT) inbound hanya kompatibel dengan mode kredensi keluarGATEWAY_IAM_ROLE. CALLER_IAM_CREDENTIALSMode meneruskan identitas IAM pemanggil, yang tidak ada untuk pemang JWT-authenticated gil, sehingga ditolak saat pembuatan target. Untuk matriks kompatibilitas penuh, lihat Mode otentikasi masuk dan keluar.

Menerapkan akses per pengguna ke Memori

Mengautentikasi penelepon dengan OAuth adalah apa yang memungkinkan otorisasi berbasis identitas, tetapi otentikasi saja tidak membatasi apa yang dapat dilakukan pemanggil. Setiap permintaan dengan token yang valid masih dapat menjangkau setiap aktor, sesi, dan namespace di sumber daya Memori. Untuk memastikan setiap permintaan hanya dapat mengakses data Memori milik pengguna akhir yang diautentikasi — yang identitasnya dibawa dalam JWT — tambahkan kebijakan kontrol akses dengan kontrol akses yang halus. Untuk cara menulis kebijakan tersebut, lihat kontrol Fine-grained akses untuk Memori.