Problem

Currently, one account can only be associated with one appID. This seems to be an issue, because some configurations a specific appID per each role.

Solution

Allow to optionally specify multiple appIDs depending on role using a map field appIDsByRole in the account struct.

Example:

accounts:
  - name: ACME Dev
    appIDsByRole:
      admin: "123456"
      readonly: "987654"
    accountID: "111111111111"
    profileName: acme-dev

roles:
  - admin
  - readonly

Backwards compatibility

This is backwards compatible, because if appIDsByRole is not specified, the appID field is used.

Problem

Currently, we have to manually build and upload the binaries for each release.

Solution

Use GoReleaser to automate the release process.

Notes

• https://goreleaser.com/

Release workflow after this PR

• Create a new tag
• Push the tag
• GoReleaser will build and upload the binaries to GitHub

Notes:

• The tag must be in the format vX.Y.Z (e.g. v1.2.3)
• The binaries will be uploaded to GitHub under the release with the same name as the tag
• Release notes will be generated from the PRs merged since the last release, so take care to write good PR titles and descriptions

Problem

Currently, the path to the config file is hardcoded to ./config.yaml and is searched in the current directory.

This behavior is convenient when there are multiple companies and each company has its own config file in a separate directory.

But for a client with a single company, it is inconvenient to have to call the program from the specific directory every time.

Solution

Add a new environment variable ONELOGIN_AUTH_CLI_CONFIG_FILE that, when set, will override the default path to the config file.

A user can set this variable in the shell profile and then call the program from any directory.