simmel
commented
8 years ago Just supporting REMOTE_USER and have configure options to say which HTTP headers that provide group, displayname and email (and what other things you might need) would be an perfectly acceptable and generic solution.
I'm guessing that keywhiz-cli uses an HTTP API? If so, making it support:
- Basic Auth
- SPNEGO
- SSL client certs
- ECP for SAML?
would be possible. That would require that the user has logged into the web ui once and gotten "provisioned" before they use the CLI.
Keywhiz has support for local admin users, or pulling them from LDAP.
But we should support SSO schemes. Our abstraction for a user is not good enough to support this today: We abstract away the idea of something checking username & password, and then being "logged in". With an SSO system, we shouldn't handle the user's password.
I think the most flexible way is to support a proxy server that handles authentication, and passes the authenticated user in an HTTP Header. (And the server itself proves its identity via a client cert). There's a number of services that do this today, and it's easy enough to integrate other types of SSO this way. I wouldn't want to implement complicated schemes like SAML.
We could even pull the LDAP/bcrypt users stuff out of the keywhiz codebase into such a proxy, packaged with Keywhiz by default. That might make Keywhiz harder to set up if you're not using Docker or something. And more annoying in Dev, unless we add an "unauthenticated administration" configuration option which feels like a footgun, but would be "convenient" (no more a footgun than using the dev_and_test key material though).
There's another big question here, and that's how to handle logging into the SSO provider with keywhiz-cli, too. We could assume the proxy just needs cookies, and that some seperate tool will handle login and putting the cookies in the jar.