integrate with EKM to pull keys during setup

[tomholub]

part of #1298

EKM = Email Key Manager https://flowcrypt.com/docs/technical/enterprise/email-deployment-overview.html

OrgRule definitions https://flowcrypt.com/docs/business/org-rules.html

Here is OrgRule class on browser - I know we already have an existing implementation hera that may look different, but I would suggest aligning the Android approach (to parsing and using OrgRules) with the browser - by porting this class to kotlin and using the same wording for methods. If we do this on all three platforms, it will be much easier to review: https://github.com/FlowCrypt/flowcrypt-browser/blob/master/extension/js/common/org-rules.ts

Immediately after authentication when we receive the OIDC and OrgRules, we should check if orgRules.usesKeyManager() == true. If yes, we should:

• 1) check if orgRules.mustAutoImportOrAutogenPrvWithKeyManager() == true and if not, skip following steps (and instead show regular setup flow)
• 2) check if orgRules.mustAutogenPassPhraseQuietly() == false. If not, show an error that this combination of OrgRules (PRV_AUTOIMPORT_OR_AUTOGEN + PASS_PHRASE_QUIET_AUTOGEN) is not supported on this platform
• 3) check if orgRules.forbidStoringPassPhrase() == true. If not, show an error that this combination of OrgRules (PRV_AUTOIMPORT_OR_AUTOGEN + missing FORBID_STORING_PASS_PHRASE) is not supported on iOS.
• 4) check if orgRules.mustSubmitToAttester() == false. If not, show an error that this combination of OrgRules (PRV_AUTOIMPORT_OR_AUTOGEN + ENFORCE_ATTESTER_SUBMIT) is not supported on iOS.
• 5) check if orgRules.forbidCreatingPrivateKey() == true. If not, show an error that this combination of OrgRules (PRV_AUTOIMPORT_OR_AUTOGEN + missing NO_PRV_CREATE) is not supported on iOS.
• 6) get the EKM URL from key_manager_url OrgRule (already includes https://, but may or may not include a trailing slash - please normalize the URL to contain a trailing slash before you use the URL).
• 7) call GET <ekm>/v1/keys/private. Into authorization header please put Bearer <ID_TOKEN>. On error, offer retry
• 8) if there are no private keys there (empty array), show an error to the user that there are no private keys configured for them and that they should ask their systems administrator or help desk. Offer retry
• 9) ask user to provide a passphrase (similar UI to creating a new key), then ask to confirm
• 10) encrypt the received keys with the pass phrase. Keep pass phrase in memory option to only keep pass phrase in memory #372 , store encrypted key in storage
• 11) finish setup without any further user interaction
• 12) do not submit any public key to attester(added by @DenBond7)

The goal is that if user has keys already configured on EKM and appropriate OrgRules are in place, they only need to authenticate and choose a pass phrase, and everything will be done automatically. After authentication and successful automatic setup, they will be sent to their inbox.

In this flow, do not submit any public key to attester.

[tomholub]

@DenBond7 this task is ready to implement. Maybe you will want to do some prepwork first in a separate PR, client class for EKM, things like that. You can then test this functionality on your company account - the OrgRules are not fully matching there but the EKM url is there, so you can authenticate with the EKM and try retrieving your keys etc as if the OrgRules were set that way. Then you can mock it up.

[DenBond7]

#748 #750

[DenBond7]

@tomholub Could you clarify this one?

1. send OIDC token to EKM to retrieve an access token and store it. Fail on error, offer retry

Here #748 is described the current logic that we have for enterprise users. I'd like to have more details about retrieve an access token and store it. Do I need to call some API?

[tomholub]

Actually, for EKM, you can skip this access token handling - I just newly found out. Therefore, you can take the OIDC token and use it directly to call GET keys endpoint.

[DenBond7]

[tomholub]

• please update domain==google.com to domain IN (googlemail.com, gmail.com)

[tomholub]

• please skip the GET <EKM>/v1/access-token step, and the storage of access token. Instead, send OIDC token to <EKM>/keys/private in next step

[tomholub]

Otherwise all good. It seems that you will have to implement #372 first as a pre-requisite.

Thank you for this chart!

[DenBond7]

I've updated the chart to fit all needs.

[tomholub]

Looks good! The final functionality will also be changed by #1202 but that's not relevant for this particular issue. It can be changed after. The outcome will be - instead of calling flowcrypt.com/api, the app will first try opportunistically calling https://fes.customerdomain.com to see if there is an API running there instead. If yes, use that, if no, use FlowCrypt backend. But that's for later.

[DenBond7]

@DenBond7 Add tests for the following cases

• Login. Show retry if failed
• Get domain rules. Show retry if failed
• Handle all cases for "org rules combination is not supported"
• Get private keys via ekm. Show retry if failed
• Get private keys via ekm. Empty list
• Get private keys via ekm. Return not fully decrypted key

[tomholub]

Also a successful scenario test, in case you don't have it yet.