additional EKM updates to the app

[tomholub]

part of #1298 after #1168

when the OrgRules show that EKM is in use:

• forbid adding keys in settings -> keys
• forbid updating or modifying keys in settings -> keys
• forbid removing keys in settings -> keys
• forbid exporting or showing private keys

[DenBond7]

when the OrgRules show that EKM is in use:

1. Do you mean the following if orgRules.usesKeyManager() == true?

2. About forbid. Would you like to see a toast with a hint or should I hide Views(buttons and etc.) if possible?

[tomholub]

Do you mean the following if orgRules.usesKeyManager() == true?

About forbid. Would you like to see a toast with a hint or should I hide Views(buttons and etc.) if possible?

Best is to hide buttons that lead to views, and then also the view itself should self-disable in case user ends up on it anyway through some other bug or oversight.

[DenBond7]

I'm thinking about this one. For now, I just store flags for OrgRules. But it seems it's not enough.

Looks like I need a separate table to store full details about OrgRules. I'm not sure about that because I don't know the full logic for the enterprise. @tomholub What do you think about that?

If we have to use OrgRules during the whole app(not just for setup only) it seems I need a separate table.

[tomholub]

You'll need to store OrgRules it it's complete form, not just the flags - they are useful throughout.

Actually, it may not be completely wrong to store it as a JSON in a single field. Then it's flexible to changes, when we add more OrgRules attributes for example.

[DenBond7]

Actually, it may not be completely wrong to store it as a JSON in a single field. Then it's flexible to changes, when we add more OrgRules attributes for example.

I thought about JSON too. As we support compatibility for older versions for that API, JSON can be a good candidate

[DenBond7]

@tomholub I need advice about migration.

What we have now (ver 1.1.9)

we call https://flowcrypt.com/api/account/get and receive the following

{
   "account":{
      "email":"...",
      ...
   },
   "subscription":{
      ...
   },
   "domain_org_rules":{
      "flags":[
         "NO_PRV_CREATE",
         "NO_PRV_BACKUP",
         ...
      ],
      "key_manager_url":"https://ekm.flowcrypt.com",
      "enforce_keygen_algo":"ecc25519",
      "enforce_keygen_expire_months":6
   }
}

then I save AccountEntity.domainRules as String = "NO_PRV_CREATE, NO_PRV_BACKUP, ..."

After the migration, I should have the following

AccountEntity.domainRules as String = "{"flags": ["NO_PRV_CREATE", "NO_PRV_BACKUP", "NO_ATTESTER_SUBMIT", "PRV_AUTOIMPORT_OR_AUTOGEN", "FORBID_STORING_PASS_PHRASE", "NO_KEY_MANAGER_PUB_LOOKUP"], "key_manager_url": "https://ekm.flowcrypt.com", "enforce_keygen_algo": "ecc25519", "enforce_keygen_expire_months": 6}"

But I don't know about "key_manager_url": "https://ekm.flowcrypt.com", "enforce_keygen_algo": "ecc25519", "enforce_keygen_expire_months": 6 for existed users(that already added to the app 1.1.9).

[tomholub]

Don't worry about them, there are no actual customers using it right now. Only users on flowcrypt.com domain.

It's ok to migrate it as {"flags": [...]} only and ignore the other parts.

Separately/alternatively, we should be eventually pulling OrgRules again from FES on every startup of the app, in background (don't hold up UI functionality while fetching). It doesn't need authentication, so it should be pretty easy to loop through all set up accounts and re-fetch/re-save the client configuration. I'll save another issue. That will also solve this.

Also can you rename the domainRules to be call clientConfiguration instead?

[DenBond7]

Only users on flowcrypt.com domain.

It's ok to migrate it as {"flags": [...]} only and ignore the other parts.

Got it.

Also can you rename the domainRules to be call clientConfiguration instead?

In that case, I propose to delete domainRules and add clientConfiguration column. There are no too many users for flowcrypt.com, they should relogin in the app to have a workable version, because after upgrading they will have clientConfiguration == null

[DenBond7]

• database migration

[tomholub]

I'd make the default client configuration to be {"flags":[]}. Then you have fewer special cases, one less null to worry about?