keystone.tests.unit.contrib.federation package¶

Submodules¶

keystone.tests.unit.contrib.federation.test_utils module¶

class keystone.tests.unit.contrib.federation.test_utils.MappingRuleEngineTests(*args, **kwargs)[source]¶

Bases: keystone.tests.unit.core.BaseTestCase

A class for testing the mapping rule engine.

assertValidMappedUserObject(mapped_properties, user_type=’ephemeral’, domain_id=None)[source]¶

Check whether mapped properties object has ‘user’ within.

According to today’s rules, RuleProcessor does not have to issue user’s id or name. What’s actually required is user’s type and for ephemeral users that would be service domain named ‘Federated’.

test_local_user_local_domain()[source]¶

Test that local users can have non-service domains assigned.

test_mapping_federated_domain_specified()[source]¶

Test mapping engine when domain ‘ephemeral’ is explicitly set.

For that, we use mapping rule MAPPING_EPHEMERAL_USER and assertion EMPLOYEE_ASSERTION

test_mapping_projects()[source]¶

test_mapping_validataion_no_remote()[source]¶

test_mapping_validation_bad_domain()[source]¶

test_mapping_validation_bad_group()[source]¶

test_mapping_validation_no_local()[source]¶

test_mapping_validation_no_type()[source]¶

test_mapping_validation_with_group_id_and_domain()[source]¶

test_mapping_validation_with_group_name_and_domain()[source]¶

test_mapping_validation_with_group_name_without_domain()[source]¶

test_mapping_validation_with_incorrect_local_keys()[source]¶

test_mapping_validation_with_user_id_and_domain_id()[source]¶

test_mapping_validation_with_user_name_and_domain_id()[source]¶

test_mapping_validation_with_user_name_and_domain_name()[source]¶

test_rule_engine_any_one_of_and_direct_mapping()[source]¶

Should return user’s name and group id EMPLOYEE_GROUP_ID.

The ADMIN_ASSERTION should successfully have a match in MAPPING_LARGE. They will test the case where any_one_of is valid, and there is a direct mapping for the users name.

test_rule_engine_any_one_of_many_rules()[source]¶

Should return group CONTRACTOR_GROUP_ID.

The CONTRACTOR_ASSERTION should successfully have a match in MAPPING_SMALL. This will test the case where many rules must be matched, including an any_one_of, and a direct mapping.

test_rule_engine_blacklist_and_direct_groups_mapping()[source]¶

Should return user’s group Developer.

The EMPLOYEE_ASSERTION_MULTIPLE_GROUPS should successfully have a match in MAPPING_GROUPS_BLACKLIST. It will test the case where ‘blacklist’ correctly filters out Manager and Developer and only allows Contractor.

test_rule_engine_blacklist_and_direct_groups_mapping_multiples()[source]¶

Test matching multiple values before the blacklist.

Verifies that the local indexes are correct when matching multiple remote values for a field when the field occurs before the blacklist entry in the remote rules.

test_rule_engine_blacklist_direct_group_mapping_missing_domain()[source]¶

Test if the local rule is rejected upon missing domain value.

This is a variation with a blacklist filter.

test_rule_engine_discards_nonstring_objects()[source]¶

Check whether RuleProcessor discards non string objects.

Despite the fact that assertion is malformed and contains non string objects, RuleProcessor should correctly discard them and successfully have a match in MAPPING_LARGE.

test_rule_engine_fails_after_discarding_nonstring()[source]¶

Check whether RuleProcessor discards non string objects.

Expect RuleProcessor to discard non string object, which is required for a correct rule match. RuleProcessor will result with ValidationError.

test_rule_engine_group_ids_mapping_blacklist()[source]¶

Test mapping engine when group_ids is explicitly set.

Also test blacklists on group ids

test_rule_engine_group_ids_mapping_only_one_group()[source]¶

Test mapping engine when group_ids is explicitly set.

If the group ids list has only one group, test if the transformation is done correctly

test_rule_engine_group_ids_mapping_whitelist()[source]¶

Test mapping engine when group_ids is explicitly set.

Also test whitelists on group ids

test_rule_engine_groups_mapping_only_one_group()[source]¶

Test mapping engine when groups is explicitly set.

If the groups list has only one group, test if the transformation is done correctly

test_rule_engine_no_groups_allowed()[source]¶

Should return user mapped to no groups.

The EMPLOYEE_ASSERTION should successfully have a match in MAPPING_GROUPS_WHITELIST, but ‘whitelist’ should filter out the group values from the assertion and thus map to no groups.

test_rule_engine_no_regex_match()[source]¶

Should deny authorization, the email of the tester won’t match.

This will not match since the email in the assertion will fail the regex test. It is set to match any @example.com address. But the incoming value is set to eviltester@example.org. RuleProcessor should raise ValidationError.

test_rule_engine_not_any_of_and_direct_mapping()[source]¶

Should return user’s name and email.

The CUSTOMER_ASSERTION should successfully have a match in MAPPING_LARGE. This will test the case where a requirement has not_any_of, and direct mapping to a username, no group.

test_rule_engine_not_any_of_many_rules()[source]¶

Should return group EMPLOYEE_GROUP_ID.

The EMPLOYEE_ASSERTION should successfully have a match in MAPPING_SMALL. This will test the case where many remote rules must be matched, including a not_any_of.

test_rule_engine_not_any_of_regex_verify_fail()[source]¶

Should deny authorization.

The email in the assertion will fail the regex test. It is set to reject any @example.org address, but the incoming value is set to evildeveloper@example.org. RuleProcessor should yield ValidationError.

test_rule_engine_not_any_of_regex_verify_pass()[source]¶

