Single Sign-On Auth

[sungo]

We have a new requirement: add support for LDAP. Alternate systems like Google Auth would be nice as well. We still must support "local" accounts, ones located inside a conch database. This will support folks who don't want the other auth or who don't want to add integrators and what not to their LDAP and Google Auth setup.

In conversation, we discussed a microservice that would handle auth and generate a JWT that could be verified by the API et al using public/private keys.

I also fully expect us to remove all non-JWT auth as part of this change.

[karenetheridge]

One potential problem here... what do we do if there is no user_account entry for the user? Many endpoints rely on this e.g. to determine admin permissions or workspace access permissions. We might need to add an extra column to user_account to map to the LDAP username to allow existing users to log in using their LDAP credentials -- otherwise if we can't figure out who the user is, we'll have to presume "you have no permissions to access this workspace".

[sungo]

I figure we'll have to rework the API authorization system entirely to handle SSO. Sensible defaults, all that sort of thing. Don't assume LDAP. As I noted in the original description, we might support Google Auth or eris knows what. We'll have to figure out how to map users in the SSO system to authorizations in the Conch API. If we do some sort of JWT thing where only the servers can read the claims, we can pass information about who a user is via that data channel. But there are probably quite a few ways to handle that problem.

[sungo]

After some internal discussion, it looks like our primary target should be SAML. Particularly, being a SAML service provider. My proposal at this point is that we produce an SSO shim service with a plugin architecture. Initially, it would support just the current conch auth tables and structures. Then we would implement a SAML plugin, with perhaps an option to use the first plugin as a fall back. That'd let us support remote auth and continue to support local accounts.

[karenetheridge]

closed in favour of #929.