Vscode-extension-for-zowe: Use keytar module bundled with VSCode

[ghost]

Currently using the SCS plugin with Zowe Explorer results in worse performance, because a separate Node process must be spawned to access credentials.

Historically, spawning a process has been necessary because credentials are stored securely using the keytar module, which contains native code.

Going forward, it seems that spawning a separate process may no longer be necessary. keytar is now bundled with VSCode, which makes it more convenient for extensions to access. We should be able to use this bundled version as described here: https://code.visualstudio.com/api/advanced-topics/remote-extensions#persisting-secrets

[zFernand0]

Keypoints:

• Look for the .zowe config.overrides to make sure that the global CLI is using a credential manager or not.
• Implementation of the keytar module will need to know about the service name used either by the plugin, or the default Credential Manager.

[Colin-Stone]

Keypoints:

* Look for the `.zowe` config.overrides to make sure that the global CLI is using a credential manager or not.

This is the same way we decide if we are performing the spawnSync or not.

* Implementation of the keytar module will need to know about the `service` name used either by the plugin, or the default Credential Manager.

Yes I get conflicts in zowe explorer as it will expect service to be vscode-extension-for-zowe but because of the version of cli I have installed I'm getting service name@zowe/cli This means that the credentials keys cannot be resolved

[Colin-Stone]

Do we therefore have the equivalent of
const keytar = getCoreNodeModule('keytar'); await keytar.setPassword('my-service-name', 'my-account', 'iamal337d00d'); const password = await keytar.getPassword('my-service-name', 'my-account');

[zFernand0]

This is the same way we decide if we are performing the spawnSync or not.

:+1:

Yes I get conflicts in zowe explorer as it will expect service to be vscode-extension-for-zowe but because of the version of cli I have installed I'm getting service name@zowe/cli This means that the credentials keys cannot be resolved

When initializing the credential manager, we will need to provide the necessary serviceS (@zowe/cli, @brightsode/core, any-constant-string-for-secure-plugin) in order to provide a seamless experience when accessing the credential vault using the vscode.keytar module. : )

Do we therefore have the equivalent of ...

I do not believe we need to duplicate everything there as long as we can provide the right services and the keytar module to a newly initialized credential manager.

[Colin-Stone]

Thanks Fernando. I'm trying to find the point where I can initialize the cred manager. I've incorporated the keytar "require" functionality inside the zowe explorer initialize, but I don't know how I inject into the credential initialization

[zFernand0]

They two important file here may be the src/getAllProfiles.ts and src/getDefaultProfile.ts
A possible implementation could be something similiar to what I was trying to do with the credential manager on the move2zowe branch :)
https://github.com/zowe/vscode-extension-for-zowe/blob/move2zowe/src/getAllProfiles.ts

[Colin-Stone]

Thanks for highlighting those, Fernando. So we still need to spawn.

[zFernand0]

Thanks for highlighting those, Fernando. So we still need to spawn.

That was the way I was trying to make the keytar version (installed globally by the secure-credential-store plugin) work with the extension... However since we are going to use the keytar.module from vscode we should be able to use imperative as another regular API when it comes to credential manager usage.
I know this may sound abstract or too theoretical at the moment. sorry :(

[Colin-Stone]

No that's fine thank you. I've had a good plough through the various elements today so getting a better handle on it. I was hoping impreative might have a handy API we could use but didn't find one. Need to look harder ;-)

[Colin-Stone]

@zFernand0 I've pushed a branch called "keytar" which I am experimenting with. This is what I have discovered so far

• Keytar is required if using the Default Credential Manager.
  
  
  
  • VSCode can load Keytar dynamically.
  
  
• The CLI Credential Manager interfaces with the OS key chain using a reference that is related to the node job. This is the "name" value in the CLI package.json file.
  
  
  
  • VSCode can initialize the CLI Credential manager (in it's own process) and can control the reference used to access the user/password credentials from the keychain/store created by VSCode or CLI. (@zowe/cli)
  
  

• If the Secure Credential Store plugin is installed in CLI, VSCode can initialize the CLI Credential manager to use the same reference as SCS and can access thise credentials. Do we want VSCode to save also?.

• All this is happening within the VSCode process. No spawning and therefore no performance hit.

• The only negative so far is that if accessing (from VSCode) credentials created by CLI. A (one time) pop up will appear from the OS credential manager requesting access to each of the user and password values maintained by it. I expect the reverse will be true (CLI accessing VSCode created credentials)

TODO
Still need to confirm if Keytar necesary when using the SCS?. Tests so far are including keytar.

[Colin-Stone]

@zFernand0 Should we combine this item with https://github.com/zowe/vscode-extension-for-zowe/issues/295

[zFernand0]

@zFernand0 Should we combine this item with #295

I think it makes sense to combine them, that way we eliminate any transition issues (from @brightside to @zowe) when we start exposing keytar : )

[zFernand0]

PR #400 merged. Closing! : )