Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memetakan token OIDC ke skema
Anda mungkin menemukan bahwa Anda ingin menambahkan sumber identitas ke toko kebijakan dan klaim penyedia peta, atau token, ke skema toko kebijakan Anda. Anda dapat mengotomatiskan proses ini, dengan menggunakan Pengaturan terpandu untuk membuat penyimpanan kebijakan Anda dengan sumber identitas, atau memperbarui skema Anda secara manual setelah penyimpanan kebijakan dibuat. Setelah Anda memetakan token ke skema, Anda dapat membuat kebijakan yang mereferensikannya.
Bagian panduan pengguna ini memiliki informasi berikut:
-
Bila Anda dapat secara otomatis mengisi atribut ke skema penyimpanan kebijakan
-
Cara membuat skema untuk sumber identitas secara manual
Penyimpanan kebijakan terkait API dan penyimpanan kebijakan dengan sumber identitas yang dibuat melalui penyiapan Terpandu tidak memerlukan pemetaan manual atribut token identitas (ID) ke skema. Anda dapat memberikan Izin Terverifikasi dengan atribut di kumpulan pengguna dan membuat skema yang diisi dengan atribut pengguna. Dalam otorisasi token ID, Izin Terverifikasi memetakan klaim ke atribut entitas utama.
Untuk menggunakan penyedia identitas OIDC (iDP) sebagai sumber identitas di toko kebijakan Izin Terverifikasi, Anda harus memiliki atribut penyedia dalam skema Anda. Skema diperbaiki dan harus sesuai dengan entitas yang dibuat oleh token penyedia IsAuthorizedWithTokenatau permintaan BatchIsAuthorizedWithTokenAPI. Jika Anda membuat toko kebijakan dengan cara yang secara otomatis mengisi skema Anda dari informasi penyedia dalam token ID, Anda siap untuk menulis kebijakan. Jika Anda membuat penyimpanan kebijakan tanpa skema untuk sumber identitas, Anda harus menambahkan atribut penyedia ke skema yang cocok dengan entitas yang dibuat menggunakan permintaan API. Kemudian Anda dapat menulis kebijakan menggunakan atribut dari token penyedia.
Topik
Memetakan token ID ke skema
Izin Terverifikasi memproses klaim token ID sebagai atribut pengguna: nama dan judul mereka, keanggotaan grup mereka, informasi kontak mereka. Token ID paling berguna dalam model otorisasi kontrol akses berbasis atribut (ABAC). Jika Anda ingin Izin Terverifikasi menganalisis akses ke sumber daya berdasarkan siapa yang membuat permintaan, pilih token ID untuk sumber identitas Anda.
Bekerja dengan token ID dari penyedia OIDC hampir sama dengan bekerja dengan token ID Amazon Cognito. Perbedaannya ada pada klaim. IDP Anda mungkin menampilkan atribut OIDC standar
Untuk informasi selengkapnya, lihat Membuat toko kebijakan Izin Terverifikasi.
Berikut ini adalah contoh skema untuk toko kebijakan dengan sumber identitas OIDC.
"User": { "shape": { "type": "Record", "attributes": { "email": { "type": "String" }, "email_verified": { "type": "Boolean" }, "name": { "type": "String", "required": true }, "phone_number": { "type": "String" }, "phone_number_verified": { "type": "Boolean" } } } }
Untuk contoh kebijakan yang akan memvalidasi skema ini, lihat. Mencerminkan atribut token ID OIDC
Memetakan token akses
Izin Terverifikasi memproses klaim token akses selain klaim grup sebagai atribut tindakan, atau atribut konteks. Seiring dengan keanggotaan grup, token akses dari IDP Anda mungkin berisi informasi tentang akses API. Token akses berguna dalam model otorisasi yang menggunakan kontrol akses berbasis peran (RBAC). Model otorisasi yang mengandalkan klaim token akses selain keanggotaan grup memerlukan upaya tambahan dalam konfigurasi skema.
Sebagian besar token akses dari penyedia OIDC eksternal sejajar erat dengan token akses Amazon Cognito. Token akses OIDC dipetakan ke objek konteks saat diteruskan ke Izin Terverifikasi. Atribut token akses dapat direferensikan menggunakancontext.token.
. Contoh token akses OIDC berikut mencakup contoh klaim dasar.attribute_name
{ "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e", "groups": [ "Store-Owner-Role", "Customer" ], "iss": "https://auth.example.com", "client_id": "1example23456789", "aud": "https://myapplication.example.com" "scope": "MyAPI-Read", "exp": 1688096566, "iat": 1688092966, "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222", "username": "alice" }
Contoh berikut menunjukkan cara mencerminkan atribut dari token akses contoh dalam skema Izin Terverifikasi Anda. Untuk informasi selengkapnya tentang mengedit skema Anda, lihatMengedit skema toko kebijakan.
{ "MyApplication": { "actions": { "Read": { "appliesTo": { "context": { "type": "ReusedContext" }, "resourceTypes": [ "Application" ], "principalTypes": [ "User" ] } } }, ... ... "commonTypes": { "ReusedContext": { "attributes": { "token": { "type": "Record", "attributes": { "scope": { "type": "Set", "element": { "type": "String" } }, "client_id": { "type": "String" } } } }, "type": "Record" } } } }
Untuk contoh kebijakan yang akan memvalidasi skema ini, lihat. Mencerminkan atribut token akses OIDC
Hal-hal yang perlu diketahui tentang pemetaan skema
Pemetaan atribut berbeda antara jenis token
Dalam otorisasi token akses, Izin Terverifikasi memetakan klaim ke konteks. Dalam otorisasi token ID, Izin Terverifikasi memetakan klaim ke atribut utama. Untuk penyimpanan kebijakan yang Anda buat di konsol Izin Terverifikasi, hanya penyimpanan kebijakan kosong dan contoh yang tidak memiliki sumber identitas dan mengharuskan Anda mengisi skema Anda dengan atribut kumpulan pengguna untuk otorisasi token ID. Otorisasi token akses didasarkan pada kontrol akses berbasis peran (RBAC) dengan klaim keanggotaan grup dan tidak secara otomatis memetakan klaim lain ke skema penyimpanan kebijakan.
Atribut sumber identitas tidak diperlukan
Saat Anda membuat sumber identitas di konsol Izin Terverifikasi, tidak ada atribut yang ditandai sebagai wajib. Ini mencegah klaim yang hilang menyebabkan kesalahan validasi dalam permintaan otorisasi. Anda dapat mengatur atribut ke required sesuai kebutuhan, tetapi atribut tersebut harus ada di semua permintaan otorisasi.
RBAC tidak memerlukan atribut dalam skema
Skema untuk sumber identitas bergantung pada asosiasi entitas yang Anda buat saat menambahkan sumber identitas. Sumber identitas memetakan satu klaim ke jenis entitas pengguna, dan satu klaim ke jenis entitas grup. Pemetaan entitas ini adalah inti dari konfigurasi sumber identitas. Dengan informasi minimum ini, Anda dapat menulis kebijakan yang melakukan tindakan otorisasi untuk pengguna tertentu dan grup tertentu yang mungkin menjadi anggota pengguna, dalam model kontrol akses berbasis peran (RBAC). Penambahan klaim token ke skema memperluas cakupan otorisasi toko kebijakan Anda. Atribut pengguna dari token ID memiliki informasi tentang pengguna yang dapat berkontribusi pada otorisasi kontrol akses berbasis atribut (ABAC). Atribut konteks dari token akses memiliki informasi seperti cakupan OAuth 2.0 yang dapat menyumbangkan informasi kontrol akses tambahan dari penyedia Anda, tetapi memerlukan modifikasi skema tambahan.
Opsi Pengaturan dengan API Gateway dan penyedia identitas serta Penyiapan terpandu di konsol Izin Terverifikasi menetapkan klaim token ID ke skema. Ini tidak berlaku untuk klaim token akses. Untuk menambahkan klaim token akses non-grup ke skema Anda, Anda harus mengedit skema Anda dalam mode JSON dan menambahkan atribut CommonTypes.
Klaim grup OIDC mendukung berbagai format
Saat menambahkan penyedia OIDC, Anda dapat memilih nama klaim grup di ID atau token akses yang ingin dipetakan ke keanggotaan grup pengguna di toko kebijakan Anda. Izin terverifikasi mengenali klaim grup dalam format berikut:
-
String tanpa spasi:
"groups": "MyGroup"
-
Daftar yang dibatasi ruang:.
"groups": "MyGroup1 MyGroup2 MyGroup3"
Setiap string adalah grup. -
Daftar JSON (dibatasi koma):
"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]
catatan
Izin Terverifikasi menafsirkan setiap string dalam klaim grup yang dipisahkan spasi sebagai grup terpisah. Untuk menafsirkan nama grup dengan karakter spasi sebagai grup tunggal, ganti atau hapus spasi dalam klaim. Misalnya, format grup bernama My
Group
sebagaiMyGroup
.
Pilih jenis token
Cara penyimpanan kebijakan Anda bekerja dengan sumber identitas Anda bergantung pada keputusan kunci dalam konfigurasi sumber identitas: apakah Anda akan memproses ID atau token akses. Dengan penyedia OIDC, Anda harus memilih jenis token saat menambahkan sumber identitas. Anda dapat memilih ID atau token akses, dan pilihan Anda mengecualikan jenis token yang tidak dipilih untuk diproses di toko kebijakan Anda. Terutama jika Anda ingin mendapatkan keuntungan dari pemetaan otomatis klaim token ID ke atribut di konsol Izin Terverifikasi, putuskan lebih awal tentang jenis token yang ingin Anda proses sebelum Anda membuat sumber identitas Anda. Mengubah jenis token membutuhkan upaya yang signifikan untuk memfaktorkan ulang kebijakan dan skema Anda. Topik berikut menjelaskan penggunaan ID dan token akses dengan toko kebijakan.
Parser cedar membutuhkan tanda kurung untuk beberapa karakter
Kebijakan biasanya referensi atribut skema dalam format sepertiprincipal.username
. Dalam kasus sebagian besar karakter non-alfanumerik seperti:
,.
, atau /
yang mungkin muncul di nama klaim token, Izin Terverifikasi tidak dapat mengurai nilai kondisi seperti atau. principal.cognito:username
context.ip-address
Anda harus memformat kondisi ini dengan notasi braket dalam format principal["cognito:username"]
ataucontext["ip-address"]
, masing-masing. Karakter garis bawah _
adalah karakter yang valid dalam nama klaim, dan satu-satunya pengecualian non-alfanumerik untuk persyaratan ini.
Contoh sebagian skema untuk atribut utama dari jenis ini terlihat seperti berikut:
"User": { "shape": { "type": "Record", "attributes": { "cognito:username": { "type": "String", "required": true }, "custom:employmentStoreCode": { "type": "String", "required": true, }, "email": { "type": "String", "required": false } } } }
Contoh sebagian skema untuk atribut konteks jenis ini terlihat seperti berikut:
"GetOrder": { "memberOf": [], "appliesTo": { "resourceTypes": [ "Order" ], "context": { "type": "Record", "attributes": { "ip-address": { "required": false, "type": "String" } } }, "principalTypes": [ "User" ] } }
Untuk contoh kebijakan yang akan memvalidasi skema ini, lihat. Menggunakan notasi braket untuk referensi atribut token