Should return group DEVELOPER_GROUP_ID.

The DEVELOPER_ASSERTION should successfully have a match in MAPPING_DEVELOPER_REGEX. This will test the case where many remote rules must be matched, including a not_any_of, with regex set to True.

test_rule_engine_regex_many_groups()[source]¶

Should return group CONTRACTOR_GROUP_ID.

The TESTER_ASSERTION should successfully have a match in MAPPING_TESTER_REGEX. This will test the case where many groups are in the assertion, and a regex value is used to try and find a match.

test_rule_engine_regex_match_and_many_groups()[source]¶

Should return group DEVELOPER_GROUP_ID and TESTER_GROUP_ID.

The TESTER_ASSERTION should successfully have a match in MAPPING_LARGE. This will test a successful regex match for an any_one_of evaluation type, and will have many groups returned.

test_rule_engine_returns_group_names()[source]¶

Check whether RuleProcessor returns group names with their domains.

RuleProcessor should return ‘group_names’ entry with a list of dictionaries with two entries ‘name’ and ‘domain’ identifying group by its name and domain.

test_rule_engine_whitelist_and_direct_groups_mapping()[source]¶

Should return user’s groups Developer and Contractor.

The EMPLOYEE_ASSERTION_MULTIPLE_GROUPS should successfully have a match in MAPPING_GROUPS_WHITELIST. It will test the case where ‘whitelist’ correctly filters out Manager and only allows Developer and Contractor.

test_rule_engine_whitelist_direct_group_mapping_missing_domain()[source]¶

Test if the local rule is rejected upon missing domain value.

This is a variation with a whitelist filter.

test_set_ephemeral_domain_to_ephemeral_users()[source]¶

Test auto assigning service domain to ephemeral users.

Test that ephemeral users will always become members of federated service domain. The check depends on type value which must be set to ephemeral in case of ephemeral user.

test_type_not_in_assertion()[source]¶

Test that if the remote “type” is not in the assertion it fails.

test_user_identification_id()[source]¶

Test varius mapping options and how users are identified.

This test calls mapped.setup_username() for propagating user object.

Test plan: - Check if the user has proper domain (‘federated’) set - Check if the user has propert type set (‘ephemeral’) - Check if user’s display_name is properly set and equal to unique_id, as it was not explicitly specified in the mapping.

test_user_identification_id_and_name()[source]¶

Test varius mapping options and how users are identified.

This test calls mapped.setup_username() for propagating user object.

Test plan: - Check if the user has proper domain (‘federated’) set - Check if the user has proper type set (‘ephemeral’) - Check if display_name is properly set from the assertion - Check if unique_id is properly set and equal to value hardcoded in the mapping

This test does two iterations with different assertions used as input for the Mapping Engine. Different assertions will be matched with different rules in the ruleset, effectively issuing different user_id (hardcoded values). In the first iteration, the hardcoded user_id is not url-safe and we expect Keystone to make it url safe. In the latter iteration, provided user_id is already url-safe and we expect server not to change it.

test_user_identifications_name()[source]¶

Test varius mapping options and how users are identified.

This test calls mapped.setup_username() for propagating user object.

Test plan: - Check if the user has proper domain (‘federated’) set - Check if the user has property type set (‘ephemeral’) - Check if user’s name is properly mapped from the assertion - Check if unique_id is properly set and equal to display_name, as it was not explicitly specified in the mapping.

test_user_identifications_name_and_federated_domain()[source]¶

Test varius mapping options and how users are identified.

This test calls mapped.setup_username() for propagating user object.

Test plan: - Check if the user has proper domain (‘federated’) set - Check if the user has propert type set (‘ephemeral’) - Check if user’s name is properly mapped from the assertion - Check if the unique_id and display_name are properly set

test_using_remote_direct_mapping_that_doesnt_exist_fails()[source]¶

Test for the correct error when referring to a bad remote match.

The remote match must exist in a rule when a local section refers to a remote matching using the format (e.g. {0} in a local section).

test_whitelist_pass_through()[source]¶

class keystone.tests.unit.contrib.federation.test_utils.TestMappingLocals(*args, **kwargs)[source]¶

Bases: keystone.tests.unit.core.BaseTestCase

assertion = {‘idp_username’: ‘a_user’}¶

mapping_combined = {‘rules’: [{‘local’: [{‘group’: {‘id’: ‘d34db33f’}, ‘user’: {‘name’: ‘{0}’}}], ‘remote’: [{‘type’: ‘idp_username’}]}]}¶

mapping_split = {‘rules’: [{‘local’: [{‘user’: {‘name’: ‘{0}’}}, {‘group’: {‘id’: ‘d34db33f’}}], ‘remote’: [{‘type’: ‘idp_username’}]}]}¶

mapping_with_duplicate = {‘rules’: [{‘local’: [{‘user’: {‘name’: ‘test_{0}’}}, {‘user’: {‘name’: ‘{0}’}}], ‘remote’: [{‘type’: ‘idp_username’}]}]}¶

process(rules)[source]¶

test_local_list_gets_squashed_into_a_single_dictionary()[source]¶

test_when_local_list_gets_squashed_first_dict_wins()[source]¶

class keystone.tests.unit.contrib.federation.test_utils.TestUnicodeAssertionData(*args, **kwargs)[source]¶

Bases: keystone.tests.unit.core.BaseTestCase

Ensure that unicode data in the assertion headers works.

Bug #1525250 reported that something was not getting correctly encoded and/or decoded when assertion data contained non-ASCII characters.

This test class mimics what happens in a real HTTP request.

setUp()[source]¶

test_unicode()[source]¶

Module contents¶