Bases: object
Mixin class to aid testing of assignments.
This class supports data driven test plans that enable:
A test plan is a dict of the form:
An example 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.
# 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.
# 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.
# 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.
# The ‘params’ key also supports the ‘effective’, # ‘inherited_to_projects’ and ‘source_from_group_ids’ options to # list_role_assignments.}
Create the assignments specified in the test plan.
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 the group memberships specified in the test plan.
Create the implied roles specified in the test plan.
Execute the test plan, based on the created test_data.
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.
Bases: keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
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 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 for get role by user and project, user was added into a group.
Test Plan:
Test retrieving group domain roles.
Test Plan:
Test retrieving group project roles.
Test Plan:
Test for getting roles for user on a domain.
Test Plan:
Test errors raised when getting roles for user on a domain.
Test Plan:
Ensure RoleNotFound thrown if role does not exist.
Test retrieving domains for a list of groups.
Test Plan:
Test retrieving projects for a list of groups.
Test Plan:
Test listing assignments by user, with group roles on a domain.
Test names are not included with list role assignments.
Show we trap this unsupported internal combination of params.
Test listing assignments when restricted by source groups.
Test listing domain assignments when restricted by source groups.
Test listing of role assignments filtered by role ID.
Test multiple group roles for user on project and domain.
Test Plan:
Bases: keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
Test that a role can have multiple, different prior roles.
Test that you can filter by role even if roles are implied.
Test that you can intermix inherited and implied roles.
Bases: keystone.tests.unit.assignment.test_backends.AssignmentTestHelperMixin
Test inherited group roles.
Test Plan:
Test inherited user roles.
Test Plan:
Test we correctly list effective assignments for a tree
Test we correctly honor domain inherited assignments on the tree
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 inherited user roles.
Test Plan:
Test inherited group roles.
Test Plan:
Test inherited role assignments for groups on nested projects.
Test Plan:
Test inherited role assignments for users on nested projects.
Test Plan: