Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API. This is documented in each patch with FIXMEs [0].
The following acceptance criteria describes how the v3 assignment API should behave with tokens from multiple scopes.
GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/{target_id}/actors/{actor_id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API. This is documented in each patch with FIXMEs [0].
The following acceptance criteria describes how the v3 assignment API should behave with tokens from multiple scopes.
GET /target/ {target_ id}/actor/ {actor_ id}/roles/ {role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/ {target_ id}/actors/ {actor_ id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/ {target_ id}/actor/ {actor_ id}/roles/ {role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
DELETE /target/ {target_ id}/actor/ {actor_ id}/roles/ {role_id}
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
[0] https:/ /github. com/openstack/ keystone/ blob/68df7bf1f3 b3d6ab3f691f59f 1ce6de6b0b1deab /keystone/ common/ policies/ project. py