Avoiding FGA's Tuple Hell

Taming tuple explosions in Fine-Grained Authorization

Fine-Grained Authorization (FGA) is a great piece of kit. Like microservices, it adds flexibility and scale. It also brings complexity. This level of complexity is not always the right fit; sometimes, all you need is a simple role check. Easy. I don’t want to talk about those cases.

Let’s say FGA is the right choice. What are some initial questions to get you on your way?

For me, performance is critical. You have to avoid the “tuple explosion”. It will bring your system to its knees. To this end, think about how often your system will need to ask, Can this user do this thing? Now imagine all the users. All the things. All the checks. Those add up to pressure on the tuple store that must inform the design. It leads me to thoughts like:

• How best to shape graph traversal?

  • Remember, we’re thinking in graphs here

  • Where are the “pivot” points in the models?

  • How can we reduce the number of calls?

  • Can we reduce how much data is retrieved?

  • Deep trees impact performance. Keep traversal limits in mind

• Do users switch contexts (like between organizations)?

• Look for opportunities to reduce tuple count with “cascading” permissions

  • This relates back to tree depth and the “pivot”

  • How will deletion and revocation propagate through the tree

• Can you foresee computed permissions? What might those look like?

• Design around the principle of least privilege

• What low-risk data is worth caching?

In no universe are these comprehensive. But it’s where my mind drifts first. FGA is a powerful authorization technology. And with that power comes the ability to shoot yourself in the foot blow your foot off. So do your future-self a favor and try to manage the size of your tuple set before it gets out of hand.