Policy API: Enable admins to perform unsafe mutations on data in their platform

[jrschumacher]

Implement the unsafe mutation RPCs so that admins can have an audit trail when they need to make unsafe changes to their platform

Depends on

• Policy API: Enable admins to perform unsafe mutations on data in their platform #115

Acceptance Criteria

• Create an UnsafeService which captures the unsafe update RPC to empower platform admins
  • e.g. UnsafeService.UnsafeUpdateAttributeName()
  • e.g. UnsafeService.UnsafeDeleteAttribute()
• Every unsafe property should require passing a value that would provoke the user to question what they are doing or why the platform requires it

[jakedoublev]

Suggesting we add the following rpc's, which are also dangerous if a deactivation was intentional and restoration could give new access where it had previously been blocked (see discussion in 108)

• UnsafeService.RestoreDeactivatedNamespace()
• UnsafeService.RestoreDeletedAttribute()
• UnsafeService.RestoreDeletedAttributeValue()

They will intentionally not bubble up or cascade down to avoid unintended consequences. In other words, restoring a deactivated namespace will not restore any of its deactivated child attributes, and restoring an attribute will not restore any of its deactivated values.

[jakedoublev]

Along with those:

• UnsafeService.UpdateNamespace() // name is the only value that can be mutated and it should be dangerous to mutate
• UnsafeService.UpdateAttributeValue()

Any of these should be prevented and/or removed if currently implemented and reserved for specific calls by the unsafe service:

1. reactivation of any inactive state by update
2. mutation of attribute name via update
3. mutation of attribute value via update

[jakedoublev]

For future discussion

Scenario:
I create the following: namespace: namespace.com, attribute: attr-xyz on that namespace, value: value-123 on that attribute. I then deactivate attribute attr-xyz, which cascades down to value-123. Then I create value: value-456 on deactivated attribute attr-xyz. What is the API contract a PEP will need so that a subject mapping or resource mapping with that newly created active value value-456 on inactive attribute attr-xyz will be properly entitled/enforced?

Questions:

1. is creation/update of an attribute on a namespace that is inactive something to prevent?
2. likewise, is creation/update of an attribute value on an attribute that is inactive something to prevent?
3. is that a user error considered out of scope?
4. should we enable simple boolean rpc's on the resources that check their entire "validity chain" for active state? (i.e. getIsValidSubjectMapping which checks value -> attribute -> namespace for active state?

The goal is to prevent data loss and prevent a blocking experience via user error, but these flows probably need to be considered.

[jrschumacher]

With this work, we will need to see how to remain DRY in our DB funcs. The unsafe properties were removed in the update funcs for the time being.

[jakedoublev]

Unsafe updates should also include:

1. reactivation (probably without cascades, but could be discussed)
2. attribute definition update with full replacement of values order on an attribute (enabled by feat(policy): preserve values order within an attribute #496), which will require validation that the supplied list of value UUIDs contains only ids for values on that attribute and that the quantity includes all values under the definition (both active & inactive)

[jakedoublev]

Moved back to todo and unassigned myself as other priorities consistently took precedence this week.

[jakedoublev]

Namespaces

• reactivate (no cascade)
• update name (and fqn)
• delete (cascading)

Definitions

• reactivate (no cascade)
• update name (and fqn)
• update rule
• reorder values
• delete (cascading)

Values

• reactivate
• update value (and fqn)
• delete

[jakedoublev]

Out of scope: audit events for unsafe policy events, which will be handled in a separate issue to follow.