翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
コンテキストは、ポリシーの決定に関連する情報ですが、プリンシパル、アクション、またはリソースのアイデンティティの一部ではありません。アクセストークンクレームはコンテキストです。一連の送信元 IP アドレスからのみ、またはユーザーが MFA でサインインした場合にのみ、アクションを許可できます。アプリケーションはこのコンテキストセッションデータにアクセスできるため、承認リクエストに入力する必要があります。Verified Permissions 認可リクエストのコンテキストデータは、 contextMap要素で JSON 形式である必要があります。
このコンテンツを説明する例は、サンプルポリシーストアから取得されています。これを行うには、テスト環境に DigitalPetStore サンプルポリシーストアを作成します。
次のコンテキストオブジェクトは、サンプルの DigitalPetStore ポリシーストアに基づいて、アプリケーションの各 Cedar データ型のいずれかを宣言します。
"context": {
"contextMap": {
"MfaAuthorized": {
"boolean": true
},
"AccountCodes": {
"set": [
{
"long": 111122223333
},
{
"long": 444455556666
},
{
"long": 123456789012
}
]
},
"UserAgent": {
"string": "My UserAgent 1.12"
},
"RequestedOrderCount": {
"long": 4
},
"NetworkInfo": {
"record": {
"IPAddress": {
"string": "192.0.2.178"
},
"Country": {
"string": "United States of America"
},
"SSL": {
"boolean": true
}
}
},
"approvedBy": {
"entityIdentifier": {
"entityId": "Bob",
"entityType": "DigitalPetStore::User"
}
}
}
}認可コンテキストのデータ型
- ブール値
-
バイナリ
trueまたはfalse値。この例では、trueのブール値 は、顧客が注文の表示をリクエストする前に多要素認証を実行したMfaAuthenticatedことを示します。 - 設定
-
コンテキスト要素のコレクション。セットメンバーは、この例のようにすべて同じタイプにすることも、ネストされたセットを含む異なるタイプにすることもできます。この例では、顧客は 3 つの異なるアカウントに関連付けられています。
- String
-
文字で囲まれた文字、数字、または記号のシーケンス
"。この例では、UserAgent文字列 は、顧客が注文の表示をリクエストするために使用したブラウザを表します。 - Long
-
整数。この例では、 は、顧客が過去の注文のうち 4 つを表示するように求めた結果、このリクエストがバッチの一部である
RequestedOrderCountことを示します。 - レコード
-
属性のコレクション。これらの属性は、リクエストコンテキストで宣言する必要があります。スキーマを含むポリシーストアには、このエンティティと、スキーマ内のエンティティの属性を含める必要があります。この例では、
NetworkInfoレコードには、ユーザーの発信元 IP、クライアントによって決定されるその IP の位置情報、および転送中の暗号化に関する情報が含まれています。 - EntityIdentifier
-
リクエストの
entities要素で宣言されたエンティティと属性への参照。この例では、ユーザーの注文が従業員 によって承認されましたBob。
このサンプルコンテキストをサンプル DigitalPetStore アプリケーションでテストするには、リクエスト entities、ポリシーストアスキーマ、静的ポリシーを、顧客ロール - 注文の取得の説明で更新する必要があります。
認可コンテキストを受け入れるように DigitalPetStore を変更する
当初、 DigitalPetStore はそれほど複雑なポリシーストアではありません。提示したコンテキストをサポートするために事前設定されたポリシーやコンテキスト属性は含まれません。このコンテキスト情報を使用して認可リクエストの例を評価するには、ポリシーストアと認可リクエストに次の変更を加えます。アクセストークン情報をコンテキストとするコンテキストの例については、「」を参照してくださいアクセストークンをマッピングする。
新しいコンテキスト属性をサポートするために、ポリシーストアスキーマに次の更新を適用します。GetOrder でactions次のように更新します。
"GetOrder": {
"memberOf": [],
"appliesTo": {
"resourceTypes": [
"Order"
],
"context": {
"type": "Record",
"attributes": {
"UserAgent": {
"required": true,
"type": "String"
},
"approvedBy": {
"name": "User",
"required": true,
"type": "Entity"
},
"AccountCodes": {
"type": "Set",
"required": true,
"element": {
"type": "Long"
}
},
"RequestedOrderCount": {
"type": "Long",
"required": true
},
"MfaAuthorized": {
"type": "Boolean",
"required": true
}
}
},
"principalTypes": [
"User"
]
}
}リクエストコンテキストNetworkInfoで という名前recordのデータ型を参照するには、次のようにスキーマに commonTypecommonType コンストラクトは、異なるエンティティに適用できる属性の共有セットです。
注記
Verified Permissions ビジュアルスキーマエディタは現在commonTypeコンストラクトをサポートしていません。スキーマに追加すると、Visual モードでスキーマを表示できなくなります。
"commonTypes": {
"NetworkInfo": {
"attributes": {
"IPAddress": {
"type": "String",
"required": true
},
"SSL": {
"required": true,
"type": "Boolean"
},
"Country": {
"required": true,
"type": "String"
}
},
"type": "Record"
}
}