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  endend

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 }  endend
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!

https://github.com/BUS-OGD/arrthorizer