What is Fine-Grained Authorization?

Fine-grained authorization (FGA) is a tricky thing to define.  The term “fine-grained” only has meaning in comparison to something else that is “coarse-grained.” Does it mean you have a lot of different roles? Or that you support a lot of permissions? Test a lot of conditions? What’s “a lot,” anyway? Luckily, this isn’t a dictionary, so let's skip the definition. It’s more useful to illustrate it.

Coarse Authorization Logic

Many applications start with simple authorization requirements. Here are a couple examples:

A multitenant application needs to support three types of user.

• A member can use standard features.
• An administrator can configure a single organization.
• A global administrator can manage settings that affect all organizations.

You can support this logic with Role-Based Access Control (RBAC). Assign a user a role that  corresponds to one of the three user types, and they get access to that role’s capabilities.

A document sharing application lets users store files in a folder hierarchy.

A user should only have access to files in the same organization they belong to. You can support this logic with Relationship-Based Access Control (ReBAC). You need to know two relationships:

• What organization a user is in
• What organization owns the root folder for a given file

If a user and a file belong to the same organization, the user can access the file.

These are examples of coarse authorization logic. The permissions are blunt. You can administer an organization or you can’t. You have access to a document or you don’t. You can assign those permissions by making a single type of comparison: a user’s role, or the relationships between entities.

Fine-grained Authorization Logic

Over time, applications become more sophisticated. Their authorization requirements reflect this.

You add a Customer Service role to the multitenant application.

The Customer Service role can impersonate users to make troubleshooting easier. Abuse of that feature could cause significant harm, so you want to restrict it. You decide that someone may impersonate a user only under the following conditions:

• They are on the Customer Service team and
• They have the impersonator role and
• They are in the same geographical region as the customer and
• It is during their work hours

You want more specific permissions in the document sharing application.

Users want to be able to more precisely define who can do what with a document. They also want to be able to share documents with people outside of their organization. You decide to support the following permissions on a file:

• read
• write
• delete
• share
• change visibility (public or private)
• transfer ownership

These new authorization requirements no longer fit neatly into a model like RBAC or ReBAC. They combine elements of both, as well as attributes of resources and of the surrounding environment (this is called Attribute-based Access Control, or ABAC).

Fine-grained authorization refers to this kind of logic, which incorporates elements of multiple authorization models. The permissions defined in FGA are highly targeted. Rather than simply granting or revoking access, different users can have different types of access to the same resource. Permissions are tightly constrained based on multiple conditions, and those conditions incorporate different types of data: roles, relationships, attributes, etc.

What are the benefits of Fine-Grained Authorization?

FGA is more secure than other authorization models because of its flexibility and specificity.

• Flexibility: FGA can express authorization logic that is unwieldy or impossible using any single authorization model. A pure RBAC or ReBAC system forces you to recast all authorization logic in terms of roles or relationships. If you want to support public documents in RBAC, you have to add all users to a default role that has permission to access any document marked public. That translation makes it easier to introduce errors and more difficult to understand the intent of the logic. Under FGA, your authorization logic can just test the public attribute directly.
• Specificity: FGA can grant highly targeted permissions under narrowly defined conditions. If you need to build something like the impersonation logic above, you can in FGA. Under a coarse model like RBAC, you have to relax some of those requirements. You couldn’t restrict the impersonation permission by geography or time under RBAC, so you’d just have to grant it to anyone with the impersonator role. This means that you grant permissions to more users than strictly need it.

What are the drawbacks of Fine-Grained Authorization?

It’s harder to develop and operate applications that incorporate FGA.

• Development: Authorization policies based on FGA define more resources and provide more evaluation paths than other models. After all, that’s why you need FGA in the first place. This creates a multitude of possible states, which introduces opportunities for gaps and edge cases. Good tests are critical, but also more difficult to write.
• Operation: Under FGA, a request could be allowed or denied for multiple reasons. A given request can even yield a different result based on transient conditions like the time of day. You need detailed logs and powerful auditing to validate system functionality and troubleshoot issues.

When should you use fine-grained authorization?

Don’t introduce extra complexity until you need it. If your authorization logic only relies on roles, then stick with RBAC. When you need to combine elements of multiple models to make an authorization decision, you need FGA. Some examples of features that require FGA include:

• Impersonation: When your application lets one user assume the identity of another, you need to be sure that ability is tightly controlled. Impersonation should be restricted to people you trust to use it responsibly, and even those people should only be able to use it for legitimate business needs. FGA lets you write policies that define not only who is allowed to do something, but also when they’re allowed to do it and on which entities.
• Entitlements: If you have tiers of service that provide different features, you want to be sure that customers only have access to the features provided by their tier. A policy based on FGA can incorporate information about what tier a customer belongs to, and can be extended to allow things like free trials or promotional windows that grant elevated access for a period of time.
• Field-level Authorization: Sometimes, different users have access to different pieces of data on a given resource. A Customer Service Rep may be able to manage other users' settings and preferences, but only Customer Service Managers can see and edit sensitive customer data like their address or credit card information. To support this, you need permissions that target not only specific resources, but specific information on a given resource. You also want to narrowly define the conditions under which a user is granted access to the sensitive data.

When you start to build these kinds of features, start to add FGA to your authorization model. This will allow you to grow into FGA when it’s necessary.

Fine-Grained Authorization in Oso Cloud

The Polar language provided by Oso Cloud can model the complex logic that FGA demands. It also provides simple workflows for RBAC and ReBAC, so you can express all of your logic in a natural syntax. You can build an initial policy based on simple RBAC rules, and extend the policy with ReBAC and ABAC elements over time. This makes FGA policies in Oso Cloud easy to develop, understand, and maintain.

Oso Cloud can use data from your application databases and from external sources. You can keep that data in your local databases, centralize it in Oso Cloud, or pass it to Oso Cloud at request time. This lets you write FGA policies that incorporate information from disparate sources without the need for a convoluted data management process.

As you move into production, the testing and troubleshooting tools that Oso Cloud provides give you confidence that your policy does what you intend it to do. You can add complexity without wondering whether you broke any existing logic. Because your policy is code, you can quickly iterate on it if your tests catch an error or roll it back to a previous state if you do identify an anomaly in production.

Oso Cloud is free to get started – try it out. If you’d like to learn more about building Fine-Grained Authorization with Oso Cloud or just talk authorization with us, come say hi on Slack.

‍