What is access control?

Speaker 0: Hey, developers. And welcome to authentication Avenue. Today, we're going to explore access control. How systems decide what different users can and can't do. It's like having a clever set of rules that keep everything organized and secure.

Imagine you're at a huge museum. When you enter, everyone gets a different colored badge. Red badges are for the curators who can do everything. Blue badges are for the tour guides who can enter public areas. Green badges are for the cleaning staff who can access maintenance areas.

And yellow badges are for visitors who can only view exhibits. But it gets even more specific because each badge has special symbols that show exactly what you can do. For example, looking at exhibits, that is the read permission. Creating new displays, that's the create permission. Rearranging exhibits, that's the update permission.

And finally, removing displays, that's the delete permission. And here's where it gets interesting. Some staff members might only be allowed to change exhibits that they created themselves. Like a junior curator who can only modify their own displays, but not anyone else's. In the tech world, we call this ownership based access.

Now in Directus, this system is handled through roles, permissions, and policies. Roles are like your colored badges, the broad category you belong to. Permissions are a single rule. For example, what collections you can access or what CRUD operations, that's create, read, update, and delete operations, you can perform. Custom permissions like only view published articles and whether you can only work with items you created, and policies are bundles of permissions that can be applied to either roles or individual users.

Think of them as rule packages. For example, a content editor role might have policies that allow them to read all articles, create new articles, but only update their own articles, and a content editor might never delete anything or not have the permissions to delete anything. What's cool about policies is their flexibility. You can create one policy, like basic content management, and apply it to both the junior editor role and specific users who need those permissions. It's like creating a standardized set of rules once and then using them wherever you need them.

So, remember, access control isn't just about yes or no, it's about who can do what, where, and under what conditions. Next up, we'll see how to configure these permissions in Directus. Here we have a posts collection with a field denoting the author. This is a many to one relationship with the director's users collection, and what this means is that each one of these represents a user in our project that could authenticate with this project. So here we see this one is authored by Beth, 2 by me, and 1 by Carmen.

Now we have an access policy here, which denotes how users can interact with the posts collection. Now remember, the public do not have access to this collection. Instead, we say that users who have this policy applied to them can partially read. We say that they can only read items where they are the author, and we do that using this dynamic variable here called current user, and the value of this will change depending on the currently authenticated user. Exactly the same with update and the same with delete.

This policy is attached to the member role, which in turn is assigned to Beth, Carmen, and Mike. My user is an admin. So let's see how this works in practice. So here we see we are trying to access the posts collection with no authentication, and we hit send. And as expected, we get a 403 error, which means forbidden, you don't have access to this, or it does not exist.

As an admin, if I put in an admin token here, we see that we can access all posts. We see there is an author here beginning with 18b and an author here beginning with be8, and that is because admins have full CRUD access, create, read, update, and delete over all collections in the project. This is the exact same request, but with Beth's token, and we see here that if we hit send, we now only get one item returned. In turn, Beth can only update this item or delete this item, but not those created by other users. This is really nice because it means access control is set up and controlled by directus, which means you cannot inadvertently access data that you're not allowed to in your own application because it's all handled at a direct us level.

So that's just a quick example of how access control works inside of Directus. I will see you next time on Authentication Avenue.