Story #3897

Updated by Tom Clegg about 5 years ago

The usual methods method by which a client authenticates to Arvados are
*
is via the ARVADOS_API_HOST, ARVADOS_API_TOKEN and ARVADOS_API_HOST_INSECURE environment variables. There are some drawbacks to this method: e.g. the environment variables
* $HOME/.config/arvados/settings.conf

Both methods stop being convenient when
have to be set each time a given UNIX shell account is used to user logs in, a program can authenticate to more than a single only one Arvados account instance at a single time, users cannot easily manage authentication credentials for multiple Arvados instance with instances, etc.

It would help here to have
a single API token. Both methods are just plain useless when a single process uses mechanism that is shared by any CLI tool using the Python or Ruby SDKs, permitting credential management for multiple Arvados accounts/instances/tokens (e.g., arv-copy). instances in a consistent and convenient way.

The Python SDK has There are several possibilities:
* Clients could use @$HOME/.config/arvados/instance.conf@ as
a concept source of a connection profile (API version, host, token, insecure flag). This concept should be extended to configuration files: the choice of which credentials/endpoint to use can be indicated authentication tokens (the approach currently taken by a path to a configuration file.

For example, these
@arv-copy@)
* Environment variables
could be equivalent:

<pre>
named for their parent instance, e.g.:
arv --auth-file ~/.config/arvados/foo.conf user current ** @ARVADOS_API_HOST_QR1HI=qr1hi.arvadosapi.com@
arv --auth foo user current
</pre>
** @ARVADOS_API_TOKEN_QR1HI=....@

Notes:
* Avoid the obvious command line parameter name @--config@ for choosing a connection profile, despite the tempting @~/.config@ path convention. This causes confusion between configuration and authentication. (When the arv tool gets real configuration options, like default output format, visual editor, and auth profile, we'll want those configs
The goal of this story is to be orthogonal to choose an authentication profiles.)
* Avoid assuming there
mechanism that clients can use consistently across tools, and that is only one auth profile per Arvados instance. In documentation, avoid directing users to make qr1hi.conf. Something like @tom@qr1hi.conf@ makes it more clear what's happening.
* Leave room for supporting a file format like yaml,
supported and multiple auth profiles per config file. But for now, @~/.config/arvados/{string}.conf@ provides a decent amount of flexibility.
documented properly by the doc site and Workbench.

Back