Using flat-manager for private app repo

[Alexander Larsson]

On Mon, Apr 29, 2019 at 8:46 PM Dan Nicholson <nicholson at endlessm.com> wrote:
>
> At Endless we have a desire to have private app repos and have been
> looking at having flat-manager manage the access. It already has a lot
> of the pieces to manage build access. My hope is that this can be
> extended to cover reading the repository.
>
> The simple implementation we thought of is to limit access to commit
> objects and delta superblocks. If you can't fetch the commit object
> then you can't install the flatpak. The server would maintain a map of
> refs to commits and deltas and only return them when the user was
> authorized. A more complete implementation would limit access to all
> of the objects referenced by the commit, but it's much simpler to just
> handle refs and commits.

Yeah, this sounds good to me.

> 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.

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.

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.

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.

Its possible that to make this work flat-manager needs to know to set
some property on the urls that the CDN need to validate tokens for.
This needs some research, but I think it is fundamentally doable in an
safe, scalable way.