Hasura Authorization

Introduction

Authorization determines what a verified user can access.

You can define permissions (also known as access control or authorization rules) on output types, models, and commands in your data domain.

There are three forms of permissions:

• Type Permissions: Define which fields within an ObjectType can be accessed by a particular role.
• Model Permissions: Define which rows of a Model can be accessed by a particular role.
• Command Permissions: Define if a Command can be executed by a particular role.

A role comes into existence when it is defined in one of these three ways.

Every request to Hasura should carry the necessary session variables or roles from your authentication service. The presence and values of these roles determine which permissions apply to the request. There is no longer the concept of a built-in, default, super-user admin role in Hasura DDN. You can however set up role emulation in order to test your permissions with another role.

Hasura's roles and permissions are implemented at the Hasura Engine layer. They have no direct relationship to any data source users and roles.

Examples

For examples of authorization permissions in metadata, see the permissions page in the Supergraph modeling section.

Testing Permissions

You can test permissions directly in the Hasura Console's API interface:

1. Define the desired permissions for a particular type, model, or command in your metadata.
2. Ensure you have role emulation enabled for a particular role, say api_admin.
3. Make a request through the Hasura DDN Console GraphiQL API interface (with an auth token that resolves to the api_admin role) and set the test required session variables as request headers (e.g. x-hasura-role, x-hasura-user-id, etc.).
4. Check the returned data to ensure it adheres to your permission configurations.