Issue 1219 poc service accounts

[hexaltation]

This is an evolving PR with draft status
Following lines MUST evolved across development

Context

This PR add an API as a first implementation of service accounts as defined in previous discussions. C.F. #579 #1115

Proposed solution

In evolution

Under the hood, Service account is a just a user account.
It can act exactly like a user account.
It has the same action as a user account.

It's differentiated by the following elements:

1. a type column in user table. type=login|service

2. A table handling:

   • id
   • description,
   • endOfLive,

• Label/key-name can stored in users.name

• technicalId can be the logins.email or the email_username (part before the @)

3. An associative table linking Service account to its owners and to its associated user/personna.

4. Service accounts are not allowed to connect through web.

DB schema updates

The two previous features have to be implemented in the table.

API description

base endpoint : /api/service-accounts

CREATE Service Account

POST /api/service-account

• Authorizations: ApiKey

Request Body schema: application/json

• label: <String>
• description: <String>
• endOfLife: <String>

endOfLife is a String that can be parsed as a date. Following the date time string format specification.
To be discussed Possibly a -1 EndOf life will give never ending Service Account

Response

200

An object containing :

• Service account APIkey: <String>
• Service APIkey technical id: <String>

400
on invalid endOfLife

UPDATE Service Account

UPDATE /api/serviceaccount/{saId}

• Authorizations: ApiKey

path Parameters

parameter	type
saId required	string A string id (UUID)

Request Body schema: application/json

• label: <String>
• description: <String>
• endOfLife: <String>
• ownerId: <Number>

** Verify if ownership transfer is still a thing **

Response

200

• Service account object as updated: <Object>

READ Service Account

GET /api/serviceaccount/{saId}

• Authorizations: ApiKey

path Parameters

parameter	type
saId required	string A string id (UUID)

Response

200

• Service account object: <Object>

DELETE Service Account

DELETE /api/serviceaccount/{saId}

• Authorizations: ApiKey

path Parameters

parameter	type
saId required	string A string id (UUID)

Response

200

• A deletion confirmation message ?

The 200 instead of 204 is chosen to be consistent with other DELETE routes in grist.

READ Service Accounts by Owner/GroupOwner

GET /api/servicesccounts

• Authorizations: ApiKey

path Parameters

parameter	type
UserId required	number

Response

200

• List of service account objects: <Object>[]

To be answered questions / decision to be made

• What is the form of emails given to the service accounts ?

  For this first draft the opiniated option is
  [email protected]
  It must be a domain that for sure is rejected for web login.

• What happened to documents owned by a Service Account on service account deletion ?

In an API point of view it's not handled. It the duty to the key owner to perform an UPDATE call with a new ownerId.

• Can service account create documents ?

Yes, if the linked persona as been added as editor on a workspace or org.

• How implement a logic like can't edit it's own Rights (Only lowering it)

Yes a every users. The only difference its that it can be deleted by another user.

• Can multiple users have access to the same key ?

Let say no for the first implementation. The good news is that is inherits its owner rights.

A service account max right is its owner max right.

Can a service account be owner of another service account ?

To be determined

Related issues

fixes #1219

Has this been tested?

• 👍 yes, I added tests to the test suite
• [ x ] 💭 no, because this PR is a draft and still needs work
• 🙅 no, because this is not relevant here
• 🙋 no, because I need help