Major changes since the 0.3 release:

• Improved DSL: allow nesting of has_many associations for if_permitted_to and if_attribute:

  has_permission_on :companies, :to => :read do
    if_attribute :branches => { 
        :manager => { :last_name => is { user.last_name } } }
    if_permitted_to :read, :branches
  end

• Simplified controller authorization for RESTful controllers with filter_resource_access. Instead of multiple filter_access_to statements, one line is often sufficient:

  class BranchController < ApplicationController
    filter_resource_access :nested_in => :companies
  end

• Controller namespace handling.  Now, the decl_auth context in controllers is prefixed by the underscored namespace by default. Thanks for all those implementation suggestions in the Github forks.

• Improved STI handling by allowing to explicitly define the model’s decl_auth context.  Just override AModel.decl_auth_context.

• Test helper to test authorization rules, e.g.

  with_user a_normal_user do
    should_not_be_allowed_to :update, :conferences
    should_not_be_allowed_to :read, an_unpublished_conference
    should_be_allowed_to :read, a_published_conference
  end

• permitted_to?/! on model level. You may now use those methods in models as you are used to from controllers and views.

• Switched to gemcutter for gem distribution.

• Change support in the development support backend (I’ll write a separate Blog post on decl_auth change support soon)

And lots of smaller fixes: full change log.

So, what’s new in 0.3? Apart from smaller fixes and improvements, a few major items:

• Gemified the plugin
• Allow to globally enable model security by calling ActiveRecord::Base.using_access_control
• New operator intersects_with
• AND’ing attribute conditions in has_permission_to blocks

Also, helping you in handling complex policies and using declarative_authorization correctly, a Rails Engines-based GUI has been implemented, with graphical policy browser and usage analyzer. The full changelog.

One way, of course, is code review. Have knowledgeable people point out the mistakes by looking over the code. Complete code reviews may be prohibitively expensive, though. Being a cross-cutting concern, you need to look at a lot of code for authorization aspects.

Penetration tests: definitely necessary. Still, penetration testing isn’t likely to find a one-time error in the usage of the authorization framework. Achieving a high coverage is very expensive.

So, what about authorization-focussed static analysis? It would definitely improve code review efficiency. Commercial static analysis tools still primarily look for programming errors, though. As authorization checks are typically employed in a structured manner, they can be easily analyzed if the framework is known well by static analysis rule developers.

For Rails apps, our Rails authorization plugin declarative_authorization comes with  support of this kind. In the screenshot, controller authorization analysis is shown. Possible flaws are highlighted in yellow and red and the found problems are displayed in tool tips.

In the demo app, the authorization usage browser reveals which actions aren’t (properly) protected by authorization checks. For example, SessionsController#create is marked red for having no authorization check. This, of course, is intentional as this action allows users to login.

The yellow coloring of ConferencesController#index shows that this action is just generally protected and authorization constraints are not enforced. Again, this is intentional because index lists conferences and conference-specific authorization is checked at database query time. If other actions were marked in this way, the developer could easily make out the mistakes and correct potentionally highly critical bugs.

Try it out in the declarative_authorization demo application! And leave a note on whether this is of use to you.

For now, the tool analyzes authorization on controller level.  As declarative_authorization also comes with authorization for the model level and database query rewriting, a next step will be looking at issues in those areas as well.

So, how about a graphical browser of your authorization rules?  In particular inheritance between roles and privileges – and consequences thereof – may be much easier to grasp in a graphical way. This is how it looks in the declarative_authorization demo application:

Roles are shown in colored ovals and are connected to privileges in the context boxes. Inheritance links between roles and privileges are displayed in black, with unfilled arrows. Filled circles on role-privilege links show additional rules that apply.

You can filter to dig deeper into the rules and limit the view to certain roles or contexts. Also, you can decide to only display those privileges that are explicitly stated in the authorization configuration or all privileges that the roles possess.

If you are interested, give it a try. Either in the declarative_authorization demo application or in your own application. The declarative_authorization README tells you the one simple step to get it started. This feature requires graphviz for graph generation and Rails 2.3 for its Engine support.

On the long run, we’d like to integrate multiple abstraction levels for different viewing audiences and we might even add authorization rule editing capabilities.

What do you think? Does this help you as a developer or in discussions with non-technical customers about authorization?

Very easy to set up.  Only add to your Rakefile a few lines that run garlic:

