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_add_duplicate_role_grant()[source]¶

test_add_role_to_user_and_project_no_user()[source]¶

test_add_role_to_user_and_project_returns_not_found()[source]¶

test_add_user_to_project()[source]¶

test_add_user_to_project_missing_default_role()[source]¶

test_add_user_to_project_no_user()[source]¶

test_add_user_to_project_returns_not_found()[source]¶

test_create_grant_no_group()[source]¶

test_create_grant_no_user()[source]¶

test_del_role_assignment_by_domain_not_found()[source]¶

test_del_role_assignment_by_project_not_found()[source]¶

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_group_grant_no_group()[source]¶

test_delete_group_removes_role_assignments()[source]¶

test_delete_project_with_role_assignments()[source]¶

test_delete_role_check_role_grant()[source]¶

test_delete_role_returns_not_found()[source]¶

test_delete_role_with_user_and_group_grants()[source]¶

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_delete_user_grant_no_user()[source]¶

test_delete_user_with_project_association()[source]¶

test_delete_user_with_project_roles()[source]¶

test_get_and_remove_correct_role_grant_from_a_mix()[source]¶

test_get_and_remove_role_grant_by_group_and_cross_domain()[source]¶

test_get_and_remove_role_grant_by_group_and_domain()[source]¶

test_get_and_remove_role_grant_by_group_and_project()[source]¶

test_get_and_remove_role_grant_by_user_and_cross_domain()[source]¶

test_get_and_remove_role_grant_by_user_and_domain()[source]¶

test_get_project_user_ids_returns_not_found()[source]¶

test_get_role_assignment_by_domain_not_found()[source]¶

test_get_role_assignment_by_project_not_found()[source]¶

test_get_role_by_user_and_project()[source]¶

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_role_grant_by_user_and_project()[source]¶

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_get_roles_for_user_and_project_returns_not_found()[source]¶

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_group_role_assignment()[source]¶

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_projects_for_user()[source]¶

test_list_projects_for_user_with_grants()[source]¶

test_list_role_assignment_by_domain()[source]¶

Test listing of role assignment filtered by domain.

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_containing_names_domain_role()[source]¶

test_list_role_assignment_containing_names_global_role()[source]¶

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_bad_role()[source]¶

test_list_role_assignments_filtered_by_role()[source]¶

Test listing of role assignments filtered by role ID.

test_list_role_assignments_group_not_found()[source]¶

test_list_role_assignments_unfiltered()[source]¶

Test unfiltered listing of role assignments.

test_list_role_assignments_user_not_found()[source]¶

test_list_user_ids_for_project()[source]¶

test_list_user_ids_for_project_no_duplicates()[source]¶

test_list_user_project_ids_returns_not_found()[source]¶

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

test_multi_role_grant_by_user_group_on_project_domain()[source]¶

test_project_add_and_remove_user_role()[source]¶

test_remove_foreign_assignments_when_deleting_a_domain()[source]¶

test_remove_role_from_user_and_project()[source]¶

test_remove_role_grant_from_user_and_project()[source]¶

test_remove_user_from_project()[source]¶

test_remove_user_from_project_race_delete_role()[source]¶

test_remove_user_from_project_returns_not_found()[source]¶

test_remove_user_role_not_assigned()[source]¶

test_role_grant_by_group_and_cross_domain_project()[source]¶

test_role_grant_by_user_and_cross_domain_project()[source]¶

test_update_role_no_name()[source]¶

test_update_role_same_name()[source]¶

class keystone.tests.unit.assignment.test_backends.ImpliedRoleTests[source]¶

Bases: keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin

test_circular_inferences()[source]¶

Test that implied roles are expanded out.

test_delete_implied_role_returns_not_found()[source]¶

test_implied_role_crd()[source]¶

test_role_assignments_directed_graph_of_implied_roles()[source]¶

Test that a role can have multiple, different prior roles.

test_role_assignments_domain_specific_with_implied_roles()[source]¶

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.

test_role_assignments_simple_tree_of_implied_roles()[source]¶

Test that implied roles are expanded out.

test_role_assignments_simple_tree_of_implied_roles_on_domain()[source]¶

Test that implied roles are expanded out when placed on a domain.

class keystone.tests.unit.assignment.test_backends.InheritanceTests[source]¶

Bases: keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin

test_crud_inherited_and_direct_assignment_for_group_on_domain()[source]¶

test_crud_inherited_and_direct_assignment_for_group_on_project()[source]¶

test_crud_inherited_and_direct_assignment_for_user_on_domain()[source]¶

test_crud_inherited_and_direct_assignment_for_user_on_project()[source]¶

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_assignments_for_tree()[source]¶

Test we correctly list direct assignments for a tree.

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

test_list_role_assignment_using_inherited_sourced_groups()[source]¶

Test listing inherited assignments when restricted by groups.

test_list_user_ids_for_project_with_inheritance()[source]¶

test_role_assignments_user_domain_to_project_inheritance()[source]¶

keystone.tests.unit.assignment.test_core module¶

class keystone.tests.unit.assignment.test_core.RoleTests[source]¶

Bases: object

test_cache_layer_role_crud(*args, **kwargs)[source]¶

test_create_duplicate_role_name_fails()[source]¶

test_get_role_returns_not_found()[source]¶

test_list_roles()[source]¶

test_rename_duplicate_role_name_fails()[source]¶

test_role_crud()[source]¶

test_update_role_returns_not_found()[source]¶

Module contents¶