keystone.tests.unit.assignment package¶
Subpackages¶
Submodules¶
keystone.tests.unit.assignment.test_backends module¶
-
class
keystone.tests.unit.assignment.test_backends.
AssignmentTestHelperMixin
[source]¶ Bases:
object
Mixin class to aid testing of assignments.
This class supports data driven test plans that enable:
Creation of initial entities, such as domains, users, groups, projects and roles
Creation of assignments referencing the above entities
A set of input parameters and expected outputs to list_role_assignments based on the above test data
A test plan is a dict of the form:
- test_plan = {
entities: details and number of entities, group_memberships: group-user entity memberships, assignments: list of assignments to create, tests: list of pairs of input params and expected outputs}
An example test plan:
- test_plan = {
# First, create the entities required. Entities are specified by # a dict with the key being the entity type and the value an # entity specification which can be one of: # # - a simple number, e.g. {‘users’: 3} creates 3 users # - a dict where more information regarding the contents of the entity # is required, e.g. {‘domains’ : {‘users : 3}} creates a domain # with three users # - a list of entity specifications if multiple are required # # The following creates a domain that contains a single user, group and # project, as well as creating three roles.
- ‘entities’: {‘domains’: {‘users’: 1, ‘groups’: 1, ‘projects’: 1},
‘roles’: 3},
# If it is required that an existing domain be used for the new # entities, then the id of that domain can be included in the # domain dict. For example, if alternatively we wanted to add 3 users # to the default domain, add a second domain containing 3 projects as # well as 5 additional empty domains, the entities would be defined as: # # ‘entities’: {‘domains’: [{‘id’: DEFAULT_DOMAIN, ‘users’: 3}, # {‘projects’: 3}, 5]}, # # A project hierarchy can be specified within the ‘projects’ section by # nesting the ‘project’ key, for example to create a project with three # sub-projects you would use:
‘projects’: {‘project’: 3}
# A more complex hierarchy can also be defined, for example the # following would define three projects each containing a # sub-project, each of which contain a further three sub-projects.
- ‘projects’: [{‘project’: {‘project’: 3}},
{‘project’: {‘project’: 3}}, {‘project’: {‘project’: 3}}]
# If the ‘roles’ entity count is defined as top level key in ‘entities’ # dict then these are global roles. If it is placed within the # ‘domain’ dict, then they will be domain specific roles. A mix of # domain specific and global roles are allowed, with the role index # being calculated in the order they are defined in the ‘entities’ # dict.
# A set of implied role specifications. In this case, prior role # index 0 implies role index 1, and role 1 implies roles 2 and 3.
- ‘roles’: [{‘role’: 0, ‘implied_roles’: [1]},
{‘role’: 1, ‘implied_roles’: [2, 3]}]
# A list of groups and their members. In this case make users with # index 0 and 1 members of group with index 0. Users and Groups are # indexed in the order they appear in the ‘entities’ key above.
‘group_memberships’: [{‘group’: 0, ‘users’: [0, 1]}]
# Next, create assignments between the entities, referencing the # entities by index, i.e. ‘user’: 0 refers to user[0]. Entities are # indexed in the order they appear in the ‘entities’ key above within # their entity type.
- ‘assignments’: [{‘user’: 0, ‘role’: 0, ‘domain’: 0},
{‘user’: 0, ‘role’: 1, ‘project’: 0}, {‘group’: 0, ‘role’: 2, ‘domain’: 0}, {‘user’: 0, ‘role’: 2, ‘project’: 0}],
# Finally, define an array of tests where list_role_assignment() is # called with the given input parameters and the results are then # confirmed to be as given in ‘results’. Again, all entities are # referenced by index.
- ‘tests’: [
- {‘params’: {},
- ‘results’: [{‘user’: 0, ‘role’: 0, ‘domain’: 0},
{‘user’: 0, ‘role’: 1, ‘project’: 0}, {‘group’: 0, ‘role’: 2, ‘domain’: 0}, {‘user’: 0, ‘role’: 2, ‘project’: 0}]},
- {‘params’: {‘role’: 2},
- ‘results’: [{‘group’: 0, ‘role’: 2, ‘domain’: 0},
{‘user’: 0, ‘role’: 2, ‘project’: 0}]}]
# The ‘params’ key also supports the ‘effective’, # ‘inherited_to_projects’ and ‘source_from_group_ids’ options to # list_role_assignments.}
-
create_assignments
(assignment_pattern, test_data)[source]¶ Create the assignments specified in the test plan.
-
create_entities
(entity_pattern)[source]¶ Create the entities specified in the test plan.
Process the ‘entities’ key in the test plan, creating the requested entities. Each created entity will be added to the array of entities stored in the returned test_data object, e.g.:
test_data[‘users’] = [user[0], user[1]….]
-
create_group_memberships
(group_pattern, test_data)[source]¶ Create the group memberships specified in the test plan.
-
create_implied_roles
(implied_pattern, test_data)[source]¶ Create the implied roles specified in the test plan.
-
execute_assignment_cases
(test_plan, test_data)[source]¶ Execute the test plan, based on the created test_data.
-
execute_assignment_plan
(test_plan)[source]¶ Create entities, assignments and execute the test plan.
The standard method to call to create entities and assignments and execute the tests as specified in the test_plan. The test_data dict is returned so that, if required, the caller can execute additional manual tests with the entities and assignments created.
-
class
keystone.tests.unit.assignment.test_backends.
AssignmentTests
[source]¶ Bases:
keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
-
test_delete_group_assignments_group_same_id_as_user
()[source]¶ Test deleting group assignments when group_id == user_id.
In this scenario, only group assignments must be deleted (i.e. GROUP_DOMAIN or GROUP_PROJECT).
Test plan: * Create a group and a user with the same ID; * Create four roles and assign them to both group and user; * Delete all group assignments; * User assignments must stay intact.
-
test_delete_user_assignments_user_same_id_as_group
()[source]¶ Test deleting user assignments when user_id == group_id.
In this scenario, only user assignments must be deleted (i.e. USER_DOMAIN or USER_PROJECT).
Test plan: * Create a user and a group with the same ID; * Create four roles and assign them to both user and group; * Delete all user assignments; * Group assignments must stay intact.
-
test_get_role_by_user_and_project_with_user_in_group
()[source]¶ Test for get role by user and project, user was added into a group.
Test Plan:
Create a user, a project & a group, add this user to group
Create roles and grant them to user and project
Check the role list get by the user and project was as expected
-
test_get_roles_for_groups_on_domain
()[source]¶ Test retrieving group domain roles.
Test Plan:
Create a domain, three groups and three roles
Assign one an inherited and the others a non-inherited group role to the domain
Ensure that only the non-inherited roles are returned on the domain
-
test_get_roles_for_groups_on_project
()[source]¶ Test retrieving group project roles.
Test Plan:
Create two domains, two projects, six groups and six roles
Project1 is in Domain1, Project2 is in Domain2
Domain2/Project2 are spoilers
Assign a different direct group role to each project as well as both an inherited and non-inherited role to each domain
Get the group roles for Project 1 - depending on whether we have enabled inheritance, we should either get back just the direct role or both the direct one plus the inherited domain role from Domain 1
-
test_get_roles_for_user_and_domain
()[source]¶ Test for getting roles for user on a domain.
Test Plan:
Create a domain, with 2 users
Check no roles yet exit
Give user1 two roles on the domain, user2 one role
Get roles on user1 and the domain - maybe sure we only get back the 2 roles on user1
Delete both roles from user1
Check we get no roles back for user1 on domain
-
test_get_roles_for_user_and_domain_returns_not_found
()[source]¶ Test errors raised when getting roles for user on a domain.
Test Plan:
Check non-existing user gives UserNotFound
Check non-existing domain gives DomainNotFound
-
test_grant_crud_throws_exception_if_invalid_role
()[source]¶ Ensure RoleNotFound thrown if role does not exist.
-
test_list_domains_for_groups
()[source]¶ Test retrieving domains for a list of groups.
Test Plan:
Create three domains, three groups and one role
Assign a non-inherited group role to two domains, and an inherited group role to the third
Ensure only the domains with non-inherited roles are returned
-
test_list_projects_for_groups
()[source]¶ Test retrieving projects for a list of groups.
Test Plan:
Create two domains, four projects, seven groups and seven roles
Project1-3 are in Domain1, Project4 is in Domain2
Domain2/Project4 are spoilers
Project1 and 2 have direct group roles, Project3 has no direct roles but should inherit a group role from Domain1
Get the projects for the group roles that are assigned to Project1 Project2 and the inherited one on Domain1. Depending on whether we have enabled inheritance, we should either get back just the projects with direct roles (Project 1 and 2) or also Project3 due to its inherited role from Domain1.
-
test_list_role_assignment_by_user_with_domain_group_roles
()[source]¶ Test listing assignments by user, with group roles on a domain.
-
test_list_role_assignment_does_not_contain_names
()[source]¶ Test names are not included with list role assignments.
- Scenario:
names are NOT included by default
names are NOT included when include_names=False
-
test_list_role_assignment_fails_with_userid_and_source_groups
()[source]¶ Show we trap this unsupported internal combination of params.
-
test_list_role_assignment_using_sourced_groups
()[source]¶ Test listing assignments when restricted by source groups.
-
test_list_role_assignment_using_sourced_groups_with_domains
()[source]¶ Test listing domain assignments when restricted by source groups.
-
test_list_role_assignments_filtered_by_role
()[source]¶ Test listing of role assignments filtered by role ID.
-
test_multi_group_grants_on_project_domain
()[source]¶ Test multiple group roles for user on project and domain.
Test Plan:
Create 6 roles
Create a domain, with a project, user and two groups
Make the user a member of both groups
Check no roles yet exit
Assign a role to each user and both groups on both the project and domain
Get a list of effective roles for the user on both the project and domain, checking we get back the correct three roles
-
-
class
keystone.tests.unit.assignment.test_backends.
ImpliedRoleTests
[source]¶ Bases:
keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
-
test_role_assignments_directed_graph_of_implied_roles
()[source]¶ Test that a role can have multiple, different prior roles.
-
test_role_assignments_implied_roles_filtered_by_role
()[source]¶ Test that you can filter by role even if roles are implied.
-
test_role_assignments_inherited_implied_roles
()[source]¶ Test that you can intermix inherited and implied roles.
-
-
class
keystone.tests.unit.assignment.test_backends.
InheritanceTests
[source]¶ Bases:
keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
-
test_inherited_role_grants_for_group
()[source]¶ Test inherited group roles.
Test Plan:
Enable OS-INHERIT extension
Create 4 roles
Create a domain, with a project, user and two groups
Make the user a member of both groups
Check no roles yet exit
Assign a direct user role to the project and a (non-inherited) group role on the domain
Get a list of effective roles - should only get the one direct role
Now add two inherited group roles to the domain
Get a list of effective roles - should have three roles, one direct and two by virtue of inherited group roles
-
test_inherited_role_grants_for_user
()[source]¶ Test inherited user roles.
Test Plan:
Enable OS-INHERIT extension
Create 3 roles
Create a domain, with a project and a user
Check no roles yet exit
Assign a direct user role to the project and a (non-inherited) user role to the domain
Get a list of effective roles - should only get the one direct role
Now add an inherited user role to the domain
Get a list of effective roles - should have two roles, one direct and one by virtue of the inherited user role
Also get effective roles for the domain - the role marked as inherited should not show up
-
test_list_effective_assignments_for_tree
()[source]¶ Test we correctly list effective assignments for a tree.
-
test_list_effective_assignments_for_tree_with_domain_assignments
()[source]¶ Test we correctly honor domain inherited assignments on the tree.
-
test_list_effective_assignments_for_tree_with_mixed_assignments
()[source]¶ Test that we correctly combine assignments for a tree.
In this test we want to ensure that when asking for a list of assignments in a subtree, any assignments inherited from above the subtree are correctly combined with any assignments within the subtree itself.
-
test_list_projects_for_user_with_inherited_grants
()[source]¶ Test inherited user roles.
Test Plan:
Enable OS-INHERIT extension
Create a domain, with two projects and a user
Assign an inherited user role on the domain, as well as a direct user role to a separate project in a different domain
Get a list of projects for user, should return all three projects
-
test_list_projects_for_user_with_inherited_group_grants
()[source]¶ Test inherited group roles.
Test Plan:
Enable OS-INHERIT extension
Create two domains, each with two projects
Create a user and group
Make the user a member of the group
Assign a user role two projects, an inherited group role to one domain and an inherited regular role on the other domain
Get a list of projects for user, should return both pairs of projects from the domain, plus the one separate project
-
test_list_projects_for_user_with_inherited_group_project_grants
()[source]¶ Test inherited role assignments for groups on nested projects.
Test Plan:
Enable OS-INHERIT extension
Create a hierarchy of projects with one root and one leaf project
Assign an inherited group role on root project
Assign a non-inherited group role on root project
Get a list of projects for user, should return both projects
Disable OS-INHERIT extension
Get a list of projects for user, should return only root project
-
test_list_projects_for_user_with_inherited_user_project_grants
()[source]¶ Test inherited role assignments for users on nested projects.
Test Plan:
Enable OS-INHERIT extension
Create a hierarchy of projects with one root and one leaf project
Assign an inherited user role on root project
Assign a non-inherited user role on root project
Get a list of projects for user, should return both projects
Disable OS-INHERIT extension
Get a list of projects for user, should return only root project
-
-
class
keystone.tests.unit.assignment.test_backends.
SystemAssignmentTests
[source]¶ Bases:
keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin