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

Well, then I think the plugins approach is not a bad approach to
consider, because imagine you want to go using an Oauth2 or something
that requires some special treatment to get credentials, if you
implement the authentication flow in the client, then all the clients
must have the same own implementation, so you might end up with
clients unable to use some repos (including the Flatpak CLI).

That shouldn't happen if the flow is implemented into something that
Flatpak could call independently of the client, like a plugin, which
can depend on webkit or not, our particular case doesn't require any
user interaction to get the credentials, for example.

Then you'd have to think how to associate the repo's auth-server to a
particular plugin, I'm starting to think, instead of having a
xa.entitlement-server-url you could have a more flexible
xa.auth-provider, for example:

xa.auth-provider = eos?url=https://flatpak-auth.endlessm.com

This would tell Flatpak to use the "eos" auth provider (if the .so
file is available) and initialize it with the parameters
url=https://flatpak-auth.endlessm.com, this plugin would access the
user's key ring to retrieve the pull token. Another provider could
start an OAuth2 flow. This would work with all clients.

> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                Red Hat, Inc
>        alexl at redhat.com         alexander.larsson at gmail.com



-- 
Damián Nohales  |  Endless