Access Control

Speaker 0: Access control is a critical part of managing data. What different users in their various roles and responsibilities should be able to create, read, update, delete and share. Directus auth along with Directus' access control provide a complete solution for user management. From initial registration, through to interacting with data held in your project. In side of a directors project, you will have 1 or more users.

A user conceptually is just one item in a special directors users collection, that represents a person or a service that has access to your data. Users may only be able to access your data via API or your custom application but can also be given access to data via the data studio web application. You can invite users, enable public registration or create users via API from your own application. Directus auth provides all of the required end points to manage users. From generating and refreshing access tokens, checking permissions, resetting passwords and more.

Directus can fully manage your users or you can connect it with an existing single sign on provider to use the existing accounts to authenticate with directus. But that's all authentication, Let's talk about access control. The first concept is the permission itself. A permission is a combination of a collection, an action such as create or update, and either allow all or custom rules. By default, all actions on all collections are denied, and you can add access by creating permissions.

Allow all is self explanatory, but for each action in each collection, custom rules can be created, which use Directus' filter syntax to specify which items can be interacted with. For example, only items created by the current user. You can also apply custom rules to limit which fields in a collection a user can access. So you might allow certain roles to edit data and others to only see it. Now given a permission is just a single action on a single collection, a user is likely to have many of them.

And to organize them, we create access policies. And an access policy is just that, a set of permissions. For example, you might have a policy called manage own posts and use it to group the edit and delete permissions on posts created by the current user. Now roles describe a user's position within a team. For example, marketing team or editors.

You can add roles to other roles allowing for a cascade that describes someone's full position and all that they will inherit. Now policies can be attached to either roles or users, making them a flexible organization tool for permissions. Any user's overall set of permissions are just an aggregate of all of the policies that are attached to them or their role. Now there are a lot of use case specific nuance to how access control could be configured. But just remember that a policy is a set of permissions, and policy can be attached to either a user or a role.

Hopefully, you found this useful. Feel free to reach out with any questions, and we'll see you in the next video.