if File.directory?(File.join(File.dirname(__FILE__), 'garlic'))
  require File.join(File.dirname(__FILE__), 'garlic/lib/garlic_tasks')
  require File.join(File.dirname(__FILE__), 'garlic')
end
 
desc "clone the garlic repo (for running ci tasks)"
task :get_garlic do
  sh "git clone git://github.com/ianwhite/garlic.git garlic"
end

And define the tasks that garlic should perform for you.  In the declarative_authorization case, garlic should retrieve the plugin from the current path and take a few Rails versions as targets. For the test run, garlic just needs to run “rake”. This is the necessary recipe:

garlic do
  repo 'rails', :url => 'git://github.com/rails/rails'
  repo 'declarative_authorization', :path => '.'
 
  target 'edge'
  target '2.1-stable', :branch => 'origin/2-1-stable'
  target '2.2.0-RC1', :tag => 'v2.2.0'
 
  all_targets do
    prepare do
      plugin 'declarative_authorization', :clone => true
    end
 
    run do
      cd "vendor/plugins/declarative_authorization" do
        sh "rake"
      end
    end
  end
end

Thus, all that is needed to check my current declarative_authorization branch against all defined Rails versions is

rake get_garlic # just once
rake garlic:all

Great, all declarative_authorization tests pass on 2.2.0-RC1!

All specified targets passed: edge, 2.1-stable, 2.2.0-RC1

• “Role definition is for admins not developers”: It certainly depends on the project size. With small to medium apps (our primary target) admins might just be the developers. Still, our future plans include a possible move of the authorization rules to database, enabling a policy editing UI.
• “You’d need a UI for handling the policy development”: This might be true. But without further evaluation, I am not convinced of the superior performance of a UI when compared to a readable, concise policy syntax. Policy files still provide documentation and specification for free. We will look into UIs, especially to facilitate a test-driven policy development approach, though.
• “I can’t redeploy on every role modification”: In practice, engineering an application’s policy is certainly error prone. Missing permissions will have to be added to roles once taken into production. Changing roles on a production system isn’t optimal either, though: role-permission assignments need to be carefully checked for side effects. Thus, a QA workflow would be desirable, just as provided by a deployment cycle. I would prefer to handle missing permission assignments just like other software bugs which need to be fixed asap. Nevertheless, with the planned features (TDD, UI, policy in DB) and an integrated authorization workflow, online role modifications may be feasible. In our self-service authorization approach we would even like end users to extend their permissions on their own, on a limited scope and in some environments.
• “With 90 Controllers, the authorization policy will become unmanageably long”: This is certainly true with the current syntax. On the one hand, we will distribute rules to multiple files in order to group similar aspects. Also, currently one context is used per model. A hierarchy of contexts is planned to cut the number of specific rules and thus ease policy development and maintainability.

Here is our presentation (will only really display nicely on Firefox 3, though, sorry; full window view):

In our declarative approach, authorization rules are grouped in a policy file, while only privileges are used inside program code to enforce restrictions. We developed for flexibility and simplicity, requiring only very simple statements in rules and program code. So instead of

class ConferenceController < ApplicationController
  access_control :DEFAULT => [:admin],
    [:index, :show]  => [...],
    [:edit, :update] => [:admin, :conference_organizer]
end

cond = permit?([:admin, :conference_organizer]) ?
           {} : {:published => true}
Conference.find(:all, :conditions => cond)

<% restrict_to [:admin, :conference_organizer] do %>
  <%= link_to 'Edit', edit_conference_path(conference) %>
<% end %>

with all the authorization logic interweaved with your code, you only need this

class ConferencesController < ApplicationController
  filter_access_to :all

  def index
    @conferences = Conference.with_permissions_to(:read)
  end
end

<%= link_to 'Edit', edit_conference_path(conference)
            if permitted_to? :edit, conference %>

And, separated in one place the authorization rules:

role :guest do
  has_permission_on :conferences, :to => :read
end

role :conference_organizer do
  has_permission_on :conferences, :to => :manage
end

So, the same rules are used in enforcing authorization in Model, View and Controller. Also, they are used for Query Rewriting to automatically constrain the retrieved records according to the authorization rules.  Thus, you just modify the rules on authorization requirement changes and you can also use the rules to talk to business owners of Agile projects.

For additional information and more examples, refer to the README and the rdoc documentation. Currently, we are using the plugin for an application with fairly complex authorization and it will be taking into production in the next iteration. So, look into it if you have authorization concerns in your application, it’s released under MIT license.