Manage API authentication

[northox]

Provide the capability to control who can access the API - authentication.

Constraint: The design of this functionality needs to take into consideration the future need to extend the model toward a more elaborated type of Access Control where we can actually control who can access what (which part of the API, under which constraints) - authorization.

[jmettraux]

Hello,

since flack is a Rack "app" (something that responds to call(env), for the app where I am using flor+flack I did it this way in the configu.ru:

# (...)
#
# top Sinatra configuration then...

require 'flack'
require 'sg/flor_logger'

class ManageFlowCheck

  def initialize(app); @app = app; end

  def call(env)

    s = env['rack.session']
    u = s && SilverGoose::Auth.user(s[:user_id]) rescue nil
      # fetch user from host application auth service

    if u && u.may?(:manage_flows)
      # the user has the right to manage flows, let her/him pass
      @app.call(env)
    elsif u
      # prevent access to valid user
      [ 403, {}, [ 'Forbidden' ] ]
    else
      # prevent access, not logged in, 404 would be better maybe
      [ 401, {}, [ 'Unauthorized' ] ]
    end
  end
end

map '/flack' do

  use ManageFlowCheck

  run Flack::App.new('flor/', start: false)
    # only start flor when auth credentials are available...
end

run Sinatra::Application

My goal showing that is not to solve this issue, it's rather to remind us that Rack allows for deceptively simple solutions, those horses can let us ride far, provided we remember they're in the stable.

[jmettraux]

authentication

We should look at what's on the Rack market, maybe https://www.google.co.jp/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=ruby+rack+authentication+middleware&*

authorization

Maybe there is a Rack middleware out there to help us, but we should probably start with enumerating what can be done with flack:

• POST a message to flack /message
  • a launch message
  • a cancel message
  • a tasker reply message
• GET a list of executions /executions
• GET a particular executions /executions/:exid

For now that's all there is to it.

Updated with point from #1

[jmettraux]

@northox question, are we in sync if I say that you want to use flack(+flor) as a standalone service? Whereas I'm thinking of using it as some kind of admin nested in a flor-using application?

I want to distinguish the two use cases, they can gain from each other, but we need to not confuse them.

[northox]

Yes, exactly.

Absolutely. The separation has to be VERY clear. That's what I was saying in #5:

What I have in mind is to use Flack's API itself so it would be composed of two parts;

1. to manage workflows (e.g. create,list) and;
2. to act as a RESTful tasker - i.e. the Flack Tasker

The first part being your admin nested in a flor-using application and the second being the standalone service.

[northox]

Your authentication implementation proposal seems to make sense but I think we should assign it to a far-away milestone or on-hold label as it's not a priority - at least for me. The whole point of have it here is for other users to do +1 if this is something they need.

[jmettraux]

OK. let's welcome +1s and comments.