1. Messages
  2. [abacus] Usage processing authorization, was: Usage submission authorization

Re: [abacus] Usage processing authorization, was: Usage submission authorization

Jean-Sebastien Delfino
 

Hi all,

A few more thoughts on a different, but related subject.

We're using the resource provider's token and scopes to authorize usage
*submission* to our usage collector service. I agree with that and have
confirmed it in my answer to Piotr's question below.

It also looks like we're using the resource provider's token as well to
flow usage data through our usage *processing* pipeline (after we've
authorized the usage submission, validated that usage and taken
responsibility for it). I'm wondering if we couldn't find a better
approach, as we will run into a number of issues with this:

- processing delays in the pipeline can cause the token to expire, at that
point the resource provider is out of the loop, can't do anything about it,
and it won't make much sense anyway to ask the resource provider for a new
token way after it has submitted its usage;

- when restarting an Abacus service and recovering after a processing
interruption, we don't have a valid resource provider token either;

- more generally, I find a bit odd to use the resource provider's token in
usage processing steps down the Abacus pipeline, as they're really just
processing usage passed to them by the previous Abacus processing step (or
could have just read that usage from one of our usage DBs, and again the
resource provider wouldn't be so relevant as it wouldn't even have written
that usage to that DB itself.)

So, I'm wondering if it still makes sense to use the resource provider's
token inside our *asynchronous* usage *processing* pipeline. Shouldn't we
require the individual processing steps to obtain their own tokens instead?

Thoughts?

-- Jean-Sebastien

On Tue, Oct 6, 2015 at 10:36 PM, Jean-Sebastien Delfino <jsdelfino(a)gmail.com
wrote:
Hi Piotr,

what kind of authorization is required to submit usage to Abacus ?
Is the oauth token used for submission [1] required to have particular
scope, specific to resource or resource provider ?

A resource provider is expected to present an OAuth token with the usage
it submits for a (service or runtime) resource.

That OAuth token should include:
- a user id uniquely identifying that resource provider;
- an OAuth scope named like abacus.usage.<resource_id>.write.

The precise naming syntax for that scope may still evolve in the next few
days as we progress with the implementation of user story 101703426 [1].

Is there a different scope required to submit runtimes usage (like cf
bridge) versus other services or its possible to use single scope for all
the submissions

I'd like to handle runtimes and services consistently as they're basically
just different types of resources, i.e. one scope per 'service' resource,
one scope per 'runtime' resource.

We're still working on the detailed design and implementation, but I'm not
sure we'd want to share scopes across (service and runtime) resource
providers as that'd allow a resource provider to submit usage for resources
owned by another...

@assk / @sasrin, anything I missed? Thoughts?

-- Jean-Sebastien


On Tue, Oct 6, 2015 at 6:29 PM, Piotr Przybylski <piotrp(a)us.ibm.com>
wrote:

Hi,
what kind of authorization is required to submit usage to Abacus ?
Is the oauth token used for submission [1] required to have particular
scope, specific to resource or resource provider ? Is there a different
scope required to submit runtimes usage (like cf bridge) versus other
services or its possible to use single scope for all the submissions ?


[1] - https://www.pivotaltracker.com/story/show/101703426

Piotr


?
attachment.html

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.