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


Jean-Sebastien Delfino
 

OK that confirms what I thought. Thanks!

Assk, any thoughts as well? Did that make sense to you?

-- Jean-Sebastien

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

Sebastien

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?

It seems natural that the Abacus should use its own token - or tokens to
authenticate and authorize steps in the pipeline. After the submission
Abacus 'takes custody' of the submitted data so it should be solely
responsible for authrizing its processing.

Piotr

Piotr Przybylski | IBM Bluemix | piotrp(a)us.ibm.com | 650-645-8213


[image: Inactive hide details for Jean-Sebastien Delfino ---10/07/2015
09:21:05 AM---Hi all, A few more thoughts on a different, but re]Jean-Sebastien
Delfino ---10/07/2015 09:21:05 AM---Hi all, A few more thoughts on a
different, but related subject.

From: Jean-Sebastien Delfino <jsdelfino(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 10/07/2015 09:21 AM
Subject: [cf-dev] Re: [abacus] Usage processing authorization, was: Usage
submission authorization
------------------------------



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* <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*
<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*
<https://www.pivotaltracker.com/story/show/101703426>

Piotr




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