boundary authenticate (type) can conflict with BOUNDARY_AUTH_METHOD_ID

[jorhett]

Describe the bug

The command boundary authenticate requires the user to provide a type oidc or password.
It also accepts setting the auth-method via BOUNDARY_AUTH_METHOD_ID ... which makes the user selection unnecessary, and potentially wrong. If a user environment is set up correctly for OIDC auth but they type the wrong option here they get incorrect instructions.

$ env |grep BO
BOUNDARY_AUTH_METHOD_ID=amoidc_wLLVtNa5kA

$ boundary authenticate
Usage: boundary authenticate [sub command] [options] [args]

  This command authenticates the Boundary commandline client using a specified auth method. Examples:

    Authenticate with password auth method:

      $ boundary authenticate password -auth-method-id ampw_1234567890 -login-name foo -password "bar"

  Please see the auth method subcommand help for detailed usage information.

$ boundary authenticate password --login-name innocent-user --password exposing-my-login-password-in-shell-history

To Reproduce
Steps to reproduce the behavior:

1. Set BOUNDARY_AUTH_METHOD_ID to an oidc method
2. Run boundary authenticate by itself
3. Receive instructions to login with password from help output
4. Run boundary authenticate password (because user doesn't recognize oidc)
5. Failure. User is frustrated, contacts helpdesk

Expected behavior

• User should not be required to select oidc or password when BOUNDARY_AUTH_METHOD_ID is set
• User should not be given an example with ampw_1234567890 without any mention that this value cannot be used as-is
• User should not be instructed to put their password on the command line by a security application!! The help example should demonstrate good behavior, like prompting for it

[jefferai]

The CLI help text is outdated -- I'll get it fixed up. Thanks for the pointer!

[jefferai]

Closing this via #1835. A couple of notes:

• We'll eventually be removing the type-specific prefixes (e.g. ampw and amoidc will just be am for both) as when working on plugins we found that there are issues with trying to extend support arbitrarily. This also means the CLI wouldn't be able to pick a type by itself, the user will have to indicate type, so keeping that as-is for now.
• While I'm empathetic about showing an auth method ID that can't be used, the output of boundary authenticate indicates that it's examples. If users aren't figuring out that they need to substitute that in, you may simply need to give them a more specific example :-/

[jorhett]

• We'll eventually be removing the type-specific prefixes (e.g. ampw and amoidc will just be am for both) as when working on plugins we found that there are issues with trying to extend support arbitrarily. This also means the CLI wouldn't be able to pick a type by itself, the user will have to indicate type, so keeping that as-is for now.

Would you not be able to add another environment variable? Remember that Boundary is and probably will remain overly complex for the vast majority of people whom we want to use it. Allowing us to pre-provision their environment so that stuff "just works" is going to be very important. "They are going to be responsible for typing long complex command lines" is not workable.

• While I'm empathetic about showing an auth method ID that can't be used, the output of boundary authenticate indicates that it's examples. If users aren't figuring out that they need to substitute that in, you may simply need to give them a more specific example :-/

We do give them instructions. But the problem was that the help text was very directive on how to use, and made use of a value without mentioning that it was a variable. This requires a person to be trained in Boundary to read the help text and recognize that it is a value they must supply.

To be honest your change in #1835 missed a significant part of this confusion as what the user sees isn't mapped to the example text:

$ boundary authenticate
Usage: boundary authenticate [sub command] [options] [args]

Your help text does tell them what sub commands are available, but never mentions auth-method. I'm also not convinced "sub-command" is the right text for someone to grasp the meaning. This seems to be conflating implementation with meaning, no?

Would something like this not be more clear?

Usage: boundary authenticate MECHANISM [--auth-method AUTH_METHOD_ID] [options] [args]

...

MECHANISM:
    oidc        Invoke the OIDC auth method for SSO authentication with Boundary
    password    Invoke the password auth method to authenticate with Boundary
    
AUTH_METHOD_ID:
   A value unique to your environment which must be provided unless supplied by the environment variable BOUNDARY_AUTH_METHOD_ID