Skip to main content

Policies

Policies and functions

Typegraphs allow you to specify granular access control when exposing your functions. This can be done at the function or the type field level. This section also makes use of toy typegraph for the sake of clarity.

Policy based access control (PBAC)​

The Deno runtime enable to understand the last abstraction. Policies are a way to verify for each type whether the user is authorized or not to access it. It's a very powerful concept that can be for instance used to guarantee a given type is never accidentally exposed to the outside world.

Metatype comes with some built-in policies, but you can use the Deno runtime to define your own:

  • policies.public() is an alias for deno.policy("public", "() => 'PASS'") providing everyone open access while still allowing field level custom access.
  • Policy.context("role_value", "role_field") is a companion policy for the authentication strategy you learned in the previous section. It will verify the context and give adequate access to the user.

Policies are hierarchical in the sense that the request starts with a denial, and the root functions must explicitly provide an access or not. Once access granted, any further types can either inherit or override the access. Policies evaluate in order in case multiple ones are defined.

Loading...

Composition rules​

Traversal order​

  • ALLOW: Allows access to the parent and all its descendants, disregarding inner policies.
  • DENY: Denies access to the parent and all its descendants, disregarding inner policies.
  • PASS: Allows access to the parent, each descendant will still be evaluated individually (equivalent to having no policies set).

Chaining policies​

If you have foo.with_policy(A, B).with_policy(C) for example, it will evaluated in batch as [A, B, C].

If one or more policies fail (DENY), the type will be inaccessible.