Support simple shared secret unsigned backend authentication

[sporkmonger]

In the ideal case, we'd implement a firewall rule and asymmetric request signing between SSO proxy and the upstream service, but we are discovering that this is impractical in many cases. Request signing with both methods have spotty or virtually non-existent language support, proxies and load balancers may slightly alter requests just enough that signatures don't match, and some languages may not fully preserve order and casing of headers, and may even perform destructive normalization that prevents a signature from being successfully calculated. When signature verification fails, the failure is usually opaque.

We're also discovering that in AWS, for cross-region and cross-VPC services, tools like security groups that would otherwise allow you to narrowly lock down communication between instances will now only allow you to lock things down by IP address or IP range. That's not very granular and in practice we can't get much narrower than an entire subnet due to our preferences for short-lived, disposable infrastructure.

And unfortunately we've managed to run into a few situations that have the union of these two problems.

My suggestion for a simplest-thing-that-can-possibly-work solution is just shared secret API keys. Have a per-upstream optional shared secret and pass it through as e.g. Sso-Key header or something like that.

It would be less secure than request signing, but particularly for connections that are running TLS, there are real-world attack paths that it would mitigate and it's clearly better than being stuck with no security at all.

[jphines]

@sporkmonger would https://github.com/buzzfeed/sso/blob/master/docs/sso_config.md#request-signing cover this case?

The documentation is stale but the TLDR is simple per upstream shared secret request signing

[jphines]

Additionally, if you want to just inject headers, you can use

inject_request_headers adds headers to the request before the request is sent to the proxied service. Useful for adding basic auth headers if needed.

https://github.com/buzzfeed/sso/blob/master/docs/sso_config.md#proxy-config

[sporkmonger]

@jphines It doesn't. We've found that in practice this method of authentication is difficult for developers to adopt as it's not standardized, language support is mixed, and it's subject to breakage if the set of signed headers ever changes. Firewall rules / security groups can reduce the risk from using an unsophisticated authentication method, and TLS covers confidentiality and addresses some of the "who am I talking to" problem (client can verify server). Mutual TLS would cover the whole problem, but it's more difficult to deploy and not universally supported by all HTTP clients.

Request header injection would work if the value of the request header could be supplied via an environment variable. We'd like to avoid templating the entire config file.