Setttings service (and share manager) require a hardcoded internal service user

[rhafer]

Describe the bug

Since #3232 and cs3org/reva#2626 the settings service and the share manager required a service user for being able to access the CS3 storage. Currently they are using the hardcoded UUID 95cb8724-03b2-11eb-a0a6-c33ef8ef53ad for that. That UUID belongs to a user that is maintained in-memory by the accounts service. (https://github.com/owncloud/ocis/blob/master/accounts/pkg/service/v0/service.go#L104)

This will of course break when switching to the libregraph/idm bases user-management. As a workaround we currently created that user when bootstrapping the users database: ec4c92a
This is however a hack at best. As ideally this user should not be visible to the outside (e.g. via graph). We need to implement a proper solution for this.

AFAIU the service user needs to have some elevated permission (e.g. for being able to create a space for the metadata store). It needs to be present in the CS3 userprovider so that we can mint a valid token for that user via the machine-auth provider. It would be nice if we could implement this kind of functionality in a way that doesn't require the user to be present in the main user database (which e.g. might be an external LDAP server)

@wkloucek mentioned the possibility to enhance the machine authprovider or implement and addtional authprovider service that handles this type of user(s).

cc @C0rby @butonic

[wkloucek]

Also currently the service user needs to know the URL of the IDP, to successfully authenticate, which is not nice

[rhafer]

@micbar I've raised the priority of this, as this seems to have fallen through the cracks. I think this needs to be addressed before beta.

[rhafer]

@wkloucek mentioned the possibility to enhance the machine authprovider or implement and addtional authprovider service that handles this type of user(s).

Trying to summarize the discussion we had on this earlier today: We could setup an additional authprovider (and userprovider if needed), e.g. using the json driver for now, that is just used for authenticating services users like the one required by the settings service. That way we should be able to keep the settings user (and possible other internal/service users in the future) separated from "normal" users. I.e. they won't show up in the user management UI or when looking up users for sharing.

We also agreed that, while this is an improvement over the current state, it is still suboptimal and a proper service authentication mechansim (using mutual TLS?) would be a good thing to have.

@wkloucek , @C0rby , @butonic, @dragonchaser please add your thoughts here.

[micbar]

Closed. Implemented.