Sensitive Key Storage Tables

[gabestein]

Motivation

So developers can store and query sensitive keys in the production database without risk of leakage
So developers can build the datacite and google drive actions

Requirements

• Command-line utility that allows developers to locally encrypt a password
• Database tables that can store encrypted passwords and, optionally, usernames or other non-sensitive information (e.g. DOI prefix) with a unique queryable name (e.g. Datacite DOI Prefix)
• Ability to specify that keys are global or only accessible within a specific community
• Ability for Actions to get contents of specific keys by name
• Ability for Actions to decrypt encrypted keys when run

Acceptance Criteria

• Could use Legacy encryption strategy of encrypting with vector
• Developers can add keys manually to table for now; eventually, should be addable and deletable by admins, for community-level, and superadmins, for global, via a UI

[kalilsn]

If our first use case is just authenticating to the google drive API, I'm not sure we even need encrypted storage. We can pretty easily authenticate requests to that API with oauth (and request offline access) to get a refresh token, which we can safely store in postgres because it has timed expiration, can be revoked by the user, and is worthless without our client secrets which we can store in an env var. I think that would be quicker to implement than encrypted storage since the google guides are easy to follow.

[tefkah]

where would we store the auth token in postgres? the way the drive action will currently work is that there won't be any user configurable tokens at all, we will just use a "pubpub-bot" account that users will add to documents they want to import. they give us an explicit link to a specific document (or we read it from the pub), and will only be able to access it if our bot is added to that doc.

in this case, we can just read an env var no? maybe we need to temporarily write a refresh token to the file system as suggested here (https://developers.google.com/drive/api/quickstart/nodejs) but that wouldn't be that big of a problem right?

[gabestein]

Yes, we can use env vars for gdrive for now. But we do need some way to store the datacite credentials on a community-by-community basis.

[tefkah]

Any usecase you see where we would want global sensitive keys rather than always scoping them to the community? i feel for those cases we would almost always set them through env vars, although being able to change them through the ui would be convenient.

[tefkah]

ill suggest that the table look something like this

model SensitiveData {
  id String
  name String
  type SensitiveDataType
  communityId String // maybe optional if we really need globals
  encryptedCredential String // the encrypted credential
  otherInfo JSON? // other info  (username, datacite info) stored as a json object. 
                               // we can then parse that based on the `type` in `core`
                               // eg we would know that it would contain the doi prefix if `type === DataCite`.
}

enum SensitiveDataType {
  genericPassword
  genericAPIToken
  datacite
  crossref
  // other specific credentials, eg GDriveOauth
}

i think having that enum in the db makes it easy to figure out in our app what how to handle the data, similar to how we do the actions.
in fact, we probably should create something similar to our action definition thing for the credentials. kind of similarly to how n8n defines credentials and their way of authenticating with them (https://github.com/n8n-io/n8n/blob/master/packages/nodes-base/credentials/GithubApi.credentials.ts)