Authorization

[Samsinite]

Hey guys,

This gem/library looks great! What about directly supporting an option to easily hook up authorization instead of requiring the resource controller index/show/create/update/destroy methods to be overridden?

Something like a simple interface that filters for index/read_list, returns true/false for show/create/update/destroy, and if in the future updating lists or destroying lists are supported, the interface could be updated to support filtering those as well. Than it would be straight forward for whoever to override it to support their preferred method of authorization, such as pundit or cancancan. I wouldn't mind implementing this if you guys are interested.

[lgebhardt]

I have been thinking about different ways to handle authorization. I stripped out my first attempt (a set of callbacks of the resource) since I wasn't sure it was quite right.

One concern I have about overriding the controller to handle authorization is that once we get patch support implemented it will be possible to have a single request create multiple operations. Authorization will need to be checked for each of these operations. I don't know how well Pundit or cancancan can be adapted to this criteria.

One method I have been playing with (in my project using this gem) has been to create a custom OperationsProcessor, derived from the ActiveRecordOperationsProcessor. In before_operation I call a custom method on each resource which I have named approve_operation. This allows each resource to have it's own authorization scheme. I'm not totally happy with this approach since the approve_operation method isn't as clean as I think it should be (due to needing to pull the details out of the Operation object).

I would certainly appreciate any work you wish to put into this problem. I just want to make sure any solution we adopt will support multiple operations, is flexible to support different authorization packages, and is resource centric (if possible).

[Samsinite]

lgebhardt,

I'll put together an example showing the gist of what I was thinking, and see what you think.

I'm thinking an interface that can be specified in the controller -- similar to how context is specified -- so nothing on the controller has to be overridden. I don't see this getting in the way for a patch single request that handles multiple operations, as whatever handles the type of patch operation that occurs can know the appropriate type of authorization that it needs to do. I currently think authorization should occur in the controller and not in the resource -- thus why I think a callback on a resource is a bad idea.

[lgebhardt]

@Samsinite, thanks, I look forward to seeing your proposal.

[lgebhardt]

From the http://jsonapi.org/format/#patch-urls

PATCH operations MAY be allowed at the root URL of an API. In this case, every "path" within a PATCH operation MUST include the full resource URL. This allows for general "fire hose" updates to any resource represented by an API. As stated above, a server MAY limit the type, order and count of bulk operations.`

I want any authorization system we come up with to allow jsonapi-resources to support PATCH operations on the root URL.

[juggy]

Authorizations are also important on the UI side for the client that will use the data. I was thinking about sending along with the object, the operation the user can perform on it.

For a post the author can create, read, update, delete, but a viewer can only read. Based on that meta information, the client can change the UI to reflect it.

This does not remove the need to block actions on the server based on the user's authorization, but it would provide a much more complete approach.

[barelyknown]

It might help others to see how I'm handing authorization. I'm pretty happy with the approach.

I'm using the pundit gem in combination with the new callbacks that are available in v0.1.0 of jsonapi-resources.

This is what my BaseResource class looks like.

module V1
  class BaseResource < JSONAPI::Resource
    [:create, :update, :remove].each do |action|
      set_callback action, :before, :authorize
    end

    # Authorize the model for the permission required by the controller
    # action. Also, mark the controller as having been policy authorized.
    def authorize
      controller = context.fetch(:controller)
      permission = controller.action_name + "?"

      controller.policy_authorized!
      policy = Pundit.policy!(context.fetch(:current_user), model)
      unless policy.public_send(permission)
        error = Pundit::NotAuthorizedError.new("not allowed to #{permission} this #{model}")
        error.query, error.record, error.policy = permission, model, policy
        raise error
      end
    end

    class << self
      # Override the records method to policy scope the records
      # used by JSONAPI::Resource find methods. Also, mark the controller
      # as having been policy scoped.
      def records(options = {})
        options.fetch(:context).fetch(:controller).policy_scoped!
        relation = Pundit.policy_scope!(options.fetch(:context).fetch(:current_user), _model_class)
        authorize(options.fetch(:context), relation)
        relation
      end

      private

      def authorize(context, relation)
        case context.fetch(:controller).action_name
        when "show"
          resource_for(
            context.fetch(:controller).params.fetch(:controller)
          ).new(relation.first, context).authorize
        end
      end
    end
  end
end

[wzowee]

@barelyknown what are you using for authentication? My only experience with authentication in Rails so far is Devise, but that does not appear to be a good fit here.

[barelyknown]

@wzowee Devise could work fine. I've used that or just rolled my own using has_secure_password. In either case, I use the OAuth2 password flow and then ember-simple-auth.

[oliverbarnes]

@barelyknown I think you're on to something, I've been also thinking it'd be nice to use a pundit-like solution. Only I'm wondering if it'd be possible to have separate Policy objects with methods for each of the operations, and this object would be passed around to both resources (for GET requests / show operations) and controllers (for POST and PATCH / create and update operations). I'm still grokking the source to be able to offer a concrete solution, though

[oliverbarnes]

@wzowee we're also using ember-simple-auth + rolling our own token oauth, but this setup assumes you have an ember front-end, a single trusted client. Is that your scenario? It might be different for, say, services, or a public API.

[barelyknown]

I've evolved my approach a bit (but it's still the same basic idea). Here's some sample code. It might be helpful.

module V1
  class BaseResource < JSONAPI::Resource
    include ResourcePolicyAuthorization
    // ...
  end
end

module ResourcePolicyAuthorization
  extend ActiveSupport::Concern

  included do
    [:save, :remove].each do |action|
      set_callback action, :before, :authorize
    end
  end

  delegate :authorize_policy, to: :class

  def authorize
    authorize_policy(context[:current_user], model, context[:controller])
  end

  def records_for(association_name, options={})
    records = model.public_send(association_name)

    return records if context.nil?

    if records
      authorize_policy(context[:current_user], records, context[:controller])
    end
    records
  end

  class_methods do
    def records(options = {})
      authorized_records(
        options[:context][:current_user],
        options[:records_base] || _model_class,
        options[:context][:controller]
      )
    end

    def authorized_records(user, records, controller)
      records = Pundit.policy_scope!(user, records)
      controller.policy_scoped!

      authorize_policy(user, records, controller)

      records
    end

    def authorize_policy(user, records, controller)
      controller.policy_authorized!

      case records
      when ActiveRecord::Relation
        return if records.count == 0
      end

      policy = Pundit.policy!(user, policy_record_for(records))
      permission = permission_for(controller, policy)

      if !_authorized?(policy, permission)
        raise Pundit::NotAuthorizedError.new(
          query: permission_for(controller, policy),
          record: policy_record_for(records)
        )
      end
    end

    private

    def policy_record_for(records)
      case records
      when ActiveRecord::Base then records
      when ActiveRecord::Relation then records.first || records.model
      end
    end

    def permission_for(controller, policy)
      case controller.model_class == policy.model_class
      when true then controller.action_name.to_s + "?"
      when false then "show?"
      end
    end

    def _authorized?(policy, permission)
      policy.public_send(permission)
    end

  end
end

[wzowee]

@oliverbarnes yeah - that's pretty much my scenario at present - have gone with ember-simple-auth and devise for now (see http://johnmosesman.com/ember-simple-auth-tutorial-and-common-problems/), mainly due to time constraints and not wanting to re-implement what comes for free with devise (account locking, password reset emails etc)

@barelyknown thanks for the update on how your authorisation is evolving.

[oliverbarnes]

@barelyknown I'm having a hard time seeing where the authorization rules are, or would go, there