Skip to content

Validation YAML should support reusing the subject list from one validation in another #516

@hermannloose

Description

@hermannloose

We are liking the exhaustive checks performed for any validations entries in a validation YAML, to ensure more complex policies work exactly as intended (which assertTrue and assertFalse don't guarantee unless we are very diligent), however they can become verbose quickly, even for fairly minimal sets of test relationships.

Consider the following schema:

definition user {}

definition organization {
  relation member: user

  permission all = member
}

definition supplier {
  relation organization: organization
  relation contact: contact

  permission read = contact + organization->all
  permission invite = contact + organization->all
}

definition contact {
  relation organization: organization
  relation supplier: supplier
  relation self: contact

  permission read = self + supplier->read
  permission update = self + organization->all
}

contact models an external user, attached to a supplier, who has read access to that supplier and can see all other contacts on that supplier, as well as invite new contacts (which will be attached to the same supplier).

Assume that the schema is a bit more complex still, with e.g. an admin and a super-admin role, which for most of the cases work like normal organization members, but it would mean we have for example the following test relationships:

relationships: |-
  organization:acme#member@user:acme-user
  organization:acme#member@user:acme-admin
  organization:acme#member@user:acme-support
  supplier:globex#organization@organization:acme
  supplier:globex#contact@contact:globex-rep
  supplier:initech#organization@organization:acme
  supplier:initech#contact@contact:initech-rep
  contact:globex-rep#organization@organization:acme
  contact:globex-rep#supplier@supplier:globex
  contact:initech-rep#organization@organization:acme
  contact:initech-rep#supplier@supplier:initech

We would like to be able to do some equivalent of the following:

validations:
  organization:acme#all: &acme-all
    - "[user:acme-user] is <organization:acme#member>"
    - "[user:acme-admin] is <organization:acme#member>"
    - "[user:acme-support] is <organization:acme#member>"
  supplier:globex#edit:
    - "[contact:globex-rep] is <supplier:globex#contact>"
    <<: *acme-all # not supported natively in YAML, unfortunately
  supplier:initech#edit:
    - "[contact:initech-rep] is <supplier:initech#contact>"
    <<: *acme-all
  ...

Essentially, we still want to get alerted if access is unexpectedly wider or narrower than expected, but have a shorthand for a list of subjects that occur all over the place; this will quickly become quite verbose if we want to validate for example that two contacts from globex can update themselves but not the other contact etc. making it hard to quickly spot the important bits.

What we could also imagine, but what doesn't seem to be supported at the moment (or we are holding it wrong):

validations:
  organization:acme#all:
    - "[user:acme-user] is <organization:acme#member>"
    - "[user:acme-admin] is <organization:acme#member>"
    - "[user:acme-support] is <organization:acme#member>"
  supplier:globex#edit:
    - "[contact:globex-rep] is <supplier:globex#contact>"
    - "[organization:acme#member]"
  supplier:initech#edit:
    - "[contact:initech-rep] is <supplier:initech#contact>"
    - "[organization:acme#member]"
  ...

or more explicitly, by having a type union of ValidationString and something else:

validations:
  organization:acme#all:
    - "[user:acme-user] is <organization:acme#member>"
    - "[user:acme-admin] is <organization:acme#member>"
    - "[user:acme-support] is <organization:acme#member>"
  supplier:globex#edit:
    - "[contact:globex-rep] is <supplier:globex#contact>"
    - all_from: "[organization:acme#all]"
  supplier:initech#edit:
    - "[contact:initech-rep] is <supplier:initech#contact>"
    - all_from: "[organization:acme#all]"
  ...

which could verify that the key referenced in all_from does actually occur somewhere in validations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions