Comment 11 for bug 1818846

Reviewed: https://review.opendev.org/675807
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=0df8d0e2e1519154ec76100f7a4c2fdc8c9c04bb
Submitter: Zuul
Branch: master

commit 0df8d0e2e1519154ec76100f7a4c2fdc8c9c04bb
Author: Colleen Murphy <email address hidden>
Date: Sun Aug 11 21:06:36 2019 -0700

    Move list_trusts enforcement to default policies

    Without this change, policy enforcement for the GET /OS-TRUST/trusts API
    is hardcoded in the flask dispatcher code. This is a problem because
    this enforcement can't be controlled by the operator, as is the norm.
    Moreover, it makes the transition to system-scope and
    default-roles-aware policies more difficult because there's no sensible
    migration from "" to a logical role-based check string.

    This patch starts the conversion from hardcoded enforcement to
    enforcement via default policies for GET /OS-TRUST/trusts. To do this,
    we add two new policy rules, "identity:list_trusts_for_trustor" and
    "identity:list_trusts_for_trustee". We need to do this so that we can
    keep backwards compatibility with the bizarre behavior that an admin can
    list all trusts (GET /OS-TRUST/trusts) but not list trusts for a trustor
    or trustee (GET /OS-TRUST/trusts?trustor_user_id={} and
    GET/OS-TRUST/trusts?trustee_user_id={}). The tricky part is that it's
    plausible that operators may have incorporated the hardcoded empty
    default for "identity:list_trusts" into their on-disk policy
    configuration, either by never removing the old default policy file that
    used to come packaged with keystone, or by generating a sample file and
    applying that to disk (we don't recommend that but we don't expressly
    forbid or discourage it either). To overcome
    this, the trust API code checks whether the "identity:list_trusts" rule
    is "" and re-applies the enforcement with a warning. We don't need to do
    this for the two new policies because they are initially enforced
    in-code and an operator would have to take explicit action on upgrade to
    override them.

    This change does not use the formal oslo.policy deprecation system
    because "" OR'd with the new default is entirely useless as a policy.

    Partial-bug: #1818850
    Partial-bug: #1818846

    Change-Id: I6c1a4ecd756519f7f807c9d28960482e7f0d235b