Entitlement server and protected repos support

[Damián Nohales]

On Thu, May 23, 2019 at 4:19 AM Alexander Larsson <alexl at redhat.com> wrote:
> > The only thing I cannot see integrating well to upstream is the
> > mechanism to get the credentials to talk to the entitlements server.
> > In our specific case, these credentials lives in the user's keychain,
> > so it's fetched using libsecret and an Endless specific SecretSchema.
> >
> > So maybe we can create some sort of entitlements-server credentials
> > providers that are dynamically loaded as plugins so each distro can
> > provide their own .so files with the specific implementations?
>
> Yeah, this is really the crux. Once we have a token everything is
> pretty simple, but getting the token fundamentally depends on details
> about the authentication system used by the particular system.
>
> On a system like Endless (or even RHEL) your host OS would already
> have some kind of entilement which is kept up-to date by the OS
> itself. This could easily be passed by flatpak to a http API with some
> standard API, which returns the token you would use for the pull.
>
> I imagine the for each remote you configure a url to the authenticator
> service, and a path name to the entitlement (or alternatively a
> commandline you run to generate the entilement). Then flatpak would
> load/run this, and send the extracted entitlement data to the
> configured url. Flatpak wouldn't need to understand the entitlement
> data, it would just forward it, and while the API is generic the
> backend is specific and will know the entitlement format.
>
> However, that only works because there is some kind of constantly
> running entitlement system. What about systems that don't do this.
> Consider for instance if steam was using flatpak, and you ran flatpak
> update. How would it know to pass the steam username and password to
> the steam auth server? I wonder if we can define a standardized
> interactive way to solve this. This sounds *exactly* like OAuth2, so
> maybe we can use that? Like, have a standardized API in libflatpak
> that allows the client to implement oauth for the authentication
> stuff. I mean, it would mean having the client having to render a
> webpage for the login, but in practice you just take a dep on some
> webkit thing.
>
> I wonder if oauth is flexible enough to handle the pre-entitled case
> too. Then Oauth2 could be the standardized authorization API for both
> of these cases.

Hello Alex,

So, after talking to the team at Endless, specifically about this
situation. We are finally thinking of this approach:

The repo will have in its configuration (in the summary) two new options:
  * xa.authenticator: Which can be a query string with multiple
parameters describing the way the repo should manage the
authentication.
  * xa.authenticator-gpg-key: The public key the repo must use to
validate pull tokens.

On the other hand, we will create a D-Bus interface called
org.flatpak.Authenticator, anything outside Flatpak could implement
that interface, right now, I'm thinking that interface could have only
one method called GetToken which accepts what's inside the
authenticator, the refs that Flatpak wants a token for and basic
information about the remote (like URL and Collection ID), and returns
the bearer token to be used in the pull requests.

So basically Flatpak doesn't know anything about how to get the token
at all, but it delegates that work to the available services
implementing org.flatpak.Authenticator. It only knows what is returned
there, must be used as Bearer token afterwards (unless we want to be
flexible there too). Depending on the information in xa.authenticator,
the authenticator could try to fetch the token, or ignore the request
and return null. When Flatpak detects an authenticator returning
something, it stops calling the rest.

What to put in xa.authenticator exactly is something I haven't think
about, but's that's something we may want to keep it flexible? for
example:

- url=https://login.service.com
- type=oauth2&url=https://whatever.example.com
- type=steam

Let me know what do you think.

-- 
Damián Nohales  |  Endless