스키마에 자격 증명 공급자 토큰 매핑 - Amazon Verified Permissions
ID 토큰 매핑액세스 토큰 매핑Amazon Cognito 콜론으로 구분된 클레임에 대한 대체 표기법스키마 매핑에 대해 알아야 할 사항

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

스키마에 자격 증명 공급자 토큰 매핑

정책 스토어에 자격 증명 소스를 추가하고 정책 스토어 스키마에 공급자 클레임을 매핑하려는 경우가 있습니다. 이 프로세스를 자동화하거나 스키마를 수동으로 업데이트할 수 있습니다. 토큰을 스키마에 매핑한 후에는 토큰을 참조하는 정책을 생성할 수 있습니다.

사용 설명서의 이 섹션에는 다음 정보가 나와 있습니다.

  • 정책 스토어 스키마에 속성을 자동으로 채울 수 있는 경우

  • Verified Permissions 정책에서 Amazon Cognito 및 OIDC 토큰 클레임을 사용하는 방법

  • 자격 증명 소스에 대한 스키마를 수동으로 빌드하는 방법

API-가이드 설정을 통해 생성된 자격 증명 소스가 있는 연결된 정책 스토어 및 정책 스토어는 스키마에 자격 증명(ID) 토큰 속성을 수동으로 매핑할 필요가 없습니다. Verified Permissions 정책 스토어 생성 사용자 풀의 속성을 사용하여 Verified Permissions를 제공하고 사용자 속성으로 채워진 스키마를 생성할 수 있습니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 엔터티의 속성에 매핑합니다. 다음 조건에서 Amazon Cognito 토큰을 스키마에 수동으로 매핑해야 할 수 있습니다.

  • 샘플에서 빈 정책 스토어 또는 정책 스토어를 생성했습니다.

  • 역할 기반 액세스 제어 이상으로 액세스 토큰 사용을 확장하려고 합니다(RBAC).

  • Verified Permissions REST API, AWS SDK또는 를 사용하여 정책 스토어를 생성합니다 AWS CDK.

Verified Permissions 정책 스토어에서 Amazon Cognito 또는 OIDC 자격 증명 공급자(IdP )를 자격 증명 소스로 사용하려면 스키마에 공급자 속성이 있어야 합니다. 스키마는 고정되며 공급자 토큰이 IsAuthorizedWithToken 또는 BatchIsAuthorizedWithToken API 요청에서 생성하는 엔터티에 해당해야 합니다. ID 토큰의 공급자 정보에서 스키마를 자동으로 채우는 방식으로 정책 스토어를 생성한 경우 정책을 작성할 준비가 된 것입니다. 자격 증명 소스에 대한 스키마 없이 정책 스토어를 생성하는 경우 API 요청을 사용하여 생성된 엔터티와 일치하는 스키마에 공급자 속성을 추가해야 합니다. 그런 다음 공급자 토큰의 속성을 사용하여 정책을 작성할 수 있습니다.

Verified Permissions에서 인증된 사용자에 대한 Amazon Cognito ID 및 액세스 토큰 사용에 대한 자세한 내용은 Amazon Amazon Cognito 개발자 안내서의 Amazon Verified Permissions 권한 부여를 참조하세요.

ID 토큰을 스키마에 매핑

Verified Permissions는 ID 토큰 클레임을 사용자의 이름 및 제목, 그룹 멤버십, 연락처 정보와 같은 사용자의 속성으로 처리합니다. ID 토큰은 속성 기반 액세스 제어(ABAC) 권한 부여 모델에서 가장 유용합니다. Verified Permissions가 요청자를 기반으로 리소스에 대한 액세스를 분석하도록 하려면 자격 증명 소스의 ID 토큰을 선택합니다.

Amazon Cognito ID 토큰

Amazon Cognito ID 토큰은 대부분의 OIDC 의존 당사자 라이브러리 에서 작동합니다. 추가 클레임으로 의 기능을 확장OIDC합니다. 애플리케이션은 Amazon Cognito 사용자 풀 인증 API 작업 또는 사용자 풀 호스팅 UI를 사용하여 사용자를 인증할 수 있습니다. 자세한 내용은 Amazon Cognito 개발자 안내서의 API 및 엔드포인트 사용을 참조하세요.

Amazon Cognito ID 토큰의 유용한 클레임
cognito:username 및 preferred_username

사용자 사용자 이름의 변형입니다.

sub

사용자의 고유 사용자 식별자(UUID)

custom: 접두사가 있는 클레임

