Merge lp://staging/~joetalbott/uci-engine/add_v2_skeleton into lp://staging/uci-engine

FAILED: Continuous integration, rev:760
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1357/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1357/rebuild

FAILED: Continuous integration, rev:761
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1464/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1464/rebuild

PASSED: Continuous integration, rev:763
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1465/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/1465/rebuild

This should be ready to be reviewed now.

Joe,

Before we dive into this. Why is it necessary to provide a v2 API for supporting authentication/authorization ?

Why can't we right an Authorization class that accommodates our needs [1] and apply that to all existing v1 resources ? Since authorization procedure is pretty homogeneous to all resources.

[1] unrestricted access for requests coming from Lander & GK (bundle.request.META.REMOTE_HOST matching against intercom private-address relations), read-only access to non-private content and write access to logged in users (bundle.request.user.is_authenticated)

The consensus was that we'd have a v1 api that's unauthenticated and a v2 api that is authenticated. The only major reason I can recall is to handle upgrading a deployment or other clients (CLI for one) that might be in use that aren't able to support authentication yet. This might need to be re-evaluated and would certainly simplify this MP.

Right, I remember that argument about 'supporting unauthenticated clients', specially CLI, because internal components will probably always be unauthenticated and that's fine from the security PoV and much lighter for the code maintenance/complexity burden PoV.

Regarding the CLI, it would have to be upgraded in order to support authenticated actions either if we block it via central Authorization class or drop v1 from the apache proxy. So, I don't see why we can't land an permissive Authorization class on v1 now and flip the restrictive switch (only authorized writes) when we upgrade the CLI. In both cases, old CLI writes would break when we get *safe*, right ?

On Thu, Sep 25, 2014 at 01:20:15PM -0000, Celso Providelo wrote:
> Right, I remember that argument about 'supporting unauthenticated clients', specially CLI, because internal components will probably always be unauthenticated and that's fine from the security PoV and much lighter for the code maintenance/complexity burden PoV.
>
> Regarding the CLI, it would have to be upgraded in order to support authenticated actions either if we block it via central Authorization class or drop v1 from the apache proxy. So, I don't see why we can't land an permissive Authorization class on v1 now and flip the restrictive switch (only authorized writes) when we upgrade the CLI. In both cases, old CLI writes would break when we get *safe*, right ?

If that's the case we don't need to do anything. All the tastypie
resources are read-only except those that need write access which
already have the default permissive authorization implementation.

So should we just reject this MP?

I think we should land a custom authorization class to explicitly support:

 1. *local* access for components inside the same deployment, established via juju-relation (think Lander or GK)
 2. *internal* access for components outside the deployment but inside the DC with the appropriate fw rules, established via juju-config (think ci-train jenkins or any other crack-of-the-day subsystem)

External access, coming via webui-apache proxy (host preserved) would be submitted to openid or oauth2 authentication (request.user is setup), at this point, specifically we say 'yes, for now ...' to anonymous request.

Later, when the CLI is able to grab a oauth token and use it, we just patch the custom Authorization class and we are done.