steffenbartsch

I just pushed the decl_auth 0.4 gem to gemcutter.

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.

HttpMock is great to test the client side of a REST API. But if you’re responsible for client and server side of the API, it makes sense to do full end-to-end tests from your application’s controllers to the client app. Up to now, you’d need to set up a local server to end-to-end-test the ActiveResource requests from the client app against.

Instead, I’d like to just use Rails’ integration test infrastructure. All ActiveResource requests can be directly routed to the app’s controller, just as known from integration tests. This is how tests could then look like:

  require 'active_resource_integration_test_support'
 
  class APIIntegrationTest < ActionController::IntegrationTest
    test "API requests work end-to-end" do
      ActiveResource::Connection.with_integration_test_session(open_session) do
        result = APIClient.some_method_that_requires_api_access
        assert result
      end
    end
  end

All you need to get there, is drop this monkey patch into your app’s lib directory and require it from the ActiveResource integration tests.

module ActiveResource
  class Connection
    # ActiveResource requests will use the supplied
    # ActionController::Integration::Session to execute its request in the
    # given block.
    #
    def self.with_integration_test_session (session)
      previous_session = Connection.integration_test_session
      begin
        Connection.integration_test_session = session
        yield
      ensure
        Connection.integration_test_session = previous_session
      end
    end
 
    private
    mattr_accessor :integration_test_session
 
    def request_with_integration_test_support (method, path, *arguments)
      if self.class.integration_test_session
        # arguments are data, header for post, put; else header
        header = arguments.last
        data = arguments.length > 1 ? arguments.first : nil
 
        Rails.logger.debug("#{method.to_s.upcase} #{path}")
        self.class.integration_test_session.send(method, path, data, header)
        #Rails.logger.debug(self.class.integration_test_session.response.body)
 
        handle_response(self.class.integration_test_session.response)
        self.class.integration_test_session.response
      else
        Rails.logger.debug("No session set, using default ActiveResource requests")
        request_without_integration_test_support(method, path, *arguments)
      end
    end
    alias_method_chain :request, :integration_test_support
  end
end

If you find this useful, have a look at the pending Rails patch at Lighthouse to support getting this into Rails.

I just pushed the 0.3 release for declarative_authorization to github.  declarative_authorization helps Rails developers to implement authorization in a declarative manner, cleanly separating authorization rules from application code and reusing the same policy for access control in model, view and controller.

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.

Many projects employ authorization frameworks to control and enforce permissions. Custom-built or off-the-shelf, how sure are you that your projects are using the framework in the correct way? And have authorization checks at all the necessary locations in your code base?

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.

It certainly helps to have the authorization rules in your Rails app defined in a clear DSL, such as the one offered by declarative_authorization. Still, with anything more than a few roles and models (let’s not even think about 200 models), it can be hard to maintain a good view of the whole rules set.

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?

There now is a declarative_authorization discussion group at Google Groups. This group is a good place to discuss patterns of using the plugin. Thanks for setting it up, Mike.

No more issue tracking in comments or direct e-mail!  To improve the development process and enable more collaborative development, I created a Lighthouse project for declarative_authorization.  Please direct all your suggestions and bug reports to there.

With Rails 2.2 around the corner, I decided to implement a scalable testing infrastructure for the declarative_authorization plugin. One great thing to notice at the RailsConf Europe was Ian’s garlic.  Though only given as a side note in Ian’s talk on resources_controller, it provides a nice way of keeping your plugin tested against all those Rails versions.

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

One of the interesting comments on our RailsConf Europe presentation on declarative_authorization was offered by Timo Hentschel. He stated that on the Rails CRM project with 90 Controllers and 200 Models that he is working on the declarative_authorization approach was simply not viable. Projects of this size are currently not the target of our plugin, though. Currently, we focus on bringing maintainable authorization into small to medium applications. Nevertheless, it is interesting to look into Timo’s points:

• “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.

I’m in Berlin for RailsConf Europe currently where I’m talking together with Carsten Bormann about implementing application security in Agile development with Rails and announcing declarative_authorization.

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