와 같은 사용자 지정 사용자 풀 속성의 접두사입니다custom:employmentStoreCode.

표준 클레임

email 및 와 같은 표준 OIDC 클레임phone_number. 자세한 내용은 에라타 세트 2를 포함하는 OpenID Connect Core 1.0의 표준 클레임을 참조하세요.

cognito:groups

사용자의 그룹 멤버십입니다. 역할 기반 액세스 제어(RBAC)를 기반으로 하는 권한 부여 모델에서 이 클레임은 정책에서 평가할 수 있는 역할을 나타냅니다.

일시적 클레임

사용자의 속성은 아니지만 사용자 풀 사전 토큰 생성 Lambda 트리거에 의해 런타임에 추가되는 클레임입니다. 임시 클레임은 표준 클레임과 유사하지만 tenant 또는 와 같이 표준을 벗어납니다department.

: 구분 기호가 있는 Amazon Cognito 속성을 참조하는 정책에서 형식의 속성을 참조합니다principal["cognito:username"]. 역할 클레임cognito:groups은 이 규칙에 대한 예외입니다. Verified Permissions는 이 클레임의 내용을 사용자 엔터티의 상위 엔터티에 매핑합니다.

Amazon Cognito 사용자 풀의 ID 토큰 구조에 대한 자세한 내용은 Amazon Cognito 개발자 안내서의 ID 토큰 사용을 참조하세요.

다음 예제 ID 토큰에는 네 가지 유형의 속성이 각각 있습니다. 여기에는 Amazon Cognito 관련 클레임 cognito:username, 사용자 지정 클레임 custom:employmentStoreCode, 표준 클레임 email, 및 일시적 클레임 tenant이 포함됩니다.

{
    "sub": "91eb4550-XXX",
    "cognito:groups": [
        "Store-Owner-Role",
        "Customer"
    ],
    "email_verified": true,
    "clearance": "confidential",
    "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
    "cognito:username": "alice",
    "custom:employmentStoreCode": "petstore-dallas",
    "origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77",
    "aud": "1example23456789",
    "event_id": "0ed5ad5c-7182-4ecf-XXX",
    "token_use": "id",
    "auth_time": 1687885407,
    "department": "engineering",
    "exp": 1687889006,
    "iat": 1687885407,
    "tenant": "x11app-tenant-1",
    "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
    "email": "alice@example.com"
}

Amazon Cognito 사용자 풀로 자격 증명 소스를 생성할 때 Verified Permissions가 를 사용하여 권한 부여 요청에서 생성하는 보안 주체 엔터티 유형을 지정합니다IsAuthorizedWithToken. 그러면 정책을 통해 해당 요청 평가의 일환으로 해당 보안 주체의 속성을 테스트할 수 있습니다. 스키마는 자격 증명 소스의 보안 주체 유형과 속성을 정의한 다음 Cedar 정책에서 참조할 수 있습니다.

ID 토큰 그룹 클레임에서 파생하려는 그룹 엔터티 유형도 지정합니다. 권한 부여 요청에서 Verified Permissions는 그룹 클레임의 각 구성원을 해당 그룹 엔터티 유형에 매핑합니다. 정책에서 해당 그룹 엔터티를 보안 주체로 참조할 수 있습니다.

다음 예는 Verified Permissions 스키마에 자격 증명 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 JSON 모드에서 정책 스토어 스키마 편집을(를) 참조하세요. 자격 증명 소스 구성에서 보안 주체 유형 User를 지정하면 다음 예제와 유사한 내용을 포함하여 Cedar에서 해당 속성을 사용할 수 있도록 할 수 있습니다.

"User": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito:username": {
            "type": "String",
            "required": false
         },
         "custom:employmentStoreCode": {
            "type": "String",
            "required": false
         },
         "email": {
            "type": "String"
         },
         "tenant": {
            "type": "String",
            "required": true
         }
      }
   }
}

이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요Amazon Cognito ID 토큰 속성을 반영합니다..

OIDC ID 토큰

OIDC 공급자의 ID 토큰 작업은 Amazon Cognito ID 토큰 작업과 거의 동일합니다. 차이점은 클레임에 있습니다. IdP는 표준 OIDC 속성 를 제공하거나 사용자 지정 스키마가 있을 수 있습니다. Verified Permissions 콘솔에서 새 정책 스토어를 생성할 때 예제 ID 토큰을 사용하여 OIDC 자격 증명 소스를 추가하거나 사용자 속성에 토큰 클레임을 수동으로 매핑할 수 있습니다. Verified Permissions는 IdP 의 속성 스키마를 인식하지 못하므로 이 정보를 제공해야 합니다.

