yahoo-eng-team team mailing list archive

[John-Paul Robinson <2009752@xxxxxxxxxxxxxxxxxx>]

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