기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 자격 증명 소스 및 토큰으로 애플리케이션 보호
Amazon Verified Permissions에서 외부 ID 제공업체(IdP)를 *나타내는 ID 소스를* 생성하여 애플리케이션을 빠르게 보호합니다. 자격 증명 소스는 정책 스토어와 신뢰 관계가 있는 IdP로 인증된 사용자의 정보를 제공합니다. 애플리케이션이 자격 증명 소스의 토큰으로 권한 부여를 요청할 때 정책 스토어는 사용자 속성 및 액세스 권한에서 권한 부여를 결정할 수 있습니다. Amazon Cognito 사용자 풀 또는 사용자 지정 OpenID Connect(OIDC) IdP를 ID 소스로 추가할 수 있습니다.
Verified Permissions와 함께 [OpenID Connect(OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) ID 제공업체(IdPs)를 사용할 수 있습니다. 애플리케이션은 OIDC 준수 자격 증명 공급자가 생성한 JSON 웹 토큰(JWTs)을 사용하여 권한 부여 요청을 생성할 수 있습니다. 토큰의 사용자 자격 증명은 보안 주체 ID에 매핑됩니다. ID 토큰을 사용하면 Verified Permissions는 속성 클레임을 보안 주체 속성에 매핑합니다. 액세스 토큰을 사용하면 이러한 클레임이 [컨텍스트](context.md)에 매핑됩니다. 두 토큰 유형 모두와 같은 클레임을 보안 주체 그룹에 매핑하고 역할 기반 액세스 제어(RBAC)`groups`를 평가하는 정책을 구축할 수 있습니다.
**참고**
Verified Permissions는 IdP 토큰의 정보를 기반으로 권한 부여를 결정하지만 어떤 식으로든 IdP와 직접 상호 작용하지 않습니다.
Amazon Cognito 사용자 풀 또는 OIDC 자격 증명 공급자를 사용하여 Amazon API Gateway REST APIs에 대한 권한 부여 로직을 구축하는 step-by-step 연습은 *AWS 보안 블로그*의 [Authorize API Gateway APIs using Amazon Verified Permissions with Amazon Cognito or bring your own identity provider](https://aws.amazon.com/blogs/security/authorize-api-gateway-apis-using-amazon-verified-permissions-and-amazon-cognito/)를 참조하세요.
**Topics**
+ [올바른 자격 증명 공급자 선택](#choosing-identity-source)
+ [Amazon Cognito 자격 증명 소스 작업](identity-sources-cognito.md)
+ [OIDC 자격 증명 소스 작업](identity-sources-oidc.md)
## 올바른 자격 증명 공급자 선택
Verified Permissions는 다양한 IdPs에서 작동하지만 애플리케이션에서 사용할 IdP를 결정할 때는 다음 사항을 고려하세요.
다음과 같은 Amazon Cognito 경우에 사용합니다.
+ 기존 자격 증명 인프라 없이 새 애플리케이션을 구축하는 경우
+ 기본 보안 기능이 있는 원하는 AWS관리형 사용자 풀
+ 소셜 자격 증명 공급자 통합이 필요합니다.
+ 간소화된 토큰 관리를 원하는 경우
다음과 같은 경우 OIDC 공급자를 사용합니다.
+ 기존 자격 증명 인프라(Auth0, Okta, Azure AD)가 있는 경우
+ 중앙 집중식 사용자 관리를 유지해야 함
+ 특정 IdPs
# Amazon Cognito 자격 증명 소스 작업
Verified Permissions는 Amazon Cognito 사용자 풀과 밀접하게 작동합니다. Amazon Cognito JWTs 예측 가능한 구조를 갖습니다. Verified Permissions는이 구조를 인식하고 포함된 정보를 최대한 활용합니다. 예를 들어 ID 토큰 또는 액세스 토큰을 사용하여 역할 기반 액세스 제어(RBAC) 권한 부여 모델을 구현할 수 있습니다.
새 Amazon Cognito 사용자 풀 자격 증명 소스에는 다음 정보가 필요합니다.
+ AWS 리전.
+ 사용자 풀 ID입니다.
+ 자격 증명 소스와 연결할 보안 주체 엔터티 유형입니다. 예: `MyCorp::User`.
+ 자격 증명 소스와 연결할 보안 주체 그룹 엔터티 유형입니다. 예: `MyCorp::UserGroup`.
+ 가 정책 스토어에 요청할 수 있도록 승인하려는 사용자 풀의 클라이언트 IDs입니다.
Verified Permissions는 동일한의 Amazon Cognito 사용자 풀에서만 작동하므로 다른 계정에서 자격 증명 소스를 지정할 AWS 계정수 없습니다. Verified Permissions는 사용자 풀 보안 주체를 기반으로 하는 정책에서 참조해야 하는 자격 증명 소스 식별자인 *엔터티 접두사를*와 같은 사용자 풀의 ID로 설정합니다`us-west-2_EXAMPLE`. 이 경우 ID가 인 사용자 풀의 사용자를 참조`a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`합니다. `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`
사용자 풀 토큰 *클레임*에는 속성, 범위, 그룹, 클라이언트 IDs 및 사용자 지정 데이터가 포함될 수 있습니다. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)는 Verified Permissions에서 권한 부여 결정에 기여할 수 있는 다양한 정보를 포함할 수 있습니다. 다음이 포함됩니다.
1. `cognito:` 접두사가 있는 사용자 이름 및 그룹 클레임
1. 를 사용한 사용자 [지정 사용자 속성](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) `custom: prefix`
1. 런타임에 추가된 사용자 지정 클레임
1. `sub` 및와 같은 OIDC 표준 클레임 `email`
이러한 클레임과 이를 관리하는 방법은의 Verified Permissions 정책에서 자세히 다룹니다[스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md).
**중요**
만료되기 전에 Amazon Cognito 토큰을 취소할 수 있지만 JWTs는 서명 및 유효성이 포함된 상태 비저장 리소스로 간주됩니다. [JSON 웹 토큰 RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519)를 준수하는 서비스는 원격으로 토큰을 검증할 것으로 예상되며 발행자를 통해 토큰을 검증할 필요는 없습니다. 즉, Verified Permissions가 나중에 삭제된 사용자에 대해 취소되거나 발급된 토큰을 기반으로 액세스 권한을 부여할 수 있습니다. 이러한 위험을 줄이려면 유효 기간이 가장 짧은 토큰을 생성하고 사용자 세션을 계속할 수 있는 권한을 제거하려는 경우 새로 고침 토큰을 취소하는 것이 좋습니다. 자세한 내용은 [토큰 해지로 사용자 세션 종료](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)를 참조하세요.
다음 예제에서는 보안 주체와 연결된 일부 Amazon Cognito 사용자 풀 클레임을 참조하는 정책을 생성하는 방법을 보여줍니다.
```
permit(
principal,
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
)
when {
principal["cognito:username"]) == "alice" &&
principal["custom:department"]) == "Finance"
};
```
다음 예제에서는 Cognito 사용자 풀의 사용자인 보안 주체를 참조하는 정책을 생성하는 방법을 보여줍니다. 보안 주체 ID는 형식을 취합니다`"|"`.
```
permit(
principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
);
```
Verified Permissions의 사용자 풀 자격 증명 소스에 대한 Cedar 정책은 영숫자 및 밑줄() 이외의 문자가 포함된 클레임 이름에 특수 구문을 사용합니다`_`. 여기에는 `cognito:username` 및와 같은 `:` 문자가 포함된 사용자 풀 접두사 클레임이 포함됩니다`custom:department`. `cognito:username` 또는 `custom:department` 클레임을 참조하는 정책 조건을 작성하려면 `principal["custom:department"]`각각 `principal["cognito:username"]` 및 로 작성합니다.
**참고**
토큰에 `custom:` 접두사가 `cognito:` 또는 이고 클레임 이름이 리터럴 값 `cognito` 또는 인 클레임이 포함된 경우 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)을 사용한 `custom`권한 부여 요청은와 함께 실패합니다`ValidationException`.
클레임 매핑에 대한 자세한 내용은 섹션을 참조하세요[스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md). Amazon Cognito 사용자 권한 부여에 대한 자세한 내용은 [Amazon Cognito 개발자 안내서의 Amazon Verified Permissions 권한 부여](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)를 참조하세요. *Amazon Cognito *
**Topics**
+ [Amazon Verified Permissions Amazon Cognito 자격 증명 소스 생성](cognito-create.md)
+ [Amazon Verified Permissions 자격 Amazon Cognito 증명 소스 편집](cognito-edit.md)
+ [스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md)
+ [에 대한 클라이언트 및 대상 검증 Amazon Cognito](cognito-validation.md)
# Amazon Verified Permissions Amazon Cognito 자격 증명 소스 생성
다음 절차에서는 기존 정책 스토어에 자격 증명 소스를 추가합니다.
Verified Permissions 콘솔에서 [새 정책 스토어](policy-stores-create.md)를 생성할 때 자격 증명 소스를 생성할 수도 있습니다. 이 프로세스에서는 자격 증명 소스 토큰의 클레임을 개체 속성으로 자동으로 가져올 수 있습니다. **안내 설정** 또는 ** API Gateway 설정 및 자격 증명 공급자** 옵션을 선택합니다. 이러한 옵션은 초기 정책도 생성합니다.
**참고**
정책 스토어를 생성하기 전에는 왼쪽 탐색 창에서 **자격 증명 소스**를 사용할 수 없습니다. 생성한 자격 증명 소스는 현재 정책 스토어와 연결됩니다.
에서 [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)를 사용하여 자격 증명 소스를 생성 AWS CLI 하거나 Verified Permissions API에서 [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)를 사용하여 자격 증명 소스를 생성할 때 보안 주체 엔터티 유형을 제외할 수 있습니다. 그러나 빈 엔터티 유형은 엔터티 유형이 인 ID 소스를 생성합니다`AWS::Cognito`. 이 엔터티 이름은 정책 스토어 스키마와 호환되지 않습니다. 자격 증명을 정책 스토어 스키마와 통합하려면 보안 주체 Amazon Cognito 엔터티 유형을 지원되는 정책 스토어 엔터티로 설정해야 합니다.
------
#### [ AWS Management Console ]
**Amazon Cognito 사용자 풀 자격 증명 소스를 생성하려면**
1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions/)을 엽니다. 정책 스토어를 선택합니다.
1. 왼쪽 탐색 창에서 **자격 증명 소스**를 선택합니다.
1. **자격 증명 소스 생성**을 선택합니다.
1. **Cognito 사용자 풀 세부 정보**에서를 선택하고 자격 증명 소스의 **사용자 풀 ID**를 AWS 리전 입력합니다.
1. **보안 주체 구성**의 보안 **주체 유형**에서이 소스의 보안 주체에 대한 엔터티 유형을 선택합니다. 연결된 Amazon Cognito 사용자 풀의 자격 증명은 선택한 보안 주체 유형에 매핑됩니다.
1. 사용자 풀 `cognito:groups` 클레임을 매핑하려면 **그룹 구성**에서 **Cognito 그룹 사용을** 선택합니다. 보안 주체 유형의 상위인 엔터티 유형을 선택합니다.
1. **클라이언트 애플리케이션 검증**에서 클라이언트 애플리케이션 IDs 검증할지 여부를 선택합니다.
+ 클라이언트 애플리케이션 ID를 검증하려면 **클라이언트 애플리케이션 ID가 일치하는 토큰만 수락**을 선택합니다. 검증할 각 클라이언트 애플리케이션 ID에 대해 **새 클라이언트 애플리케이션 ID 추가**를 선택합니다. 추가된 클라이언트 애플리케이션 ID를 제거하려면 클라이언트 애플리케이션 ID 옆의 **제거**를 선택합니다.
+ 클라이언트 애플리케이션 ID를 검증하지 않으려면 **클라이언트 애플리케이션 ID 검증 안 함**을 선택합니다.
1. **자격 증명 소스 생성**을 선택합니다.
1. (선택 사항) 정책 스토어에 스키마가 있는 경우 Cedar 정책의 자격 증명 또는 액세스 토큰에서 추출한 속성을 참조하려면 먼저 Cedar가 자격 증명 소스가 생성하는 보안 주체 유형을 인식하도록 스키마를 업데이트해야 합니다. 스키마에 추가되는 항목에는 Cedar 정책에서 참조하려는 속성이 포함되어야 합니다. Amazon Cognito 토큰 속성을 Cedar 보안 주체 속성에 매핑하는 방법에 대한 자세한 내용은 섹션을 참조하세요[스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md).
**참고**
[API 연결 정책 저장소](policy-stores-api-userpool.md)를 생성하거나 정책 저장소를 생성할 때 ** API Gateway 및 자격 증명 공급자로 설정을** 사용하는 경우 Verified Permissions는 사용자 풀에서 사용자 속성을 쿼리하고 보안 주체 유형이 사용자 풀 속성으로 채워지는 스키마를 생성합니다.
1. 토큰의 정보를 사용하여 권한 부여 결정을 내리는 정책을 생성합니다. 자세한 내용은 [Amazon Verified Permissions 정적 정책 생성](policies-create.md) 단원을 참조하십시오.
이제 자격 증명 소스를 생성하고, 스키마를 업데이트하고, 정책을 생성했으므로 `IsAuthorizedWithToken`를 사용하여 Verified Permissions가 권한 부여 결정을 내리도록 합니다. 자세한 내용은 *Amazon Verified Permissions API 참조 안내서*의 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)을 참조하세요.
------
#### [ AWS CLI ]
**Amazon Cognito 사용자 풀 자격 증명 소스를 생성하려면**
[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html) 작업을 사용하여 자격 증명 소스를 생성할 수 있습니다. 다음 예제에서는 Amazon Cognito 사용자 풀에서 인증된 자격 증명에 액세스할 수 있는 자격 증명 소스를 생성합니다.
1. `create-identity-source` 명령의 `--configuration` 파라미터에서 사용할 Amazon Cognito 사용자 풀에 대한 다음 세부 정보가 포함된 `config.txt` 파일을 생성합니다.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 다음 명령을 실행하여 Amazon Cognito 자격 증명 소스를 생성합니다.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (선택 사항) 정책 스토어에 스키마가 있는 경우 Cedar 정책의 자격 증명 또는 액세스 토큰에서 추출한 속성을 참조하려면 먼저 Cedar가 자격 증명 소스가 생성하는 보안 주체 유형을 인식하도록 스키마를 업데이트해야 합니다. 스키마에 추가되는 항목에는 Cedar 정책에서 참조하려는 속성이 포함되어야 합니다. Amazon Cognito 토큰 속성을 Cedar 보안 주체 속성에 매핑하는 방법에 대한 자세한 내용은 섹션을 참조하세요[스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md).
**참고**
[API 연결 정책 저장소](policy-stores-api-userpool.md)를 생성하거나 정책 저장소를 생성할 때 ** API Gateway 및 자격 증명 공급자로 설정을** 사용하는 경우 Verified Permissions는 사용자 풀에서 사용자 속성을 쿼리하고 보안 주체 유형이 사용자 풀 속성으로 채워지는 스키마를 생성합니다.
1. 토큰의 정보를 사용하여 권한 부여 결정을 내리는 정책을 생성합니다. 자세한 내용은 [Amazon Verified Permissions 정적 정책 생성](policies-create.md) 단원을 참조하십시오.
이제 자격 증명 소스를 생성하고, 스키마를 업데이트하고, 정책을 생성했으므로 `IsAuthorizedWithToken`를 사용하여 Verified Permissions가 권한 부여 결정을 내리도록 합니다. 자세한 내용은 *Amazon Verified Permissions API 참조 안내서*의 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)을 참조하세요.
------
Verified Permissions에서 인증된 사용자를 위한 Amazon Cognito 액세스 및 자격 증명 토큰을 사용하는 방법에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [Amazon Verified Permissions를 통한 권한 부여](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)를 참조하세요.
# Amazon Verified Permissions 자격 Amazon Cognito 증명 소스 편집
자격 증명 소스를 생성한 후 일부 파라미터를 편집할 수 있습니다. 자격 증명 소스 유형은 변경할 수 없으며 자격 증명 소스를 삭제하고에서 OIDC 또는 OIDC Amazon Cognito 로 전환할 새 소스를 생성해야 합니다 Amazon Cognito. 정책 스토어 스키마가 자격 증명 소스 속성과 일치하는 경우 자격 증명 소스에 대한 변경 사항을 반영하도록 스키마를 별도로 업데이트해야 합니다.
------
#### [ AWS Management Console ]
**자격 Amazon Cognito 증명 소스를 업데이트하려면**
1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions/)을 엽니다. 정책 스토어를 선택합니다.
1. 왼쪽 탐색 창에서 **자격 증명 소스**를 선택합니다.
1. 편집할 자격 증명 소스의 ID를 선택합니다.
1. **편집**을 선택합니다.
1. **Cognito 사용자 풀 세부 정보**에서를 선택하고 자격 증명 소스의 **사용자 풀 ID**를 AWS 리전 입력합니다.
1. **보안 주체 세부 정보**에서 자격 증명 소스의 보안 **주체 유형을** 업데이트할 수 있습니다. 연결된 Amazon Cognito 사용자 풀의 자격 증명은 선택한 보안 주체 유형에 매핑됩니다.
1. 사용자 풀 `cognito:groups` 클레임을 매핑하려면 그룹 **구성**에서 **Cognito 그룹 사용을** 선택합니다. 보안 주체 유형의 상위인 엔터티 유형을 선택합니다.
1. **클라이언트 애플리케이션 검증**에서 클라이언트 애플리케이션 IDs 검증할지 여부를 선택합니다.
+ 클라이언트 애플리케이션 ID를 검증하려면 **클라이언트 애플리케이션 ID가 일치하는 토큰만 수락**을 선택합니다. 검증할 각 클라이언트 애플리케이션 ID에 대해 **새 클라이언트 애플리케이션 ID 추가**를 선택합니다. 추가된 클라이언트 애플리케이션 ID를 제거하려면 클라이언트 애플리케이션 ID 옆의 **제거**를 선택합니다.
+ 클라이언트 애플리케이션 ID를 검증하지 않으려면 **클라이언트 애플리케이션 ID 검증 안 함**을 선택합니다.
1. **변경 사항 저장**을 선택합니다.
1. 자격 증명 소스의 보안 주체 유형을 변경한 경우 업데이트된 보안 주체 유형을 올바르게 반영하도록 스키마를 업데이트해야 합니다.
자격 증명 소스 옆에 있는 라디오 버튼을 선택한 다음 **자격 증명 소스 삭제**를 선택하여 자격 증명 소스를 삭제할 수 있습니다. 텍스트 상자에 `delete`를 입력한 다음 **자격 증명 소스 삭제**를 선택하여 자격 증명 소스 삭제를 확인합니다.
------
#### [ AWS CLI ]
**자격 Amazon Cognito 증명 소스를 업데이트하려면**
[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html) 작업을 사용하여 자격 증명 소스를 업데이트할 수 있습니다. 다음 예시에서는 다른 Amazon Cognito 사용자 풀을 사용하도록 지정된 자격 증명 소스를 업데이트합니다.
1. `update-identity-source` 명령의 `--configuration` 파라미터에서 사용할 Amazon Cognito 사용자 풀에 대한 다음 세부 정보가 포함된 `config.txt` 파일을 생성합니다.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 다음 명령을 실행하여 Amazon Cognito 자격 증명 소스를 업데이트합니다.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**참고**
자격 증명 소스의 보안 주체 유형을 변경하는 경우 업데이트된 보안 주체 유형을 올바르게 반영하도록 스키마를 업데이트해야 합니다.
------
# 스키마에 Amazon Cognito 토큰 매핑
정책 스토어에 자격 증명 소스를 추가하고 정책 스토어 스키마에 공급자 클레임 또는 토큰을 매핑하려고 할 수 있습니다. [가이드 설정을](policy-stores-create.md) 사용하여 자격 증명 소스로 정책 스토어를 생성하거나 정책 스토어가 생성된 후 스키마를 수동으로 업데이트하여이 프로세스를 자동화할 수 있습니다. 토큰을 스키마에 매핑한 후에는 토큰을 참조하는 정책을 생성할 수 있습니다.
사용 설명서의이 섹션에는 다음 정보가 포함되어 있습니다.
+ 정책 스토어 스키마에 속성을 자동으로 채울 수 있는 경우
+ Verified Permissions 정책에서 Amazon Cognito 토큰 클레임을 사용하는 방법
+ 자격 증명 소스에 대한 스키마를 수동으로 빌드하는 방법
[API 연결 정책 스토어](policy-stores-api-userpool.md) 및 [안내형 설정을](policy-stores-create.md) 통해 생성된 자격 증명 소스가 있는 정책 스토어는 스키마에 자격 증명(ID) 토큰 속성을 수동으로 매핑할 필요가 없습니다. Verified Permissions에 사용자 풀의 속성을 제공하고 사용자 속성으로 채워진 스키마를 생성할 수 있습니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 엔터티의 속성에 매핑합니다. 다음 조건에서 Amazon Cognito 토큰을 스키마에 수동으로 매핑해야 할 수 있습니다.
+ 샘플에서 빈 정책 저장소 또는 정책 저장소를 생성했습니다.
+ 액세스 토큰 사용을 역할 기반 액세스 제어(RBAC) 이상으로 확장하려고 합니다.
+ Verified Permissions REST API, AWS SDK 또는를 사용하여 정책 스토어를 생성합니다 AWS CDK.
Verified Permissions 정책 스토어에서를 자격 증명 소스 Amazon Cognito 로 사용하려면 스키마에 공급자 속성이 있어야 합니다. 스키마는 고정되며 공급자 토큰이 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) 또는 [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html) API 요청에서 생성하는 엔터티와 일치해야 합니다. ID 토큰의 공급자 정보에서 스키마를 자동으로 채우는 방식으로 정책 스토어를 생성한 경우 정책을 작성할 준비가 된 것입니다. 자격 증명 소스에 대한 스키마 없이 정책 스토어를 생성하는 경우 API 요청을 사용하여 생성된 엔터티와 일치하는 스키마에 공급자 속성을 추가해야 합니다. 그런 다음 공급자 토큰의 속성을 사용하여 정책을 작성할 수 있습니다.
Verified Permissions에서 인증된 사용자의 Amazon Cognito ID 및 액세스 토큰 사용에 대한 자세한 내용은 Amazon *Amazon Cognito 개발자 안내서의 Amazon* [Verified Permissions 권한 부여](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)를 참조하세요.
**Topics**
+ [스키마에 ID 토큰 매핑](#cognito-map-id-token)
+ [액세스 토큰 매핑](#cognito-map-access-token)
+ [Amazon Cognito 콜론으로 구분된 클레임에 대한 대체 표기법](#cognito-colon-claims)
+ [스키마 매핑에 대해 알아야 할 사항](#cognito-map-token-to-schema-things-to-know)
## 스키마에 ID 토큰 매핑
Verified Permissions는 ID 토큰 클레임을 사용자의 이름 및 제목, 그룹 멤버십, 연락처 정보 등 사용자의 속성으로 처리합니다. ID 토큰은 *속성 기반 액세스 제어*(ABAC) 권한 부여 모델에서 가장 유용합니다. Verified Permissions가 요청자를 기반으로 리소스에 대한 액세스를 분석하도록 하려면 자격 증명 소스의 ID 토큰을 선택합니다.
Amazon Cognito ID 토큰은 대부분의 [OIDC 신뢰 당사자 라이브러리](https://openid.net/developers/certified-openid-connect-implementations/)에서 작동합니다. 추가 클레임으로 OIDC의 기능을 확장합니다. 애플리케이션은 Amazon Cognito 사용자 풀 인증 API 작업 또는 사용자 풀 호스팅 UI를 사용하여 사용자를 인증할 수 있습니다. 자세한 내용은 *Amazon Cognito 개발자 안내서*[의 API 및 엔드포인트 사용을](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html) 참조하세요.Amazon Cognito ID 토큰의 유용한 클레임
*`cognito:username` 및 `preferred_username`*
사용자 이름의 변형입니다.
*`sub`*
사용자의 고유 사용자 식별자(UUID)
*`custom:` 접두사가 있는 클레임*
와 같은 사용자 지정 사용자 풀 속성의 접두사입니다`custom:employmentStoreCode`.
*표준 클레임*
`email` 및와 같은 표준 OIDC 클레임`phone_number`. 자세한 내용은 *오류 세트 2를 통합하는 OpenID Connect Core 1.0*의 [표준 클레임](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)을 참조하세요.
*`cognito:groups`*
사용자의 그룹 멤버십입니다. 역할 기반 액세스 제어(RBAC)를 기반으로 하는 권한 부여 모델에서이 클레임은 정책에서 평가할 수 있는 역할을 제공합니다.
*일시적 클레임*
사용자의 속성은 아니지만 사용자 풀 [사전 토큰 생성 Lambda 트리거](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html)에 의해 런타임에 추가되는 클레임입니다. 일시적 클레임은 표준 클레임과 유사하지만 `tenant` 또는와 같이 표준을 벗어납니다`department`.
`:` 구분자가 있는 Amazon Cognito 속성을 참조하는 정책에서 형식의 속성을 참조합니다`principal["cognito:username"]`. 역할 클레임`cognito:groups`은이 규칙에 대한 예외입니다. Verified Permissions는이 클레임의 내용을 사용자 엔터티의 상위 엔터티에 매핑합니다.
Amazon Cognito 사용자 풀의 ID 토큰 구조에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*[의 ID 토큰 사용을](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) 참조하세요.
다음 예제 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 스키마에 자격 증명 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 [정책 스토어 스키마 편집](schema-edit.md)을(를) 참조하세요. 자격 증명 소스 구성에서 보안 주체 유형 `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 토큰 속성을 반영합니다.](policies-examples.md#policies-examples-cognito-id).
## 액세스 토큰 매핑
Verified Permissions는 그룹 클레임 이외의 액세스 토큰 클레임을 작업의 속성 또는 *컨텍스트 속성*으로 처리합니다. 그룹 멤버십과 함께 IdP의 액세스 토큰에는 API 액세스에 대한 정보가 포함될 수 있습니다. 액세스 토큰은 역할 기반 액세스 제어(RBAC)를 사용하는 권한 부여 모델에 유용합니다. 그룹 멤버십 이외의 액세스 토큰 클레임에 의존하는 권한 부여 모델은 스키마 구성에 추가 노력이 필요합니다.
Amazon Cognito 액세스 토큰에는 권한 부여에 사용할 수 있는 클레임이 있습니다.Amazon Cognito 액세스 토큰의 유용한 클레임
*`client_id`*
OIDC 신뢰 당사자에 대한 클라이언트 애플리케이션의 ID입니다. 클라이언트 ID를 사용하여 Verified Permissions는 권한 부여 요청이 정책 스토어에 허용된 클라이언트에서 온 것인지 확인할 수 있습니다. M2M(Machinemachine-to-machine) 권한 부여에서 요청 시스템은 클라이언트 보안 암호로 요청을 승인하고 클라이언트 ID와 범위를 권한 부여의 증거로 제공합니다.
*`scope`*
토큰 보유자의 액세스 권한을 나타내는 [OAuth 2.0 범위](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3)입니다.
*`cognito:groups`*
사용자의 그룹 멤버십입니다. 역할 기반 액세스 제어(RBAC)를 기반으로 하는 권한 부여 모델에서이 클레임은 정책에서 평가할 수 있는 역할을 제공합니다.
*일시적 클레임*
액세스 권한은 아니지만 사용자 풀 [사전 토큰 생성 Lambda 트리거](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html)에 의해 런타임에 추가되는 클레임입니다. 일시적 클레임은 표준 클레임과 유사하지만 `tenant` 또는와 같이 표준을 벗어납니다`department`. 액세스 토큰을 사용자 지정하면 AWS 청구서에 비용이 추가됩니다.
Amazon Cognito 사용자 풀의 액세스 토큰 구조에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*[의 액세스 토큰 사용을](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) 참조하세요.
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 스키마에 액세스 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 [정책 스토어 스키마 편집](schema-edit.md)을(를) 참조하세요.
```
{
"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 액세스 토큰 속성을 반영합니다.](policies-examples.md#policies-examples-cognito-access).
## Amazon Cognito 콜론으로 구분된 클레임에 대한 대체 표기법
Verified Permissions가 시작된 시점에 `cognito:groups`와 같은 Amazon Cognito 토큰 클레임에 권장되는 스키마는 `.` 문자를 계층 구분 기호로 사용하도록 콜론으로 구분된 문자열을 `custom:store` 변환했습니다. 이 형식을 *점 표기법*이라고 합니다. 예를 들어에 대한 참조가 정책에 `cognito:groups` `principal.cognito.groups` 추가되었습니다. 이 형식을 계속 사용할 수 있지만 대[괄호 표기법으로](#cognito-map-token-to-schema-things-to-know) 스키마와 정책을 빌드하는 것이 좋습니다. 이 형식에서는에 대한 참조가 정책에 `cognito:groups` `principal["cognito:groups"]` 포함됩니다. Verified Permissions 콘솔에서 사용자 풀 ID 토큰에 대해 자동으로 생성된 스키마는 대괄호 표기법을 사용합니다.
자격 증명 소스에 대해 Amazon Cognito 수동으로 빌드된 스키마 및 정책에서 점 표기법을 계속 사용할 수 있습니다. 다른 유형의 OIDC IdP에 대해 스키마 `:` 또는 정책에 또는 다른 영숫자가 아닌 문자와 함께 점 표기법을 사용할 수 없습니다.
점 표기법에 대한 스키마는 다음 예제와 같이 `:` 캐릭터의 각 인스턴스를 `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
}
}
}
}
```
이 스키마에 대해 검증하고 점 표기법을 사용하는 정책 예제는 섹션을 참조하세요[점 표기법을 사용하여 속성 참조](policies-examples.md#policies-examples-dot).
## 스키마 매핑에 대해 알아야 할 사항
**속성 매핑은 토큰 유형마다 다릅니다.**
액세스 토큰 권한 부여에서 Verified Permissions는 클레임을 [컨텍스트](context.md)에 매핑합니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 속성에 매핑합니다. Verified Permissions 콘솔에서 생성하는 정책 스토어의 경우 **빈** 정책 스토어와 **샘플** 정책 스토어만 자격 증명 소스가 없어지고 ID 토큰 권한 부여를 위해 사용자 풀 속성으로 스키마를 채워야 합니다. 액세스 토큰 권한 부여는 그룹 멤버십 클레임이 있는 역할 기반 액세스 제어(RBAC)를 기반으로 하며 다른 클레임을 정책 스토어 스키마에 자동으로 매핑하지 않습니다.
**자격 증명 소스 속성은 필요하지 않습니다.**
Verified Permissions 콘솔에서 자격 증명 소스를 생성하면 속성이 필수로 표시되지 않습니다. 이렇게 하면 누락된 클레임으로 인해 권한 부여 요청에 검증 오류가 발생하지 않습니다. 필요에 따라 속성을 필수로 설정할 수 있지만 모든 권한 부여 요청에 있어야 합니다.
**RBAC는 스키마에 속성이 필요하지 않습니다.**
자격 증명 소스의 스키마는 자격 증명 소스를 추가할 때 수행하는 엔터티 연결에 따라 달라집니다. 자격 증명 소스는 하나의 클레임을 사용자 엔터티 유형에 매핑하고 하나의 클레임을 그룹 엔터티 유형에 매핑합니다. 이러한 엔터티 매핑은 자격 증명 소스 구성의 핵심입니다. 이 최소 정보를 사용하여 역할 기반 액세스 제어(RBAC) 모델에서 특정 사용자 및 사용자가 구성원일 수 있는 특정 그룹에 대한 권한 부여 작업을 수행하는 정책을 작성할 수 있습니다. 스키마에 토큰 클레임을 추가하면 정책 스토어의 권한 부여 범위가 확장됩니다. ID 토큰의 사용자 속성에는 속성 기반 액세스 제어(ABAC) 권한 부여에 기여할 수 있는 사용자에 대한 정보가 있습니다. 액세스 토큰의 컨텍스트 속성에는 공급자의 추가 액세스 제어 정보를 제공할 수 있지만 추가 스키마 수정이 필요한 OAuth 2.0 범위와 같은 정보가 있습니다.
Verified Permissions 콘솔의 **API Gateway 및 자격 증명 공급자**로 **설정 및 안내 설정** 옵션은 스키마에 ID 토큰 클레임을 할당합니다. 액세스 토큰 클레임의 경우에는 그렇지 않습니다. 스키마에 비그룹 액세스 토큰 클레임을 추가하려면 JSON 모드에서 스키마를 편집하고 [commonTypes](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) 속성을 추가해야 합니다. 자세한 내용은 [액세스 토큰 매핑](#cognito-map-access-token) 단원을 참조하십시오.
**토큰 유형 선택**
정책 스토어가 자격 증명 소스와 함께 작동하는 방식은 ID 또는 액세스 토큰을 처리할지 여부와 같은 자격 증명 소스 구성의 주요 결정에 따라 달라집니다. 자격 Amazon Cognito 증명 공급자를 사용하면 API 연결 정책 스토어를 생성할 때 토큰 유형을 선택할 수 있습니다. [API 연결 정책 스토어](policy-stores-api-userpool.md)를 생성할 때 ID 또는 액세스 토큰에 대한 권한 부여를 설정할지 여부를 선택해야 합니다. 이 정보는 Verified Permissions가 정책 스토어에 적용하는 스키마 속성과 API Gateway API에 대한 Lambda 권한 부여자의 구문에 영향을 줍니다. 특히 ID 토큰 클레임을 Verified Permissions 콘솔의 속성에 자동으로 매핑하여 혜택을 받으려면 ID 소스를 생성하기 전에 처리하려는 토큰 유형을 조기에 결정해야 합니다. 토큰 유형을 변경하려면 정책과 스키마를 리팩터링하는 데 상당한 노력이 필요합니다. 다음 주제에서는 정책 스토어에서 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"
]
}
}
```
이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요[대괄호 표기법을 사용하여 토큰 속성 참조](policies-examples.md#policies-examples-brackets).
# 에 대한 클라이언트 및 대상 검증 Amazon Cognito
정책 스토어에 자격 증명 소스를 추가하면 Verified Permissions에는 ID 및 액세스 토큰이 의도한 대로 사용되고 있는지 확인하는 구성 옵션이 있습니다. 이 검증은 `IsAuthorizedWithToken` 및 `BatchIsAuthorizedWithToken` API 요청을 처리할 때 발생합니다. 동작은 ID와 액세스 토큰, 및 Amazon Cognito OIDC 자격 증명 소스 간에 다릅니다. Amazon Cognito 사용자 풀 공급자를 사용하면 Verified Permissions가 ID 및 액세스 토큰 모두에서 클라이언트 ID를 검증할 수 있습니다. OIDC 공급자를 통해 Verified Permissions는 ID 토큰의 클라이언트 ID와 액세스 토큰의 대상을 검증할 수 있습니다.
*클라이언트 ID*는 애플리케이션이 사용하는 자격 증명 공급자 인스턴스와 연결된 식별자입니다. 예: `1example23456789`. *대상*은와 같은 액세스 토큰의 의도된 *신뢰 당사자* 또는 대상과 연결된 URL 경로입니다`https://mytoken.example.com`. 액세스 토큰을 사용할 때 `aud` 클레임은 항상 대상과 연결됩니다.
Amazon Cognito ID 토큰에는 [앱 클라이언트](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html) ID가 포함된 `aud` 클레임이 있습니다. 액세스 토큰에는 앱 클라이언트 ID도 포함된 `client_id` 클레임이 있습니다.
자격 증명 소스에 **클라이언트 애플리케이션 검증**을 위한 값을 하나 이상 입력하면 Verified Permissions는이 앱 클라이언트 IDs 목록을 ID 토큰 `aud` 클레임 또는 액세스 토큰 `client_id` 클레임과 비교합니다. Verified Permissions는 자격 Amazon Cognito 증명 소스에 대한 신뢰 당사자 대상 URL을 검증하지 않습니다.
## JWTs 대한 클라이언트 측 권한 부여
정책 스토어 자격 증명 소스를 사용하지 않고 애플리케이션에서 JSON 웹 토큰을 처리하고 해당 클레임을 Verified Permissions에 전달할 수 있습니다. JSON 웹 토큰(JWT)에서 개체 속성을 추출하여 Verified Permissions로 구문 분석할 수 있습니다.
이 예제는 JWT.1을 사용하여 애플리케이션에서 Verified Permissions를 호출하는 방법을 보여줍니다.
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ 이 코드 예제는 [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify) 라이브러리를 사용하여 OIDC 호환 IdP가 서명한 JWT를 검증합니다.
# OIDC 자격 증명 소스 작업
규정 준수 OpenID Connect(OIDC) IdP를 정책 스토어의 자격 증명 소스로 구성할 수도 있습니다. OIDC 공급자는 Amazon Cognito 사용자 풀과 유사합니다. 인증의 결과로 JWTs를 생성합니다. OIDC 공급자를 추가하려면 발급자 URL을 제공해야 합니다.
새 OIDC 자격 증명 소스에는 다음 정보가 필요합니다.
+ 발급자 URL입니다. Verified Permissions는이 URL에서 `.well-known/openid-configuration` 엔드포인트를 검색할 수 있어야 합니다.
+ 와일드카드가 포함되지 않은 CNAME 레코드입니다. 예를 들어는에 매핑할 `a.example.com` 수 없습니다`*.example.net`. 반대로는에 매핑할 `*.example.com` 수 없습니다`a.example.net`.
+ 권한 부여 요청에 사용할 토큰 유형입니다. 이 경우 자격 **증명 토큰**을 선택합니다.
+ 와 같이 자격 증명 소스와 연결할 사용자 엔터티 유형입니다`MyCorp::User`.
+ 와 같이 자격 증명 소스와 연결할 그룹 엔터티 유형입니다`MyCorp::UserGroup`.
+ 예제 ID 토큰 또는 ID 토큰의 클레임 정의입니다.
+ 사용자 및 그룹 개체 IDs. CLI 및 API에서이 접두사를 선택할 수 있습니다. **API Gateway 설정 및 자격 증명 공급자** 또는 **안내 설정** 옵션으로 생성한 정책 스토어에서 Verified Permissions는 발급자 이름의 접두사에서를 뺀 접두사를 할당합니다. 예를 들면 `https://`입니다`MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`.
API 작업을 사용하여 OIDC 소스의 요청을 승인하는 방법에 대한 자세한 내용은 섹션을 참조하세요[권한 부여에 사용 가능한 API 작업](authorization.md#authorization-operations).
다음 예제에서는 회계 부서의 직원에 대한 연말 보고서에 대한 액세스를 허용하고 기밀 분류가 있으며 위성 사무실에 있지 않은 정책을 생성하는 방법을 보여줍니다. Verified Permissions는 보안 주체의 ID 토큰에 있는 클레임에서 이러한 속성을 파생합니다.
보안 주체의 그룹을 참조할 때 정책을 올바르게 평가하려면 `in` 연산자를 사용해야 합니다.
```
permit(
principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting",
action,
resource in MyCorp::Folder::"YearEnd2024"
) when {
principal.jobClassification == "Confidential" &&
!(principal.location like "SatelliteOffice*")
};
```
**Topics**
+ [Amazon Verified Permissions OIDC 자격 증명 소스 생성](oidc-create.md)
+ [Amazon Verified Permissions OIDC 자격 증명 소스 편집](oidc-edit.md)
+ [스키마에 OIDC 토큰 매핑](oidc-map-token-to-schema.md)
+ [OIDC 공급자를 위한 클라이언트 및 대상 검증](oidc-validation.md)
# Amazon Verified Permissions OIDC 자격 증명 소스 생성
다음 절차에서는 기존 정책 스토어에 자격 증명 소스를 추가합니다.
Verified Permissions 콘솔에서 [새 정책 스토어](policy-stores-create.md)를 생성할 때 자격 증명 소스를 생성할 수도 있습니다. 이 프로세스에서는 자격 증명 소스 토큰의 클레임을 개체 속성으로 자동으로 가져올 수 있습니다. **안내 설정** 또는 ** API Gateway 설정 및 자격 증명 공급자** 옵션을 선택합니다. 이러한 옵션은 초기 정책도 생성합니다.
**참고**
정책 스토어를 생성하기 전에는 왼쪽 탐색 창에서 **자격 증명 소스**를 사용할 수 없습니다. 생성한 자격 증명 소스는 현재 정책 스토어와 연결됩니다.
에서 [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)를 사용하여 자격 증명 소스를 생성 AWS CLI 하거나 Verified Permissions API에서 [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)를 사용하여 자격 증명 소스를 생성할 때 보안 주체 엔터티 유형을 제외할 수 있습니다. 그러나 빈 엔터티 유형은 엔터티 유형이 인 ID 소스를 생성합니다`AWS::Cognito`. 이 엔터티 이름은 정책 스토어 스키마와 호환되지 않습니다. 자격 증명을 정책 스토어 스키마와 통합하려면 보안 주체 Amazon Cognito 엔터티 유형을 지원되는 정책 스토어 엔터티로 설정해야 합니다.
------
#### [ AWS Management Console ]
**OpenID Connect(OIDC) 자격 증명 소스를 생성하려면**
1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions/)을 엽니다. 정책 스토어를 선택합니다.
1. 왼쪽 탐색 창에서 **자격 증명 소스**를 선택합니다.
1. **자격 증명 소스 생성**을 선택합니다.
1. **외부 OIDC 공급자**를 선택합니다.
1. **발급자 URL**에 OIDC 발급자의 URL을 입력합니다. 이는 권한 부여 서버, 서명 키 및와 같은 공급자에 대한 기타 정보를 제공하는 서비스 엔드포인트입니다`https://auth.example.com`. 발급자 URL은에서 OIDC 검색 문서를 호스팅해야 합니다`/.well-known/openid-configuration`.
1. **토큰 유형**에서 애플리케이션이 권한 부여를 위해 제출할 OIDC JWT 유형을 선택합니다. 자세한 내용은 [스키마에 OIDC 토큰 매핑](oidc-map-token-to-schema.md) 단원을 참조하십시오.
1. **스키마 엔터티에 토큰 클레임 매핑**에서 자격 증명 소스에 대한 **사용자 엔**터티 및 **사용자 클레임**을 선택합니다. **사용자 엔터**티는 OIDC 공급자의 사용자를 참조하려는 정책 스토어의 엔터티입니다. **사용자 클레임**은 일반적으로 평가할 엔터티의 고유 식별자를 포함하는 ID 또는 액세스 토큰`sub`의 클레임입니다. 연결된 OIDC IdP의 ID는 선택한 보안 주체 유형에 매핑됩니다.
1. (선택 사항) **스키마 엔터티에 토큰 클레임 매핑**에서 자격 증명 소스에 대한 **그룹 엔**터티 및 **그룹 클레임**을 선택합니다. **그룹 개체**는 **사용자 개체**의 [상위](https://docs.cedarpolicy.com/overview/terminology.html#term-group) 개체입니다. 그룹 클레임이이 엔터티에 매핑됩니다. **그룹 클레임**은 일반적으로 평가할 엔터티`groups`에 대한 사용자 그룹 이름의 문자열, JSON 또는 공백으로 구분된 문자열이 포함된 ID 또는 액세스 토큰의 클레임입니다. 연결된 OIDC IdP의 ID는 선택한 보안 주체 유형에 매핑됩니다.
1. **검증 - 선택 사항**에서 권한 부여 요청에 정책 스토어가 수락할 클라이언트 IDs 또는 대상 URLs 있는 경우 입력합니다.
1. **자격 증명 소스 생성**을 선택합니다.
1. (선택 사항) 정책 스토어에 스키마가 있는 경우 Cedar 정책의 자격 증명 또는 액세스 토큰에서 추출한 속성을 참조하려면 먼저 Cedar가 자격 증명 소스가 생성하는 보안 주체 유형을 인식하도록 스키마를 업데이트해야 합니다. 스키마에 추가되는 항목에는 Cedar 정책에서 참조하려는 속성이 포함되어야 합니다. OIDC 토큰 속성을 Cedar 보안 주체 속성에 매핑하는 방법에 대한 자세한 내용은 섹션을 참조하세요[스키마에 OIDC 토큰 매핑](oidc-map-token-to-schema.md).
1. 토큰의 정보를 사용하여 권한 부여 결정을 내리는 정책을 생성합니다. 자세한 내용은 [Amazon Verified Permissions 정적 정책 생성](policies-create.md) 단원을 참조하십시오.
이제 자격 증명 소스를 생성하고, 스키마를 업데이트하고, 정책을 생성했으므로 `IsAuthorizedWithToken`를 사용하여 Verified Permissions가 권한 부여 결정을 내리도록 합니다. 자세한 내용은 *Amazon Verified Permissions API 참조 안내서*의 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)을 참조하세요.
------
#### [ AWS CLI ]
**OIDC 자격 증명 소스를 생성하려면**
[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html) 작업을 사용하여 자격 증명 소스를 생성할 수 있습니다. 다음 예제에서는 OIDC 자격 증명 공급자(IdP)의 인증된 자격 증명에 액세스할 수 있는 자격 증명 소스를 생성합니다.
1. `create-identity-source` 명령의 `--configuration` 파라미터에서 사용할 OIDC IdP에 대한 다음 세부 정보가 포함된 `config.txt` 파일을 생성합니다.
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["1example23456789"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 다음 명령을 실행하여 OIDC 자격 증명 소스를 생성합니다.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (선택 사항) 정책 스토어에 스키마가 있는 경우 Cedar 정책의 자격 증명 또는 액세스 토큰에서 추출한 속성을 참조하려면 먼저 Cedar가 자격 증명 소스가 생성하는 보안 주체 유형을 인식하도록 스키마를 업데이트해야 합니다. 스키마에 추가되는 항목에는 Cedar 정책에서 참조하려는 속성이 포함되어야 합니다. OIDC 토큰 속성을 Cedar 보안 주체 속성에 매핑하는 방법에 대한 자세한 내용은 섹션을 참조하세요[스키마에 OIDC 토큰 매핑](oidc-map-token-to-schema.md).
1. 토큰의 정보를 사용하여 권한 부여 결정을 내리는 정책을 생성합니다. 자세한 내용은 [Amazon Verified Permissions 정적 정책 생성](policies-create.md) 단원을 참조하십시오.
이제 자격 증명 소스를 생성하고, 스키마를 업데이트하고, 정책을 생성했으므로 `IsAuthorizedWithToken`를 사용하여 Verified Permissions가 권한 부여 결정을 내리도록 합니다. 자세한 내용은 *Amazon Verified Permissions API 참조 안내서*의 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)을 참조하세요.
------
# Amazon Verified Permissions OIDC 자격 증명 소스 편집
자격 증명 소스를 생성한 후 일부 파라미터를 편집할 수 있습니다. 자격 증명 소스 유형은 변경할 수 없으며 자격 증명 소스를 삭제하고에서 OIDC 또는 OIDC Amazon Cognito 로 전환할 새 소스를 생성해야 합니다 Amazon Cognito. 정책 스토어 스키마가 자격 증명 소스 속성과 일치하는 경우 자격 증명 소스에 대한 변경 사항을 반영하도록 스키마를 별도로 업데이트해야 합니다.
------
#### [ AWS Management Console ]
**OIDC 자격 증명 소스를 업데이트하려면**
1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions/)을 엽니다. 정책 스토어를 선택합니다.
1. 왼쪽 탐색 창에서 **자격 증명 소스**를 선택합니다.
1. 편집할 자격 증명 소스의 ID를 선택합니다.
1. **편집**을 선택합니다.
1. **OIDC 공급자 세부 정보**에서 필요에 따라 **발급자 URL**을 변경합니다.
1. **토큰 클레임을 스키마 속성에 매핑**에서 필요에 따라 사용자 및 그룹 클레임과 정책 스토어 엔터티 유형 간의 연결을 변경합니다. 개체 유형을 변경한 후에는 정책 및 스키마 속성을 업데이트하여 새 개체 유형에 적용해야 합니다.
1. **대상 검증**에서 적용하려는 대상 값을 추가하거나 제거합니다.
1. **변경 사항 저장**을 선택합니다.
자격 증명 소스 옆에 있는 라디오 버튼을 선택한 다음 **자격 증명 소스 삭제**를 선택하여 자격 증명 소스를 삭제할 수 있습니다. 텍스트 상자에 `delete`를 입력한 다음 **자격 증명 소스 삭제**를 선택하여 자격 증명 소스 삭제를 확인합니다.
------
#### [ AWS CLI ]
**OIDC 자격 증명 소스를 업데이트하려면**
[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html) 작업을 사용하여 자격 증명 소스를 업데이트할 수 있습니다. 다음 예시에서는 다른 OIDC 공급자를 사용하도록 지정된 자격 증명 소스를 업데이트합니다.
1. `update-identity-source` 명령의 `--configuration` 파라미터에서 사용할 OIDC IdP에 대한 다음 세부 정보가 포함된 `config.txt` 파일을 생성합니다.
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth2.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["2example10111213"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 다음 명령을 실행하여 OIDC 자격 증명 소스를 업데이트합니다.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**참고**
자격 증명 소스의 보안 주체 유형을 변경하는 경우 업데이트된 보안 주체 유형을 올바르게 반영하도록 스키마를 업데이트해야 합니다.
------
# 스키마에 OIDC 토큰 매핑
정책 스토어에 자격 증명 소스를 추가하고 정책 스토어 스키마에 공급자 클레임 또는 토큰을 매핑하려고 할 수 있습니다. [가이드 설정을](policy-stores-create.md) 사용하여 자격 증명 소스로 정책 스토어를 생성하거나 정책 스토어가 생성된 후 스키마를 수동으로 업데이트하여이 프로세스를 자동화할 수 있습니다. 토큰을 스키마에 매핑한 후에는 토큰을 참조하는 정책을 생성할 수 있습니다.
사용 설명서의이 섹션에는 다음 정보가 포함되어 있습니다.
+ 정책 스토어 스키마에 속성을 자동으로 채울 수 있는 경우
+ 자격 증명 소스에 대한 스키마를 수동으로 빌드하는 방법
[API 연결 정책 저장소](policy-stores-api-userpool.md) 및 [안내형 설정을](policy-stores-create.md) 통해 생성된 자격 증명 소스가 있는 정책 저장소는 스키마에 자격 증명(ID) 토큰 속성을 수동으로 매핑할 필요가 없습니다. Verified Permissions에 사용자 풀의 속성을 제공하고 사용자 속성으로 채워진 스키마를 생성할 수 있습니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 엔터티의 속성에 매핑합니다.
Verified Permissions 정책 스토어에서 OIDC ID 제공업체(IdP)를 ID 소스로 사용하려면 스키마에 제공업체 속성이 있어야 합니다. 스키마는 고정되며 공급자 토큰이 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) 또는 [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html) API 요청에서 생성하는 엔터티와 일치해야 합니다. ID 토큰의 공급자 정보에서 스키마를 자동으로 채우는 방식으로 정책 스토어를 생성한 경우 정책을 작성할 준비가 된 것입니다. 자격 증명 소스에 대한 스키마 없이 정책 스토어를 생성하는 경우 API 요청을 사용하여 생성된 엔터티와 일치하는 스키마에 공급자 속성을 추가해야 합니다. 그런 다음 공급자 토큰의 속성을 사용하여 정책을 작성할 수 있습니다.
**Topics**
+ [스키마에 ID 토큰 매핑](#oidc-map-id-token)
+ [액세스 토큰 매핑](#oidc-map-access-token)
+ [스키마 매핑에 대해 알아야 할 사항](#oidc-map-token-to-schema-things-to-know)
## 스키마에 ID 토큰 매핑
Verified Permissions는 ID 토큰 클레임을 사용자의 이름 및 제목, 그룹 멤버십, 연락처 정보 등 사용자의 속성으로 처리합니다. ID 토큰은 *속성 기반 액세스 제어*(ABAC) 권한 부여 모델에서 가장 유용합니다. Verified Permissions가 요청자를 기반으로 리소스에 대한 액세스를 분석하도록 하려면 자격 증명 소스의 ID 토큰을 선택합니다.
OIDC 공급자의 ID 토큰 작업은 Amazon Cognito ID 토큰 작업과 거의 동일합니다. 차이점은 클레임에 있습니다. IdP는 [표준 OIDC 속성을](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 제공하거나 사용자 지정 스키마를 가질 수 있습니다. Verified Permissions 콘솔에서 새 정책 스토어를 생성할 때 예제 ID 토큰을 사용하여 OIDC 자격 증명 소스를 추가하거나 토큰 클레임을 사용자 속성에 수동으로 매핑할 수 있습니다. Verified Permissions는 IdP의 속성 스키마를 인식하지 못하므로이 정보를 제공해야 합니다.
자세한 내용은 [Verified Permissions 정책 스토어 생성](policy-stores-create.md) 단원을 참조하십시오.
다음은 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 토큰 속성을 반영합니다.](policies-examples.md#policies-examples-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 스키마에 액세스 토큰 예제의 속성을 반영하는 방법을 보여줍니다. 스키마 편집에 대한 자세한 내용은 [정책 스토어 스키마 편집](schema-edit.md)을(를) 참조하세요.
```
{
"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 액세스 토큰 속성을 반영합니다.](policies-examples.md#policies-examples-oidc-access).
## 스키마 매핑에 대해 알아야 할 사항
**속성 매핑은 토큰 유형마다 다릅니다.**
액세스 토큰 권한 부여에서 Verified Permissions는 클레임을 [컨텍스트](context.md)에 매핑합니다. ID 토큰 권한 부여에서 Verified Permissions는 클레임을 보안 주체 속성에 매핑합니다. Verified Permissions 콘솔에서 생성하는 정책 스토어의 경우 **빈** 정책 스토어와 **샘플** 정책 스토어만 자격 증명 소스가 없어지고 ID 토큰 권한 부여를 위해 사용자 풀 속성으로 스키마를 채워야 합니다. 액세스 토큰 권한 부여는 그룹 멤버십 클레임이 있는 역할 기반 액세스 제어(RBAC)를 기반으로 하며 다른 클레임을 정책 스토어 스키마에 자동으로 매핑하지 않습니다.
**자격 증명 소스 속성은 필요하지 않습니다.**
Verified Permissions 콘솔에서 자격 증명 소스를 생성하면 속성이 필수로 표시되지 않습니다. 이렇게 하면 누락된 클레임으로 인해 권한 부여 요청에 검증 오류가 발생하지 않습니다. 필요에 따라 속성을 필수로 설정할 수 있지만 모든 권한 부여 요청에 있어야 합니다.
**RBAC는 스키마에 속성이 필요하지 않습니다.**
자격 증명 소스의 스키마는 자격 증명 소스를 추가할 때 수행하는 엔터티 연결에 따라 달라집니다. 자격 증명 소스는 하나의 클레임을 사용자 엔터티 유형에 매핑하고 하나의 클레임을 그룹 엔터티 유형에 매핑합니다. 이러한 엔터티 매핑은 자격 증명 소스 구성의 핵심입니다. 이 최소 정보를 사용하여 역할 기반 액세스 제어(RBAC) 모델에서 특정 사용자 및 사용자가 구성원일 수 있는 특정 그룹에 대한 권한 부여 작업을 수행하는 정책을 작성할 수 있습니다. 스키마에 토큰 클레임을 추가하면 정책 스토어의 권한 부여 범위가 확장됩니다. ID 토큰의 사용자 속성에는 속성 기반 액세스 제어(ABAC) 권한 부여에 기여할 수 있는 사용자에 대한 정보가 있습니다. 액세스 토큰의 컨텍스트 속성에는 공급자의 추가 액세스 제어 정보를 제공할 수 있지만 추가 스키마 수정이 필요한 OAuth 2.0 범위와 같은 정보가 있습니다.
Verified Permissions 콘솔의 **API Gateway 설정 및 자격 증명 공급자** 및 **안내 설정** 옵션은 스키마에 ID 토큰 클레임을 할당합니다. 액세스 토큰 클레임의 경우에는 그렇지 않습니다. 스키마에 비 그룹 액세스 토큰 클레임을 추가하려면 JSON 모드에서 스키마를 편집하고 [commonTypes](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) 속성을 추가해야 합니다. 자세한 내용은 [액세스 토큰 매핑](#oidc-map-access-token) 단원을 참조하십시오.
**OIDC 그룹 클레임은 여러 형식을 지원합니다.**
OIDC 공급자를 추가할 때 정책 스토어의 사용자 그룹 멤버십에 매핑하려는 ID 또는 액세스 토큰에서 그룹 클레임의 이름을 선택할 수 있습니다. 확인된 권한은 그룹 클레임을 다음 형식으로 인식합니다.
1. 공백이 없는 문자열: `"groups": "MyGroup"`
1. 공백으로 구분된 목록: `"groups": "MyGroup1 MyGroup2 MyGroup3"`. 각 문자열은 그룹입니다.
1. 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"
]
}
}
```
이 스키마에 대해 검증할 정책 예제는 섹션을 참조하세요[대괄호 표기법을 사용하여 토큰 속성 참조](policies-examples.md#policies-examples-brackets).
# OIDC 공급자를 위한 클라이언트 및 대상 검증
정책 스토어에 자격 증명 소스를 추가하면 Verified Permissions에는 ID 및 액세스 토큰이 의도한 대로 사용되고 있는지 확인하는 구성 옵션이 있습니다. 이 검증은 `IsAuthorizedWithToken` 및 `BatchIsAuthorizedWithToken` API 요청을 처리할 때 발생합니다. 동작은 ID와 액세스 토큰, 및 Amazon Cognito OIDC 자격 증명 소스 간에 다릅니다. Amazon Cognito 사용자 풀 공급자를 사용하면 Verified Permissions가 ID 및 액세스 토큰 모두에서 클라이언트 ID를 검증할 수 있습니다. OIDC 공급자를 통해 Verified Permissions는 ID 토큰의 클라이언트 ID와 액세스 토큰의 대상을 검증할 수 있습니다.
*클라이언트 ID*는 애플리케이션이 사용하는 자격 증명 공급자 인스턴스와 연결된 식별자입니다. 예: `1example23456789`. *대상*은와 같은 액세스 토큰의 의도된 *신뢰 당사자* 또는 대상과 연결된 URL 경로입니다`https://mytoken.example.com`. 액세스 토큰을 사용할 때 `aud` 클레임은 항상 대상과 연결됩니다.
OIDC ID 토큰에는와 같은 클라이언트 ID가 포함된 `aud` 클레임이 있습니다`1example23456789`. IDs
OIDC 액세스 토큰에는와 같은 토큰의 대상 URL이 포함된 `aud` 클레임`https://myapplication.example.com`과와 같은 클라이언트 ID가 포함된 `client_id` 클레임이 있습니다`1example23456789`. IDs
정책 스토어를 설정할 때 정책 스토어가 토큰**의 대상을 검증**하는 데 사용하는 대상 검증 값을 하나 이상 입력합니다.
+ **ID 토큰** - Verified Permissions는 `aud` 클레임의 클라이언트 ID 중 하나 이상이 대상 검증 값과 일치하는지 확인하여 클라이언트 IDs를 검증합니다.
+ **액세스 토큰** - Verified Permissions는 `aud` 클레임의 URL이 대상 검증 값과 일치하는지 확인하여 대상을 검증합니다. `aud` 클레임이 없는 경우 `cid` 또는 `client_id` 클레임을 사용하여 대상을 검증할 수 있습니다. 자격 증명 공급자에게 문의하여 올바른 대상 클레임 및 형식을 확인하세요.
## JWTs 대한 클라이언트 측 권한 부여
정책 스토어 자격 증명 소스를 사용하지 않고 애플리케이션에서 JSON 웹 토큰을 처리하고 해당 클레임을 Verified Permissions에 전달할 수 있습니다. JSON 웹 토큰(JWT)에서 개체 속성을 추출하여 Verified Permissions로 구문 분석할 수 있습니다.
이 예제는 JWT.1을 사용하여 애플리케이션에서 Verified Permissions를 호출하는 방법을 보여줍니다.
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ 이 코드 예제는 [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify) 라이브러리를 사용하여 OIDC 호환 IdP가 서명한 JWT를 검증합니다.