Arrthorizer
Dynamic and Static Access Control
for your Rails Application
Rene van den Berg
Who am I?
- My name is Rene van den Berg (ReneB @Github)
- I have a bunch of (weird and other) hobbies:
- I play and organize Live Roleplaying events...
- ... I love fiddling with Arduino's and such stuff...
- ... I keep myself in shape by visiting the gym ...
- ... and so on, and so on.
- Professionally, I am interested in things like
- code quality
- application-level security
- writing as little code as I can to get maximum effects without sacrificing readability
What is the problem?
Authorization is hard. We can't even agree on its spelling.
- Static access control: 'administrators can do anything they damn well please'
- Dynamic access control: 'people are only allowed to edit their own forum posts'
What's the Problem? (2)
In some cases, authorization is even harder than otherwise:
- Multi-deployment applications where authorization might depend on what the organization wants
- for example: Coconut, our Private Social Network
What's the Problem? (3)
- Developers have an opinion on authorizations
- So do the client organizations
- Code changes and evolves - and so do privileges
- How to grant or revoke - permanently, without the next deploy potentially undoing your configuration because "stuff changed"?
Our predecessor
Some of our ideas were inspired by CBAC
(Context Based Access Control)
Some great ideas, but not actively maintained. Also, no longer applicable to our situation.
History (2)
Two developers went to ArrrrCamp...
... and started coding a new authorization library. Which, then, needed a name. Arrrr.
Arrthorizer's Principles
-
Implement dynamic and static access control
- Mountable engine (reusable sub-application)
- Easy installation
- Self-documenting
- Simple and easy (which is hard to do)
- Integrates with your code (like groups for static access control)
- Well-tested
Arrthorizer's Principles (2)
Arrthorizer is focused on getting out of your way
-
It requires very few explicit calls
Arrthorizer does not tell you how to build
your code
-
It just requires you to configure ours.
ARRTHORIZER'S PRINCIPLES (3)
Keep all badges green
Why not CanCan?
-
CanCan is no longer actively maintained
(although a promising fork called CanCanCan exists) - Different philosophies: CanCan focuses on Abilities, where Arrthorizer focuses on Actions and Contexts
Concepts (1): Context Roles
You implement all ContextRoles with one instance method:
class MessageAuthor < Arrthorizer::ContextRole
def applies_to_user?(user, context)
context.message.author == user
end
end
Concepts (2): Context
You configure context builders in your controllers
This prevents what we call context poisoning - acquiring authorization by injecting an object you do have access to into the context
to_prepare_context do |c|
c.defaults do
{ message: message }
end
end
def message
@message ||= Message.find params[:id]
end
Concepts (3): Configuration
A simple YAML file provides the link between controller actions and context roles:
read_message: # any name will do, as long as it's unique. actions: - messages: # controller_name - show # action_name
roles:
- MessageAuthor # any Arrthorizer::Group or
# Arrthorizer::ContextRole
Concepts (4): Groups
Group membership logic is owned by your app
Arrthorizer.configure do
check_group_membership_using SomeServiceObject
end
Dependency injection. Default implementation will be provided as separate plugin.
Live Demo
aka
The part where everything blows up in my face
What's Next?
- A default implementation for Role-Based Access Control
- Revoking permissions
- Move away from Combustion
- (Possibly) split off Arrthorizer-Rails from Arrthorizer
- More documentation:
- Screencast
- Tutorial at github pages
That's ALl!
Arrthorizer: Ruby Meetup
By reneb
Arrthorizer: Ruby Meetup
- 1,323