Using flat-manager for private app repo

[Dan Nicholson]

On Tue, Apr 30, 2019 at 8:10 AM Alexander Larsson <alexl at redhat.com> wrote:
>
> On Mon, Apr 29, 2019 at 8:46 PM Dan Nicholson <nicholson at endlessm.com> wrote:
> >
> > To handle this, an additional "read" subject and scope would be
> > checked in the JSON web token. The existing repos and prefixes in the
> > token scheme could be reused. For example, consider a token with the
> > following payload:
>
> However, this is less ideal imho. I don't think we want the repo
> itself to do the mapping from user -> allowed to download. We want
> some separation of concerns here.

Maybe I wasn't clear, but this is definitely something I was trying to
pursue. I don't want the repo-server to know about users at all.
That's why I was using the claims in the web token the same way that
the API server is currently using. I left the user field in there
because that's how the tokens are currently generated, but that field
is not needed.

> The way I imagine it is that the client goes to an authentication
> server and says "I'm user $foo, with password (or whatever auth) $bar,
> please give me a token that allows me to download ref $app". The
> server then verifies things against the service db and sees that the
> user should be able to download this. Then it generates a token that
> says "this client is allowed to download $app until $time="now + 10
> min" and signs it with a private key that only the auth service knows.

This is the same as what I was envisioning except maybe the last part.
The way I was thinking about it, the authorization server would have a
long lived token that had read permissions for everything in a
particular set of repos. After authenticating the user and determining
what apps they had access to, it would call the flat-manager
/token_subset API with a subset of repos and apps the user could
access. Then the authorization server doesn't need a secret key at
all. flat-manager hands back a more limited token signed by it's
secret and the authorization server gives this to the user. Then the
user uses this token to authenticate to flat-manager and it can
validate the token. I believe this is exactly how the
flat-manager-client works right now.

> Then the repo server (like flat-manager) can know that certain (or
> all) refs require authentication and what signatures are needed to
> download those files.

I'm not sure what you mean here. How does the repo server know what
refs require authentication and what the allowed signature are?

> Furthermore, I belive that CDN services like fastly has support for
> tokens like this. For example, see:
>
>   https://docs.fastly.com/guides/tutorials/enabling-url-token-validation
>
> This means we can authenticate with the central service, and then
> download directly from the CDN which validates the token.

That's a very neat feature, but I don't believe this is common in
CDNs. Neither of the 2 we've used at Endless (CloudFront and BunnyCDN)
have any edge authentication.

--
Dan