Unable to remove any secure credentials from a V2 Teams service profile once entered

[davidkjackson54]

This problem was found when modifying VSCode Explorer code to use V2 Teams profiles.

The user enters his secure credentials into the service profile and also sets a default set of credentials in the base profile.
Once this has been done, there is no current means of removing the secure credentials from the service profile to allow that profile to default to the base profile values.
This problem exists in the cli zowe config secure command and also needs to be addressed in the ProfileileInfo class to allow the credentials to be removed by VSCode applications in code.

Currently the only workaround is to delete all the zowe related credentials from the Operating System's secure vault which is risky should the user inadvertently select the wrong entry to be deleted. That also requires the user to then have to re-enter all his credentials again which is a poor user expereince.

[MikeBauerCA]

@t1m0thyj @davidkjackson54 are the service secure creds removed if you delete the properties from the secure array in zowe.config.json and then rerun the zowe config secure command?

In some cases, skipping questions in the secure array and the values staying the same is desirable. For example, if my config uses 4 sets of creds for different LPARs and I only want to update one set. I can run zowe config secure, update the one set I need, and skip the rest.

[davidkjackson54]

If the zowe.config.user provides a higher level argument and a lower level service profile also provide the argument, then it will take precedence. If the user wishes to revert to using the higher level profile then he needs to be able to 'undo' his credentials from the service profile.
For example:
Please enter profiles.D001.properties.user: xxxx
Please enter profiles.D001.properties.password:
Please enter profiles.D001.profiles.u820all.properties.user: yyyy
Please enter profiles.D001.profiles.u820all.properties.password:

yyyy will take precedence.
There is currently no means to later remove the credentials from the u820all profile to allow the higher level xxxx to take precedence.
Having to delete the zowe entry from the secure vault in the Operating system is not a good workaround as it then requires all properties to have to be re-entered again.

[t1m0thyj]

are the service secure creds removed if you delete the properties from the secure array in zowe.config.json and then rerun the zowe config secure command?

@davidkjackson54 The above method suggested by @MikeBauerCA works for me to stop yyyy from taking precedence.

If I remove (or comment out) the user and password properties in the secure array of the D001.u820all profile, then xxxx is used rather than yyyy.

{
    "$schema": "./zowe.schema.json",
    "profiles": {
        "D001": {
            "type": "zosmf",
            "profiles": {
                "u820all": {
                    "type": "zosmf",
                    "properties": {},
                    "secure": [
                        //"user",
                        //"password"
                    ]
                }
            },
            "properties": {
                "host": "example.com",
                "port": 443
            },
            "secure": [
                "user",
                "password"
            ]
        }
    },
    "defaults": {
        "zosmf": "D001.u820all"
    },
    "autoStore": true
}

[davidkjackson54]

@t1m0thyj @MikeBauerCA
I understood that the purpose of zowe.config.json delivered as a team profile to the user removed the need for the user to have to subsequently go editing that file and that any user modifications etc would be managed in a zowe.config.user.json file ?
In this example, the user inadvertently entered his credentials against u820all when he wanted to allow the LPAR value to take precedence. Having set it via a command, there should equally be a command to remove it (plus the corresponding support in ProfileInfo).

Having the user edit a supplied zowe.config.json would seem to be going against the principles of having a team profile in the first place? that is essentially what the article Zowe CLI — Getting Started, Made Easy! refers to:
"...However, the beauty of this approach is it is now done for your team. Nobody else needs to undertake this endeavor. If you provide them with the zowe.config.json you created, they can drop it into their .zowe folder, issue zowe config secure to enter their credentials, and be on their way, accessing as many services as you set up...."

[zFernand0]

I believe that the ProfileInfo side of this issue was achieved by using the updateProperty() and setting the value to undefined
I guess a zowe config unset profile.u820all.properties.user command will be the other portion of this issue 😋

[github-actions]

Thank you for raising this issue.
The community has 90 days to upvote 👍 the issue.
If it receives 5 upvotes, we will move it to our backlog. If not, we will close it.

[t1m0thyj]

Closing this issue as the initial question about how to delete secure credentials with the ProfileInfo API has been addressed here. Additional enhancements can be tracked in separate issues:

• New CLI command to delete secure props - Secure properties from non-existent files are not deleted imperative#547
• Better API method to remove secure props - Add removeKnownProperty method to ProfileInfo API imperative#917