Federated keystone mapping parsing doesn't work as documented

[John-Paul Robinson]

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.

[Ebrar Leblebici (birru2)]

Hi, I also had the same behavior in my test environment. To reproduce that I am attaching the bundle file and also the rules.json file that I used.