Access Denied: the missing guide to authorization in Rails, by Vladimir Dementyev
Abstract
Rails brings us a lot of useful tools out-of-the-box, but there are missing parts too. For example, for such essential task as authorization we are on our own.
Even if we choose a trending OSS solution, we still have to care about the way to keep our code maintainable, efficient, and, of course, bug-less.
Working on Rails projects I've noticed some common patterns in designing access systems as long as useful code techniques I'd like to share with you in this talk.
Details
Let's discuss first what authorization is:
- When we need it?
I want to provide some simple examples of plain old Ruby authorization techniques in our controllers (e.g., "no one can delete my tweet except from myself and superadmin").
That's a problem statement; just to make sure that everyone is familiar with what I'm going to talk about.
- What is the place of authorization layer in Rails application?
We've already learned about controllers. What else? Views, channels, etc.
- What are the main paradigms?
A note about activity-based checks vs. role-based checks (RBAC). We're gonna talk about activity-based checks only in the rest of the talk.
Unfortunately, Rails doesn't provide authorization framework out-of-the-box. So, we have to choose an existing library or build one ourselves. Anyway, we need a way to organize our access-related code.
What about existing solutions? There are two popular libraries: cancan(can) and pundit. I've been actively using both (though finally migrated to the latter one) and none of those two satisfied all my needs. That's why I started thinking about a new, ideal, framework for authorization (spoiler: it's already WIP, and some ideas from it have been in production for years already).
What do I want (and, I guess, most of you too) from this dream-library? There are some keys points:
- Magic vs. boilerplate balance
- Performance (per-thread memoization, cache)
- Namespaces (modules)
- Testability (Where to test authorization policies? How to do that efficiently?)
- Frontend vs. Backend
- More meaningful "Access Denied" message (i.e., how do I know why a feature was authorized or not?)
I want to discuss this features, show some examples and demonstrate some techniques for writing efficient authorization-level code.
This talk is a missing guide to authorization in Rails. At least, that's what I want it to be)
So, it fits everyone from newcomers to experienced Rubyists (and event non-Ruby-lovers).
Pitch
Can you imagine a Rails app without any access checks? I guess you can imagine. But what about real-world? It's not easy to find one (though possible, of course).
Does this problem deserve too much attention (the whole talk)? I believe it does. That's why I'm here)
There are a lot of questions when dealing with authorization:
- Which approach/framework to choose?
- How to test user-resource access?
- How to organize policies/abilities/whatever?
- What are the typical caveats/pitfalls?
- ...and more.
And it's not easy to find all the answers (well, at least it was not easy for me), especially in one place–and I want to fix it.
The title of talk describes the main idea–provide a useful piece of information for everyone struggling with authorization in Rails.