| Mykola Yakovliev | d02a8d8 | 2018-10-30 21:35:20 -0500 | [diff] [blame] | 1 | --- |
| 2 | features: |
| 3 | - | |
| 4 | The ``requirements_authority`` module now supports the following 3 cases: |
| 5 | |
| 6 | * logical or operation of roles (existing functionality) |
| 7 | * logical and operation of roles (new functionality) |
| 8 | * logical not operation of roles (new functionality) |
| 9 | |
| 10 | .. code-block:: yaml |
| 11 | |
| 12 | <service_foo>: |
| 13 | <logical_or_example>: |
| 14 | - <allowed_role_1> |
| 15 | - <allowed_role_2> |
| 16 | <logical_and_example>: |
| 17 | - <allowed_role_3>, <allowed_role_4> |
| 18 | <service_bar>: |
| 19 | <logical_not_example>: |
| 20 | - <!disallowed_role_5> |
| 21 | |
| 22 | Each item under ``logical_or_example`` is "logical OR"-ed together. Each |
| 23 | role in the comma-separated string under ``logical_and_example`` is |
| 24 | "logical AND"-ed together. And each item prefixed with "!" under |
| 25 | ``logical_not_example`` is "logical negated". |
| 26 | |
| 27 | This allows for expressing many more complex cases using the |
| 28 | ``requirements_authority`` YAML syntax. For example, the policy rule |
| 29 | (i.e. what may exist in a ``policy.yaml`` file):: |
| 30 | |
| 31 | "foo_rule: (role:a and not role:b) or role:c" |
| 32 | |
| 33 | May now be expressed using the YAML syntax as:: |
| 34 | |
| 35 | foo_rule: |
| 36 | - a, !b |
| 37 | - c |