자세한 내용은 Verified Permissions 정책 스토어 생성 단원을 참조하십시오.

다음은 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"
         }
      }
   }
}

이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요OIDC ID 토큰 속성을 반영합니다..

액세스 토큰 매핑

Verified Permissions는 그룹 클레임 이외의 액세스 토큰 클레임을 작업의 속성 또는 컨텍스트 속성 으로 처리합니다. 그룹 멤버십과 함께 IdP의 액세스 토큰에는 API 액세스에 대한 정보가 포함될 수 있습니다. 액세스 토큰은 역할 기반 액세스 제어()를 사용하는 권한 부여 모델에 유용합니다RBAC. 그룹 멤버십 이외의 액세스 토큰 클레임에 의존하는 권한 부여 모델은 스키마 구성에 추가 노력이 필요합니다.

Amazon Cognito 액세스 토큰 매핑

Amazon Cognito 액세스 토큰에는 권한 부여에 사용할 수 있는 클레임이 있습니다.

Amazon Cognito 액세스 토큰의 유용한 클레임
client_id

OIDC 의존 당사자의 클라이언트 애플리케이션의 ID입니다. 클라이언트 ID를 사용하여 Verified Permissions는 권한 부여 요청이 정책 스토어에 허용된 클라이언트에서 온 것인지 확인할 수 있습니다. (M2M) 권한 부여에서 machine-to-machine 요청 시스템은 클라이언트 보안 암호로 요청을 권한 부여하고 권한 부여의 증거로 클라이언트 ID와 범위를 제공합니다.

scope

토큰 전달자의 액세스 권한을 나타내는 OAuth 2.0 범위입니다.

cognito:groups

사용자의 그룹 멤버십입니다. 역할 기반 액세스 제어(RBAC)를 기반으로 하는 권한 부여 모델에서 이 클레임은 정책에서 평가할 수 있는 역할을 나타냅니다.

일시적 클레임

액세스 권한은 아니지만 사용자 풀 사전 토큰 생성 Lambda 트리거에 의해 런타임에 추가되는 클레임입니다. 임시 클레임은 표준 클레임과 유사하지만 tenant 또는 와 같이 표준을 벗어납니다department. 액세스 토큰을 사용자 지정하면 AWS 청구서에 비용이 추가됩니다.

Amazon Cognito 사용자 풀의 액세스 토큰 구조에 대한 자세한 내용은 Amazon Cognito 개발자 안내서의 액세스 토큰 사용을 참조하세요.

Amazon Cognito 액세스 토큰은 Verified Permissions으로 전달될 때 컨텍스트 객체에 매핑됩니다. context.token.attribute_name을 사용하여 액세스 토큰의 속성을 참조할 수 있습니다. 다음 액세스 토큰 예제에는 client_id 및 scope 클레임이 모두 포함됩니다.

{
    "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
    "cognito:groups": [
        "Store-Owner-Role",
        "Customer"
    ],
    "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
    "client_id": "1example23456789",
    "origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
    "event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011",
    "token_use": "access",
    "scope": "MyAPI/mydata.write",
    "auth_time": 1688092966,
    "exp": 1688096566,
    "iat": 1688092966,
    "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
    "username": "alice"
}

다음 예는 Verified Permissions 스키마에 액세스 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 JSON 모드에서 정책 스토어 스키마 편집을(를) 참조하세요.

{
   "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"
         }
      }
   }
}

이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요Amazon Cognito 액세스 토큰 속성을 반영합니다..

OIDC 액세스 토큰 매핑

외부 OIDC 공급자의 대부분의 액세스 토큰은 Amazon Cognito 액세스 토큰과 밀접하게 일치합니다. Verified Permissions로 전달되면 OIDC 액세스 토큰이 컨텍스트 객체에 매핑됩니다. context.token.attribute_name을 사용하여 액세스 토큰의 속성을 참조할 수 있습니다. 다음 예제 OIDC 액세스 토큰에는 예제 기본 클레임이 포함됩니다.

{
    "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"
}

다음 예는 Verified Permissions 스키마에 액세스 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 JSON 모드에서 정책 스토어 스키마 편집을(를) 참조하세요.

{
   "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"
         }
      }
   }
}

이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요OIDC 액세스 토큰 속성을 반영합니다..

Amazon Cognito 콜론으로 구분된 클레임에 대한 대체 표기법

