| --- |
| features: |
| - | |
| The ``requirements_authority`` module now supports the following 3 cases: |
| |
| * logical or operation of roles (existing functionality) |
| * logical and operation of roles (new functionality) |
| * logical not operation of roles (new functionality) |
| |
| .. code-block:: yaml |
| |
| <service_foo>: |
| <logical_or_example>: |
| - <allowed_role_1> |
| - <allowed_role_2> |
| <logical_and_example>: |
| - <allowed_role_3>, <allowed_role_4> |
| <service_bar>: |
| <logical_not_example>: |
| - <!disallowed_role_5> |
| |
| Each item under ``logical_or_example`` is "logical OR"-ed together. Each |
| role in the comma-separated string under ``logical_and_example`` is |
| "logical AND"-ed together. And each item prefixed with "!" under |
| ``logical_not_example`` is "logical negated". |
| |
| This allows for expressing many more complex cases using the |
| ``requirements_authority`` YAML syntax. For example, the policy rule |
| (i.e. what may exist in a ``policy.yaml`` file):: |
| |
| "foo_rule: (role:a and not role:b) or role:c" |
| |
| May now be expressed using the YAML syntax as:: |
| |
| foo_rule: |
| - a, !b |
| - c |