Replace MyUSA auth with hmac proxy

[gemfarmer]

Mike Bland has created a gem that will allow us to authenticate by proxying incoming traffic. Because we have auth in place, this isn't essential.

• add hmac authentication gem
• when hmac authentication is added, consolidate live site on to a single host, dolores.18f.gov

[mbland]

Well, there's two ideas here. :-)

First, and my preference in this case, I'd like to get 18F/hmac_authentication_gem#1 reviewed and merged so that I can release a new hmac_authentication gem that can be integrated into the app.

The second option is to run an instance of 18F/hmacproxy on the same host (maybe launched by the app process itself), configured for Accepted/Unauthorized mode, and forward requests to it to provide an authorization verdict.

In both cases, there would need to be a seam where the app could get the raw HTTP request object from the standard library, i.e. from Net::HTTP, to authenticate.

[gemfarmer]

Moving task from #42 here. When hmac authentication is added, consolidate live site on to a single host, dolores.18f.gov

[mbland]

Happy to help if needed, and to share the secret key when ready. The hmac_authentication gem is good to go, and bitly/oauth2_proxy support is live.

[jessieay]

This sounds fine to me. Can someone explain the benefit of hmac proxy over what we have now?

[mbland]

It wouldn't be an HMAC proxy (in the sense of running an instance of 18F/hmacproxy), but it would involve integrating the hmac_authentication gem to receive authenticated requests from our bitly/oauth2_proxy instance.

It isn't urgent by any means at this point if MyUSA OAuth2 support is already integrated. But it would allow SSO across participating *.18f.gov properties, if that's desirable in this case. The oauth2_proxy would do the authentication, and then pass a HMAC-signed request to the app. You can configure middleware with the hmac_authentication gem that validates these requests by trying to compute the same hash signature, and accepting the request only if they match. This means we can use oauth2_proxy-based SSO across the public internet.

For example, under the current oauth2_proxy configuration, anyone at @gsa.gov can access https://hub.18f.gov/, https://team-api.18f.gov/api/, and https://pages-staging.18f.gov (and pages-internal, pages-releases). If we wanted to broadly change access to these apps, or give specific outside users access to a range of apps, we can do it at the proxy rather than within each app. Within an individual app, you could still do some easy matching against an email address pattern or a whitelist if you wanted to restrict access further.

It may not be of benefit if you don't feel the need, but it's an option if you do.

[jessieay]

This is no longer relevant, we moved to GitHub auth. Closing