Verified Permissions가 시작된 시점에 Amazon Cognito 토큰에 권장되는 스키마는 이러한 콜론으로 구분된 문자열을 와 같이 주장cognito:groups하고 custom:store 변환하여 . 문자를 계층 구분 기호로 사용하도록 했습니다. 이 형식을 점 표기법이라고 합니다. 예를 들어 에 대한 참조가 정책에 cognito:groups principal.cognito.groups 추가되었습니다. 이 형식을 계속 사용할 수 있지만 괄호 표기법으로 스키마와 정책을 빌드하는 것이 좋습니다. 이 형식에서는 에 대한 참조가 정책에 cognito:groups principal["cognito:groups"] 포함됩니다. Verified Permissions 콘솔에서 사용자 풀 ID 토큰에 대해 자동으로 생성된 스키마는 브래킷 표기법을 사용합니다.

Amazon Cognito 자격 증명 소스에 대해 수동으로 빌드된 스키마 및 정책에서 점 표기법을 계속 사용할 수 있습니다. 다른 유형의 OIDCIdP 에 대해 스키마 : 또는 정책에서 또는 다른 영숫자가 아닌 문자와 함께 점 표기법을 사용할 수 없습니다.

점 표기법에 대한 스키마는 다음 예제와 같이 : 문자의 각 인스턴스를 cognito 또는 custom 초기 구문의 하위 항목으로 중첩합니다.

"CognitoUser": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito": {
            "type": "Record",
            "required": true,
            "attributes": {
               "username": {
                  "type": "String",
                  "required": true
               }
            }
         },
         "custom": {
            "type": "Record",
            "required": true,
            "attributes": {
               "employmentStoreCode": {
                  "type": "String",
                  "required": true
               }
            }
         },
         "email": {
            "type": "String"
         },
         "tenant": {
            "type": "String",
            "required": true
         }
      }
   }
}

이 스키마에 대해 검증하고 점 표기법을 사용하는 정책 예제는 섹션을 참조하세요점 표기법을 사용하여 속성 참조.

스키마 매핑에 대해 알아야 할 사항

속성 매핑은 토큰 유형마다 다릅니다.

액세스 토큰 권한 부여에서 Verified Permissions는 컨텍스트 에 클레임을 매핑합니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 속성에 매핑합니다. Verified Permissions 콘솔에서 생성하는 정책 스토어의 경우 빈 및 샘플 정책 스토어만 ID 소스가 없는 상태로 남게 되며 ID 토큰 권한 부여를 위해 스키마를 사용자 풀 속성으로 채워야 합니다. 액세스 토큰 권한 부여는 그룹 멤버십 클레임이 있는 역할 기반 액세스 제어(RBAC)를 기반으로 하며 정책 스토어 스키마에 다른 클레임을 자동으로 매핑하지 않습니다.

자격 증명 소스 속성은 필요하지 않습니다.

Verified Permissions 콘솔에서 자격 증명 소스를 생성하면 속성이 필수로 표시되지 않습니다. 이렇게 하면 누락된 클레임으로 인해 권한 부여 요청에 검증 오류가 발생하지 않습니다. 필요에 따라 속성을 필수로 설정할 수 있지만 모든 권한 부여 요청에 있어야 합니다.

RBAC 스키마에 속성이 필요하지 않음

자격 증명 소스의 스키마는 자격 증명 소스를 추가할 때 수행하는 엔터티 연결에 따라 달라집니다. 자격 증명 소스는 사용자 엔터티 유형에 클레임 하나를 매핑하고 그룹 엔터티 유형에 클레임 하나를 매핑합니다. 이러한 엔터티 매핑은 자격 증명 소스 구성의 핵심입니다. 이 최소 정보를 사용하여 역할 기반 액세스 제어(RBAC) 모델에서 사용자가 구성원일 수 있는 특정 사용자 및 특정 그룹에 대한 권한 부여 작업을 수행하는 정책을 작성할 수 있습니다. 스키마에 토큰 클레임을 추가하면 정책 스토어의 권한 부여 범위가 확장됩니다. ID 토큰의 사용자 속성에는 속성 기반 액세스 제어(ABAC) 권한 부여에 기여할 수 있는 사용자에 대한 정보가 있습니다. 액세스 토큰의 컨텍스트 속성에는 공급자의 추가 액세스 제어 정보를 제공할 수 있는 OAuth2.0 범위와 같은 정보가 있지만 스키마를 추가로 수정해야 합니다.

