Organization and Tenant are great for grouping Identities, but they lead to an absolute democracy: everyone can do anything in this system. While utopia is still a mystery, let’s take a look at the governance of access: Authorization (AuthZ).
In the previous article, we introduced the concept of authentication (AuthN) and authorization (AuthZ), along with some headachy terms: Identity, Organization, Tenant, etc.
Organization and Tenant are great for grouping Identities, but they lead to an absolute democracy: everyone can do anything in this system. While utopia is still a mystery, let’s take a look at the governance of access: Authorization (AuthZ).
Notion is a great example. For each page you own, you can choose to keep it private, accessible only to you, or share it with friends, or even the public.
Or, for an online bookstore, you want everyone to be able to view all books, but customers to only view their own orders, and sellers to manage only the books in their stores.
AuthZ and AuthN are essential components of a complex business model. They often go hand-in-hand; AuthZ verifies a user's access, while AuthN authenticates identities. Both are necessary for a secure system.
Here’s one of the most common AuthZ models: If IDENTITY performs ACTION on RESOURCE, then ACCEPT or DENY.
In the Notion example, the model is PERSON performs VIEW on PAGE.
If the page is private:
Based on consensus, the industry developed various authorization technologies, such as Role-based Access Control (RBAC), Attribute-based Access Control (ABAC). Today, we will focus on the NIST RBAC model Level 1: Flat RBAC.
Let's extend the bookstore example. Say we have many customers, but only one seller:
In Logto, a resource (i.e. API Resource) usually represents a set of entities or items, since it’s required to use a valid URL as the indicator. Hence we define two resources:
https://api.bookstore.io/bookshttps://api.bookstore.io/ordersOne of the advantages of enforcing the URL format is it can map to a real address of your API service, which improves the readability and recognizability when integrating with other components in the system.
Since we introduced the concept of resource, in Logto, we also enforce that permissions must belong to a resource, in reverse, resources can have permissions.
Let’s add some permissions the the resources:
read, create, deleteread, read:self, create:self, deleteAlthough there’s no requirement of the name of a permission, we have the convention as below:
While <action> is required to describe a permission, :<target> can be ignored to describe a general target, i.e. to all entities or items in the resource. For example:
read in resource Books means the action to read arbitrary books.create:self in resource Orders means the action to create orders that belong to the current user.In short, a role is a group of permissions. Let’s create two roles customer and seller and assign permissions to them as below:
You may notice the permission-role assignment is many-to-many relations.
Just like role-permission assignment, user-role assignment is also a many-to-many relationship. Therefore, you can assign multiple roles to a single user, and a single role can be assigned to multiple users.
Here’s a complete relationship diagram for the Level 1 RBAC model in Logto:
In the RBAC model, permissions are always "positive", meaning the authorization judgement is simple: if a user has the permission, then accept; otherwise, reject.
Let's say Alice has the role seller, Bob and Carol have the role customer. We'll describe actions in natural language first, and transpile them to the standard authorization format: IDENTITY performs ACTION on RESOURCE, finally giving the conclusion.
create on resource Books (https://api.bookstore.io/books).create of Books according to their role seller, the result is ✅ ACCEPT.read on resource Orders (https://api.bookstore.io/orders).read of Orders according to their role seller, the result is ✅ ACCEPT.read on resource Books (https://api.bookstore.io/books).read of Books according to their role cusomter, the result is ✅ ACCEPT.read:self of Orders does not work here.read on resource Orders (https://api.bookstore.io/order).read of Orders, the result is ❌ DENY.There are four levels in the NIST RBAC model:
See the paper for details if you are interested.
Logto now has the Level 1 implementation and will progress to higher levels based on community feedback. Don’t hesitate to let us know if a higher level fits your need!
Beside the theory, we still have heavy technical works to complete in order to make the model work as expected:
Don’t panic. We've taken this into account and added out-of-the-box support to cover all of the above. Check out the 🔐 RBAC recipe to learn how to use RBAC in Logto.
RBAC is a powerful access management model for most cases, but there’s no silver bullet. We still have some questions: