스키마에 OIDC 토큰 매핑

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

사용 설명서의이 섹션에는 다음 정보가 포함되어 있습니다.

정책 스토어 스키마에 속성을 자동으로 채울 수 있는 경우
자격 증명 소스에 대한 스키마를 수동으로 빌드하는 방법

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

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

스키마에 ID 토큰 매핑

Verified Permissions는 ID 토큰 클레임을 사용자의 이름 및 제목, 그룹 멤버십, 연락처 정보 등 사용자의 속성으로 처리합니다. ID 토큰은 속성 기반 액세스 제어(ABAC) 권한 부여 모델에서 가장 유용합니다. Verified Permissions가 요청자를 기반으로 리소스에 대한 액세스를 분석하도록 하려면 자격 증명 소스의 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)를 사용하는 권한 부여 모델에서 유용합니다. 그룹 멤버십 이외의 액세스 토큰 클레임에 의존하는 권한 부여 모델은 스키마 구성에 추가 노력이 필요합니다.

외부 OIDC 공급자의 대부분의 액세스 토큰은 Amazon Cognito 액세스 토큰과 밀접하게 일치합니다. OIDC 액세스 토큰은 Verified Permissions에 전달될 때 컨텍스트 객체에 매핑됩니다. 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 스키마에 액세스 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 정책 스토어 스키마 편집을(를) 참조하세요.


{
   "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 액세스 토큰 속성을 반영합니다..

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

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

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

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

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

RBAC는 스키마에 속성이 필요하지 않습니다.

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

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

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

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

공백이 없는 문자열: "groups": "MyGroup"
공백으로 구분된 목록: "groups": "MyGroup1 MyGroup2 MyGroup3". 각 문자열은 그룹입니다.
JSON(쉼표로 구분) 목록: "groups": ["MyGroup1", "MyGroup2", "MyGroup3"]

참고

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

토큰 유형 선택

정책 스토어가 자격 증명 소스와 작동하는 방식은 ID 또는 액세스 토큰을 처리할지 여부와 같은 자격 증명 소스 구성의 주요 결정에 따라 달라집니다. 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"
      ]
   }
}

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

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

자격 증명 소스 편집

클라이언트 및 대상 검증