--nobearertoken not behaving fully as described

[DrDaveD]

The help message for --nobearertoken says it will get a vault token, not a bearer token. It actually does get one, but in many cases it will not store the vault token as one would expect from the description.

[shreyb]

I ran into this issue when testing a proposed update to managed tokens (https://github.com/shreyb/managed-tokens/issues/9) and discussed it with @DrDaveD - who pointed me to this known issue.

The motivation here is to store --nobearertoken in HTGETTOKENOPTS, and then call condor_vault_storer (which would pick up the flag when it called htgettoken). My hope is that in this way, we would only pull down the vault token, without downloading a bearer token, and store the vault token in the Condor credd.

For my test, I did the following:

[sbhat@HOST ~]$ kinit -k -t /path/to/keytab.keytab testuser/kerberos@PRINCIPAL.DOMAIN
[sbhat@HOST ~]$ export HTGETTOKENOPTS="--credkey=correct_credkey --nobearertoken"
[sbhat@HOST ~]$ htgettoken -a htvaultprod.fnal.gov -i mu2e -r production -v
Initializing kerberos client for host@SERVER
Negotiating kerberos with https://SERVER:8200
  at path PATH
Connecting to 131.225.110.229
Attempting to get bearer token from https://HOSTv:8200
[sbhat@HOST ~]$ ls /tmp/vt*
ls: cannot access /tmp/vt*: No such file or directory

I'd have expected there to be a vault token written to the client here, but that wasn't the case.

[DrDaveD]

Note that condor_vault_storer would also need to be modified to use this, since it currently expects there to be a bearer token. It would probably need to look in $HTGETTOKENOPTS and behave a little differently if --nobearertoken was included.

[DrDaveD]

I also just noticed that using --nobearertoken when there is a valid vault token silently exits without doing anything, even with -v, and also that when there isn't a valid vault token and kerberos is used then with -v it still prints Attempting to get bearer token but then silently exits without doing it.