Service Oriented Authorization - Part 3
As a follow up to Part 1 and Part 2 here is the video of the talk I gave at RailsConf last month.
Disclaimer: This is my first conference talk, ever!
Slides available on Speakerdeck
As a follow up to Part 1 and Part 2 here is the video of the talk I gave at RailsConf last month.
Disclaimer: This is my first conference talk, ever!
Slides available on Speakerdeck
While recently working on IronHide, specifically the CouchDB Adapter, I needed a way to have the gem expose custom Rake tasks to an end user’s application.
For example, to make working with the IronHide CouchDB Adapter easier, I wanted to allow users to upload existing rules from disk to a remote CouchDB database.
The task could be something as simple as:
$ bundle exec rake iron_hide:load_rules\['/absolute/path/file.json','http://127.0.0.1:5984/rules'\]
where the two arguments are the path to the JSON file and the remote CouchDB database.
After thinking for a moment, I knew that I’ve come across at least one gem that when included, exposes Rake tasks that I can use in my project, Bundler. So, I started looking through the source and found this: https://github.com/bundler/bundler/blob/master/lib/bundler/gem_helper.rb
Essentially, you’d like an application owner to be able...
On my team, we like to be able to keep our applications light. We use several internal libraries to manage things like distributed request tracing, authorization, configuration management, etc.
Isolating this reusable, generic code into a library keeps our application code concise and manageable. It also allows us to test changes to the library in isolation (not to mention keeping our tests fast).
Most of these gems are very specific, and it wouldn’t make much sense to make them public. So, we decided the best approach was to use our own, internally accessible gem server.
A gem server can really just be a set of static files – nothing fancy.
http://guides.rubygems.org/command-reference/gem_generate_index
Given a base directory of *.gem files, generate the index files for a gem server directory
$ gem generate_index --directory=GEMS_DIR
And just like that...
Last week, I closed the discussion on authorization with the observation that existing authorization libraries in the Ruby ecosystem rely on coupling the application code to the authorization rules.
Make things as simple as possible, but not simpler. – Albert Einstein
Applications tend towards complexity over time and it’s our job as engineers to keep our systems simple. I started with the assumption that it must be possible to design an application with a large set of authorization rules and a simple design.
With CanCan, complexity quickly grows as the number of rules grow. You need to quickly find ways to keep the Ability class in check. To provide a simple example of how this can happen, let’s distill our application’s user domain model into two sets of users:
It’s a common theme: as our business requirements grow, so does our application. One day we discover we have coupled multiple business function sets in a monolithic application. In order to manage complexity and meet scaling requirements, we segregate the functional groups into several separately deployed applications, or services.
This is typically what we would call service-oriented architecture (SoA). I’m not writing here about the pros or cons. That’s already been done pretty well.
Here, I talk about the challenges of scaling an authorization framework, the problems we run into, and finally a solution we can adopt.
In the beginning, we have a small Rails app. We have the notion of users and these users interact with a few resources. The domain model is simple. We can fit the entire thing in our head. CanCan is very flexible with how we...