Verified Permissions 콘솔의 API 게이트웨이 및 자격 증명 공급자와 안내형 설정으로 설정 옵션은 스키마에 ID 토큰 클레임을 할당합니다. 이는 액세스 토큰 클레임의 경우는 아닙니다. 스키마에 비그룹 액세스 토큰 클레임을 추가하려면 JSON 모드에서 스키마를 편집하고 commonTypes 속성을 추가해야 합니다. 자세한 내용은 액세스 토큰 매핑 단원을 참조하십시오.

OIDC 그룹 클레임은 여러 형식을 지원합니다.

OIDC 공급자를 추가할 때 정책 스토어의 사용자 그룹 멤버십에 매핑하려는 ID 또는 액세스 토큰에서 그룹 클레임의 이름을 선택할 수 있습니다. 확인된 권한은 그룹 클레임을 다음 형식으로 인식합니다.

  1. 공백이 없는 문자열: "groups": "MyGroup"

  2. 공백으로 구분된 목록: "groups": "MyGroup1 MyGroup2 MyGroup3". 각 문자열은 그룹입니다.

  3. JSON (쉼표로 구분) 목록: "groups": ["MyGroup1", "MyGroup2", "MyGroup3"]

참고

Verified Permissions는 공백으로 구분된 그룹 클레임의 각 문자열을 별도의 그룹으로 해석합니다. 공백 문자가 있는 그룹 이름을 단일 그룹으로 해석하려면 클레임의 공백을 바꾸거나 제거합니다. 예를 들어 My Group라는 이름의 그룹을 포맷합니다MyGroup.

토큰 유형 선택

정책 스토어가 자격 증명 소스에서 작동하는 방식은 자격 증명 소스 구성의 키 결정, 즉 ID 또는 액세스 토큰을 처리할지에 따라 달라집니다. Amazon Cognito 자격 증명 공급자를 사용하면 API연결된 정책 스토어를 생성할 때 토큰 유형을 선택할 수 있습니다. API연결된 정책 스토어를 생성할 때 ID 또는 액세스 토큰에 대한 권한 부여를 설정할지 여부를 선택해야 합니다. 이 정보는 Verified Permissions가 정책 스토어에 적용하는 스키마 속성과 API 게이트웨이 에 대한 Lambda 권한 부여자의 구문에 영향을 미칩니다API. OIDC 공급자를 사용하면 자격 증명 소스를 추가할 때 토큰 유형을 선택해야 합니다. ID 또는 액세스 토큰을 선택할 수 있으며 선택하지 않은 토큰 유형은 정책 스토어에서 처리되지 않습니다. 특히 ID 토큰 클레임을 Verified Permissions 콘솔의 속성에 자동으로 매핑하여 혜택을 받으려면 자격 증명 소스를 생성하기 전에 처리하려는 토큰 유형에 대해 미리 결정합니다. 토큰 유형을 변경하려면 정책 및 스키마를 리팩터링하는 데 상당한 노력이 필요합니다. 다음 주제에서는 정책 스토어에서 ID 및 액세스 토큰을 사용하는 방법을 설명합니다.

Cedar 구문 분석기에는 일부 문자에 대한 대괄호가 필요합니다.

정책은 일반적으로 와 같은 형식의 스키마 속성을 참조합니다principal.username. 토큰 클레임 이름에 표시될 수 / 있는 :, .또는 와 같은 영숫자가 아닌 대부분의 문자의 경우 Verified Permissions는 principal.cognito:username 또는 와 같은 조건 값을 구문 분석할 수 없습니다context.ip-address. 대신 이러한 조건의 형식을 context["ip-address"]각각 principal["cognito:username"] 또는 형식의 대괄호 표기법으로 지정해야 합니다. 밑줄 문자_는 클레임 이름에 유효한 문자이며 이 요구 사항에 대한 유일한 영숫자가 아닌 예외입니다.

이 유형의 보안 주체 속성에 대한 부분 예제 스키마는 다음과 같습니다.

"User": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito:username": {
            "type": "String",
            "required": true
         },
         "custom:employmentStoreCode": {
            "type": "String",
            "required": true,
         },
         "email": {
            "type": "String",
            "required": false
         }
      }
   }
}

이 유형의 컨텍스트 속성에 대한 부분 예제 스키마는 다음과 같습니다.

"GetOrder": {
   "memberOf": [],
   "appliesTo": {
      "resourceTypes": [
         "Order"
      ],
      "context": {
         "type": "Record",
         "attributes": {
            "ip-address": {
               "required": false,
               "type": "String"
            }
		 }
	  },
      "principalTypes": [
         "User"
      ]
   }
}

이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요브래킷 표기법을 사용하여 토큰 속성 참조.