기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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를 검증합니다.