기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
스키마 및 정책에서 ID 소스 사용
ID 소스를 정책 저장소에 추가하고 제공자 클레임을 정책 저장소 스키마에 매핑해야 할 수도 있습니다. 이 프로세스를 자동화하거나 스키마를 수동으로 업데이트할 수 있습니다. 사용 설명서의 이 섹션에는 다음과 같은 정보가 있습니다.
-
정책 저장소 스키마에 속성을 자동으로 채울 수 있는 경우
-
검증된 권한 정책에서 Amazon Cognito 및 OIDC 토큰 클레임을 사용하는 방법
-
자격 증명 소스의 스키마를 수동으로 구축하는 방법
가이드 설정을 통해 ID 소스가 있는 API 연결 정책 저장소 및 정책 저장소의 경우 ID (ID) 토큰 속성을 스키마에 수동으로 매핑할 필요가 없습니다. 사용자 풀 또는 OIDC 토큰의 속성과 함께 검증된 권한을 제공하고 사용자 속성으로 채워진 스키마를 생성할 수 있습니다. ID 토큰 인증에서 검증된 권한은 클레임을 보안 주체의 속성에 매핑합니다. 다음과 같은 상황에서는 Amazon Cognito 토큰을 스키마에 수동으로 매핑해야 할 수 있습니다.
-
샘플에서 빈 정책 스토어나 정책 스토어를 생성했습니다.
-
액세스 토큰 사용을 RBAC (역할 기반 액세스 제어) 이상으로 확장하고 싶습니다.
-
검증된 권한 REST API, AWS SDK 또는 를 사용하여 정책 저장소를 생성합니다. AWS CDK
Amazon Cognito 또는 OIDC ID 공급자 (IdP) 를 검증된 권한 정책 스토어의 자격 증명 소스로 사용하려면 스키마에 공급자 속성이 있어야 합니다. ID 토큰의 공급자 정보로부터 스키마를 자동으로 채우는 방식으로 정책 스토어를 생성했다면 정책을 작성할 준비가 된 것입니다. ID 소스에 대한 스키마 없이 정책 저장소를 생성하는 경우 스키마에 공급자 속성을 추가해야 합니다. 스키마는 제공자 토큰이 생성하는 엔티티 IsAuthorizedWithToken또는 BatchIsAuthorizedWith토큰 API 요청과 일치해야 합니다. 그런 다음 제공자 토큰의 속성을 사용하여 정책을 작성할 수 있습니다.
검증된 권한에서 인증된 사용자의 Amazon Cognito ID 및 액세스 토큰을 사용하는 방법에 대한 자세한 내용은 Amazon Cognito 개발자 안내서의 Amazon 검증 권한을 통한 권한 부여를 참조하십시오.
스키마 매핑에 대해 알아야 할 사항
속성 매핑은 토큰 유형마다 다릅니다.
액세스 토큰 인증에서 검증된 권한은 클레임을 컨텍스트에 매핑합니다. ID 토큰 인증에서 검증된 권한은 클레임을 주요 속성에 매핑합니다. Verified Permissions 콘솔에서 생성하는 정책 저장소의 경우 비어 있는 샘플 정책 저장소만 있으면 ID 소스가 없으므로 ID 토큰 인증을 위한 사용자 풀 속성으로 스키마를 채워야 합니다. 액세스 토큰 권한 부여는 그룹 구성원 클레임을 포함한 RBAC (역할 기반 액세스 제어) 를 기반으로 하며 다른 클레임을 정책 저장소 스키마에 자동으로 매핑하지 않습니다.
ID 소스 속성은 필요하지 않습니다.
검증된 권한 콘솔에서 ID 소스를 만들 때는 어떤 속성도 필수로 표시되지 않습니다. 이렇게 하면 클레임 누락으로 인해 권한 부여 요청에서 유효성 검사 오류가 발생하는 것을 방지할 수 있습니다. 필요에 따라 속성을 필수로 설정할 수 있지만 모든 권한 부여 요청에 해당 속성이 있어야 합니다.
RBAC에는 스키마의 속성이 필요하지 않습니다.
ID 소스의 스키마는 ID 소스를 추가할 때 만드는 엔티티 연결에 따라 달라집니다. ID 소스는 클레임 하나를 사용자 엔티티 유형에 매핑하고, 다른 클레임을 그룹 엔티티 유형에 매핑합니다. 이러한 엔티티 매핑은 ID-소스 구성의 핵심입니다. 이 최소한의 정보만 있으면 RBAC (역할 기반 액세스 제어) 모델에서 특정 사용자 및 사용자가 구성원으로 속할 수 있는 특정 그룹에 대해 권한 부여 작업을 수행하는 정책을 작성할 수 있습니다. 스키마에 토큰 클레임을 추가하면 정책 저장소의 권한 부여 범위가 확장됩니다. ID 토큰의 사용자 속성에는 ABAC (속성 기반 액세스 제어) 권한 부여에 기여할 수 있는 사용자에 대한 정보가 있습니다. 액세스 토큰의 컨텍스트 속성에는 OAuth 2.0 범위와 같은 정보가 포함되어 있어 공급자의 추가 액세스 제어 정보를 제공할 수 있지만 추가 스키마 수정이 필요합니다.
API Gateway로 설정, ID 소스 및 검증된 권한 콘솔의 가이드 설정 옵션은 스키마에 ID 토큰 클레임을 할당합니다. 액세스 토큰 클레임의 경우는 그렇지 않습니다. 스키마에 비그룹 액세스 토큰 클레임을 추가하려면 JSON 모드에서 스키마를 편집하고 CommonTypes 속성을 추가해야 합니다.
OIDC 그룹 클레임은 여러 형식을 지원합니다.
OIDC 공급자를 추가할 때 ID 또는 액세스 토큰에서 그룹 클레임의 이름을 선택하여 정책 저장소의 사용자 그룹 구성원에 매핑할 수 있습니다. 검증된 권한은 다음 형식의 그룹 클레임을 인식합니다.
-
공백 없는 문자열:
"groups": "MyGroup" -
공백으로 구분된 목록:.
"groups": "MyGroup1 MyGroup2 MyGroup3"각 문자열은 그룹입니다. -
JSON (쉼표로 구분) 목록:
"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]
참고
검증된 권한은 공백으로 구분된 그룹 클레임의 각 문자열을 별도의 그룹으로 해석합니다. 공백 문자가 있는 그룹 이름을 단일 그룹으로 해석하려면 클레임에서 공백을 바꾸거나 제거하십시오. 예를 들어, 이름이 인 그룹의 형식을 지정합니다My
Group. MyGroup
토큰 유형을 선택합니다.
정책 저장소가 ID 소스와 연동되는 방식은 ID 소스 구성의 주요 결정, 즉 ID 토큰을 처리할지 액세스 토큰을 처리할지에 따라 달라집니다. Amazon Cognito 자격 증명 공급자를 사용하면 API 연결 정책 스토어를 생성할 때 토큰 유형을 선택할 수 있습니다. API 연결 정책 스토어를 생성할 때는 ID 또는 액세스 토큰에 대한 권한 부여를 설정할지 여부를 선택해야 합니다. 이 정보는 검증된 권한이 정책 스토어에 적용하는 스키마 속성과 API Gateway API에 대한 Lambda 권한 부여자의 구문에 영향을 줍니다. OIDC 공급자의 경우 ID 소스를 추가할 때 토큰 유형을 선택해야 합니다. ID 또는 액세스 토큰을 선택할 수 있으며 선택하지 않은 토큰 유형은 정책 저장소에서 처리되지 않도록 선택할 수 있습니다. 특히 Verified Permissions 콘솔에서 ID 토큰 클레임을 속성에 자동으로 매핑하는 기능을 활용하려면 ID 소스를 생성하기 전에 처리할 토큰 유형을 먼저 결정해야 합니다. 토큰 유형을 변경하려면 정책과 스키마를 리팩토링하는 데 상당한 노력이 필요합니다. 다음 항목에서는 정책 저장소에서 ID 및 액세스 토큰을 사용하는 방법을 설명합니다.
Cedar 파서에는 일부 문자에는 대괄호가 필요합니다.
정책은 일반적으로 다음과 같은 형식의 스키마 속성을 참조합니다. principal.username :., 또는 같이 영숫자가 아닌 대부분의 문자가 토큰 클레임 이름에 나타나는 경우 Verified Permissions는 또는 / 같은 조건 값을 파싱할 수 없습니다. principal.cognito:groups context.ip-address 대신 각각 또는 형식으로 대괄호 표기법을 사용하여 이러한 조건의 형식을 지정해야 합니다. principal["cognito:username"] context["ip-address"] 밑줄 문자는 클레임 이름에 사용할 수 있는 _ 문자이며 이 요구 사항에서 영숫자가 아닌 유일한 예외입니다.
이 유형의 주요 속성에 대한 일부 예제 스키마는 다음과 같습니다.
"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" ] } }
이 스키마를 기준으로 검증할 속성에 대한 예제 정책은 다음과 같습니다.
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal has email && principal.email == "alice@example.com" && context["ip-address"] like "192.0.2.*" };
ID 토큰을 스키마에 매핑
검증된 권한은 ID 토큰 클레임을 사용자의 특성 (이름 및 직함, 그룹 구성원, 연락처 정보) 으로 처리합니다. ID 토큰은 속성 기반 액세스 제어 (ABAC) 인증 모델에서 가장 유용합니다. Verified Permissions에서 요청한 사람을 기반으로 리소스에 대한 액세스를 분석하도록 하려면 ID 소스의 ID 토큰을 선택하십시오.
아마존 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 - 표준 클레임
-
표준 OIDC 클레임은 및 와 같습니다
email.phone_number자세한 내용은 에라타 세트 2를 포함하는 OpenID Connect Core 1.0의 표준 클레임을참조하십시오. cognito:groups-
사용자의 그룹 멤버십. RBAC (역할 기반 액세스 제어) 에 기반한 권한 부여 모델에서 이 클레임은 정책에서 평가할 수 있는 역할을 제시합니다.
- 일시적 클레임
-
사용자의 속성은 아니지만 사용자 풀 사전 토큰 생성 Lambda 트리거에 의해 런타임에 추가되는 클레임 일시적 클레임은 표준 클레임과 비슷하지만 표준을 벗어납니다 (예: 또는).
tenantdepartment
:구분자가 있는 Amazon Cognito 속성을 참조하는 정책에서는 형식의 속성을 참조합니다. principal[" roles cognito:username"]cognito:groups 클레임은 이 규칙의 예외입니다. 검증된 권한은 이 클레임의 내용을 사용자 엔티티의 상위 엔티티에 매핑합니다.
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 사용자 풀을 사용하여 자격 증명 소스를 생성할 때는 인증 요청에서 확인된 권한이 생성하는 주요 개체의 유형을 지정합니다. IsAuthorizedWithToken 그러면 정책을 통해 해당 요청 평가의 일환으로 해당 보안 주체의 속성을 테스트할 수 있습니다. 스키마는 자격 증명 소스의 주체 유형과 속성을 정의하며, 이를 Cedar 정책에서 참조할 수 있습니다.
또한 ID 토큰 그룹 클레임에서 파생하려는 그룹 엔티티의 유형을 지정합니다. 권한 부여 요청에서 검증된 권한은 그룹 클레임의 각 구성원을 해당 그룹 엔티티 유형에 매핑합니다. 정책에서 해당 그룹 엔티티를 주도자로 참조할 수 있습니다.
다음 예는 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 속성을 반영하도록 스키마를 업데이트한 후 해당 속성을 참조하는 정책을 생성할 수 있습니다.
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
OIDC ID 토큰
OIDC 공급자의 ID 토큰으로 작업하는 것은 Amazon Cognito ID 토큰을 사용하는 것과 거의 같습니다. 차이점은 클레임에 있습니다. IdP는 표준 OIDC 특성을
자세한 정보는 Verified Permissions 정책 스토어 생성을 참조하세요.
다음은 OIDC ID 소스가 있는 정책 저장소의 예제 스키마입니다.
"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 공급자의 그룹 구성원에게 적용됩니다.
permit ( principal in MyCorp::UserGroup::"MyOIDCProvider|MyUserGroup", action, resource ) when { principal.email_verified == true && principal.email == "alice@example.com" && principal.phone_number_verified == true && principal.phone_number like "+1206*" };
액세스 토큰 매핑
검증된 권한은 그룹 클레임 이외의 액세스 토큰 클레임을 작업의 속성 또는 컨텍스트 속성으로 처리합니다. 그룹 멤버십과 함께 IdP의 액세스 토큰에는 API 액세스에 대한 정보가 포함될 수 있습니다. 액세스 토큰은 RBAC (역할 기반 액세스 제어) 를 사용하는 권한 부여 모델에 유용합니다. 그룹 구성원 자격 이외의 액세스 토큰 클레임에 의존하는 권한 부여 모델의 경우 스키마 구성에 추가 작업이 필요합니다.
Amazon Cognito 액세스 토큰 매핑
Amazon Cognito 액세스 토큰에는 권한 부여에 사용할 수 있는 클레임이 있습니다.
Amazon Cognito 액세스 토큰의 유용한 클레임
client_id-
OIDC 신뢰 당사자의 클라이언트 애플리케이션 ID. 검증된 권한은 클라이언트 ID를 사용하여 권한 부여 요청이 정책 저장소에 허용된 클라이언트에서 온 것인지 확인할 수 있습니다. machine-to-machine (M2M) 권한 부여에서 요청 시스템은 클라이언트 암호를 사용하여 요청을 승인하고 클라이언트 ID와 범위를 권한 부여의 증거로 제공합니다.
scopecognito:groups-
사용자의 그룹 멤버십. RBAC (역할 기반 액세스 제어) 에 기반한 권한 부여 모델에서 이 클레임은 정책에서 평가할 수 있는 역할을 제시합니다.
- 일시적 클레임
-
액세스 권한은 아니지만 사용자 풀 사전 토큰 생성 Lambda 트리거에 의해 런타임에 추가되는 클레임 일시적 클레임은 표준 클레임과 비슷하지만 표준을 벗어납니다 (예: 또는).
tenantdepartment액세스 토큰을 사용자 지정하면 청구서에 비용이 추가됩니다. AWS
Amazon Cognito 사용자 풀의 액세스 토큰 구조에 대한 자세한 내용은 Amazon Cognito 개발자 안내서의 액세스 토큰 사용을 참조하십시오.
Amazon Cognito 액세스 토큰은 Verified Permissions으로 전달될 때 컨텍스트 객체에 매핑됩니다. context.token.을 사용하여 액세스 토큰의 속성을 참조할 수 있습니다. 다음 액세스 토큰 예제에는 attribute_nameclient_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 속성을 반영하도록 스키마를 업데이트한 후 해당 속성을 참조하는 정책을 생성할 수 있습니다.
permit(principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI/mydata.write") };
OIDC 액세스 토큰 매핑
외부 OIDC 공급자가 제공하는 대부분의 액세스 토큰은 Amazon Cognito 액세스 토큰과 밀접하게 연계됩니다. OIDC 액세스 토큰은 검증된 권한으로 전달될 때 컨텍스트 객체에 매핑됩니다. context.token.을 사용하여 액세스 토큰의 속성을 참조할 수 있습니다. 다음 예제 OIDC 액세스 토큰에는 기본 클레임 예제가 포함되어 있습니다.attribute_name
{ "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" } } } }
IdP 특성을 반영하도록 스키마를 업데이트한 후 해당 특성을 참조하는 정책을 생성할 수 있습니다.
permit( principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource ) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI-read") };
Amazon Cognito 콜론으로 구분된 클레임의 대체 표기법
검증된 권한 출시 당시 Amazon Cognito 토큰 클레임에 대한 권장 스키마는 콜론으로 구분된 문자열을 cognito:groups 반환하고 해당 문자를 계층 구분 기호로 사용하도록 custom:store 변환했습니다. . 이 형식을 점 표기법이라고 합니다. 예를 들어, 정책에 대한 cognito:groups principal.cognito.groups 참조가 포함되었습니다. 이 형식을 계속 사용할 수 있지만 대괄호 표기법을 사용하여 스키마와 정책을 작성하는 것이 좋습니다. 이 형식에서는 에 대한 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 } } } }
이 형식의 스키마를 사용하면 다음 예와 같이 점 표기법이 포함된 정책을 생성할 수 있습니다.
permit(principal, action, resource) when { principal.cognito.username == "alice" && principal.custom.employmentStoreCode == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
