the current implementation attaches a commander object to a namespace.
"commander": {
"clients": {
"aaa....": {
"accountName": "Commander CLI",
"username": "aaa...",
"password": "bbb...",
"client": "cli"
},
"wxyz": {
"accountName": "x",
"username": "wxyz",
"password": "abcd",
"client": "cli"
}
}
}
But we are moving toward associating the commander login with the nimbella namespace, much more tightly, because this has the advantage of treating the command namespace as just another nimbella identity in the credential store. With that, I have the following questions:
Does the metadata need to store the username/password
? note that in the case of the account name === "Commander CLI"
these values are redundant with the namespace properties already in the credential store?
If the client token is used to retrieve the namespace token, and a nimbella login is performed, the working identity is a first class instance of a Credential
object. In this case, the commander metadata may need to only store the client (cli, slack, etc) that is associated with the namespace.
I think there is room here to clarify both the design and implementation.