Fake creds for dev/test/qa

[david-crespo]

Until recently we have not had auth in Nexus, so nothing relies yet on authn or authz context. Even with the addition of authn, no endpoints are currently gated, and if they were, we could set things up so that if there are no authn schemes configured, every request is allowed. This is convenient for running tests and for local development, though there are limits to how productive it can be to use an unrealistic configuration for those things. With the addition of authorization, even more of the call chain will depend on auth context because every database call will be wrapped in an authz check.

As discussed in chat, we will not be setting up a no-auth mode to make dev/test/qa easy. Instead, we will work with fake creds during development, in tests, and in QA envs. This will require:

• Add auth checks to existing endpoints so an authn context is present for use by authz checks
• Update tests to auth all requests that are supposed to be authed
• DB seeding script to set up:
  • Test users with particular roles and perms
  • Username/password creds for those users for console local dev and QA
  • Spoof header auth linked to those users

Because the set of auth schemes to try is configurable, we can set it up so only spoof is configured for tests and API-only local dev and then when we're testing the console we can configure session_cookie.

Note: I'm using QA as shorthand for a deployed Nexus instance, including both the simulated one on GCP for console QA and a future unsimulated one running on a lab system.

---

Key bits from chat:

@davepacheco

as we protect each endpoint, we update oxapi_demo and the automated tests. That probably means a very large number of tiny changes to the automated tests so that they use some wrapper that uses the creds.

I'm less sure about what the shape of those creds should be. I'm not sure it's a bad idea to use "spoof" or something like it in dev/test, assuming we're not going to make everybody use oauth all the time

My hope is that once we've converted everything we have today, we can remove datastore::pool(), which means you won't be able to write a new endpoint without having an OpContext, and you won't be able to get one of those without authenticating your request (or using the internal_unauthenticated() function, which hopefully it will be clear one should not use for an API)

[davepacheco]

I've taken a first stab at part of this in #346 (comment). To summarize: there are two hardcoded test users: one privileged, and one unprivileged. These don't live in the database yet. (There's not even a table for users yet.) The test suite uses these users with "spoof" authn to exercise authorized and unauthorized code paths. I've converted one code path ("POST /organizations") to do authz and updated its tests accordingly. oxapi_demo also uses the privileged user for the protected endpoint. I think we can incrementally apply this pattern to other endpoints.