Add support for Artifactory's user-password auth

[maxvt]

On Artifactory accounts with extra security enabled, users don't appear to be able to generate their own API keys - they are required to use their username and an encrypted password. This change makes Stove work with this authentication scheme.

[tas50]

Ping @coderanger on this one

[coderanger]

I have no plans to add this. The whole Chef ecosystem for artifactory is set up for using just the token. This feels like too much of a security footgun to support.

[maxvt]

Multiple players in the ecosystem (bundler, apt, and other package systems that can be configured to use Artifactory) support username and password as basic auth over HTTPS, if it was a glaring security problem I doubt support would be as widespread.

There's a HTTPS check to make sure credentials are not submitted over plaintext HTTP. I'm not sure how it is a "security footgun" compared to an API key, which is just as much of a password, and all the while under the covers the API key is sent as a HTTP header -- exactly as BasicAuth is.

[coderanger]

It's not the login itself that's the problem, it's working out how to pass credentials in to Stove (and all other Chef ecosystem tools, if we do this here we'll need to duplicate it in berks and the policyfile downloader). There is a much higher shoulder-surf risk for a plaintext password than a token.

[maxvt]

These passwords are encrypted by Artifactory already, it's not a short human readable string - they're almost a full line long. I understand your concern, yet I have to wonder how common is the scenario of someone using a manual process (having to specify the password in a way visible on the terminal) and working somewhere where shoulder-surfing is a real problem.

Thanks for clarifying your position, I'll use a fork for now to unblock my progress, and see if there's a way to get Artifactory API keys to work under our security policies.

[coderanger]

Not sure what you mean by "encrypted by artifactory". Passwords are passwords. They are hashed at rest inside AF, but that isn't relevant on the login side :)

[maxvt]

I was following the "higher shoulder-surf risk" line of thought, where a simple plaintext password like "hunter2" is much easier to observe and remember than a long, random API token -- which is not the case since AF encrypted passwords are also long and random.

Unless we're dealing with restricted-capability tokens (not the case for API keys at AF), there is in my opinion no difference between user/password pairs and API keys. Keys can be revoked, passwords can be changed. Artifactory says so themselves:

Artifactory allows authentication for REST API calls using your API key as an alternative to your username and password in two ways: you may either using the X-JFrog-Art-API header with which you can specify an API key, or you may use basic authentication using your username and API key (instead of your password).

[coderanger]

I don't know you mean by "AF encrypted passwords".

[maxvt]

https://www.jfrog.com/confluence/display/RTF/Centrally+Secure+Passwords

[coderanger]

Got it, that is less bad to support. Let me touch base with JFrog about their current standards for API tools.

[coderanger]

Had a quick chat with JFrog's dev rel team and their vote is: "if the only use case is REST API, access tokens are the best way to go". So I'm happy to say that's all we'll support on our side.

[maxvt]

@coderanger, thank you for researching this in depth and reaching out to JFrog. Looking at the current code, I'm not convinced that access tokens are supported by stove, because access tokens are not API keys.

The following is based on my reading of JFrog docs. API keys can be used with basic auth and the dedicated header X-JFrog-Art-Api. Access tokens can be used with basic auth and the standard Authorization: Bearer header. Passwords, either plaintext or "artifactory encrypted", can be used with basic auth only.

Basic auth over HTTPS is the most flexible method as it supports all possible authentication credentials (passwords, API keys, access tokens). If you would like to make an opinionated choice and support access tokens only, it would appear the current code needs to be changed to use a different header (and I don't mind at all looking into how to generate and use tokens for our Chef Artifactory stuff). If you would like to support the widest range of customers, however, I would suggest having basic auth as an option as it covers all 3 types of secrets supported by AF.

[maxvt]

@coderanger @tas50 Any further follow-up on this?

[coderanger]

@maxvt No changes so far, I agree we need to work out the right way to support both the current API keys and access tokens. My hope is that we can use the length of the value to tell which it is, but I haven't gotten to check that yet.