Public bug reported: The documentation for federated keystone doesn't match the coded behavior. The documentation states that keystone processes the mapping rules and stops after the first match.
https://docs.openstack.org/keystone/zed/admin/federation/mapping_combinations.html#how- mappings-are-processed "A mapping is selected by IdP and protocol. Then keystone takes the mapping and processes each rule sequentially stopping after the first matched rule. A rule is matched when all of its conditions are met." The code for rules processing steps through all the rules and doesn't stop after the first match. All rules that have matching remote clauses will be processed. https://opendev.org/openstack/keystone/src/commit/c08d97672dcd40f8d927f91e59049053cfe3b5e4/keystone/federation/utils.py#L541 For the documented behavior of first-match-then-out, it seems like a break at the end of the loop would be needed. Furthermore, there is an additional bug in the processing of the "projects" rules where the intended use of a projects array is replaced by an assignment to a scalar. This causes a local rule stanza with multiple projects to only record the last project in the list. https://opendev.org/openstack/keystone/src/commit/c08d97672dcd40f8d927f91e59049053cfe3b5e4/keystone/federation/utils.py#L708 These two bugs create a scenario where the final local rule set is the combined local clause of all matching rules in the mapping and that the assigned project (and project role) is exclusively the last project in the list of projects, rather then a combination of all the projects in the list. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/2009752 Title: Federated keystone mapping parsing doesn't work as documented Status in OpenStack Identity (keystone): New Bug description: The documentation for federated keystone doesn't match the coded behavior. The documentation states that keystone processes the mapping rules and stops after the first match. https://docs.openstack.org/keystone/zed/admin/federation/mapping_combinations.html#how- mappings-are-processed "A mapping is selected by IdP and protocol. Then keystone takes the mapping and processes each rule sequentially stopping after the first matched rule. A rule is matched when all of its conditions are met." The code for rules processing steps through all the rules and doesn't stop after the first match. All rules that have matching remote clauses will be processed. https://opendev.org/openstack/keystone/src/commit/c08d97672dcd40f8d927f91e59049053cfe3b5e4/keystone/federation/utils.py#L541 For the documented behavior of first-match-then-out, it seems like a break at the end of the loop would be needed. Furthermore, there is an additional bug in the processing of the "projects" rules where the intended use of a projects array is replaced by an assignment to a scalar. This causes a local rule stanza with multiple projects to only record the last project in the list. https://opendev.org/openstack/keystone/src/commit/c08d97672dcd40f8d927f91e59049053cfe3b5e4/keystone/federation/utils.py#L708 These two bugs create a scenario where the final local rule set is the combined local clause of all matching rules in the mapping and that the assigned project (and project role) is exclusively the last project in the list of projects, rather then a combination of all the projects in the list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/2009752/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
