Skip to content

rethink credentials/metadata stored in nimbella credential store #33

@rabbah

Description

@rabbah

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions