Federated keystone mapping parsing doesn't work as documented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Confirmed
|
Undecided
|
Unassigned |
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.
"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.
For the documented behavior of first-match-
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.
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.
Changed in keystone: | |
status: | New → Confirmed |
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.