search

h2oai / wave

Realtime Web Apps and Dashboards for Python and R
https://wave.h2o.ai
Apache License 2.0
3.9k stars 326 forks source link

Enable multiple OpenID authentication providers #1758

Open padraic-shafer opened 1 year ago

padraic-shafer commented 1 year ago

Is your feature request related to a problem? Please describe

Background: OpenID Connect (OIDC) is a standard protocol for authenticating users, and many common apps (Google, Facebook, ORCID, etc.) provide this service for other registered third-party apps to use. Users can confidently log in with their existing credentials to use the third-party, and the third-party app can be confident that an authenticated user is accessing its services.

Current State: H2O Wave supports OIDC authentication with optional command line arguments passed to the waved server at startup. This enables Single Sign On functionality for the wave apps.

Feature Upgrade: Apps often need to offer multiple OIDC sign-on options to users, because this increases the likelihood that the user has an account with one of the sign-on services. Enabling the developer to configure multiple OIDC options on the Wave server would provide this benefit to Wave apps, which is generally expected by web app users.

Describe the solution you'd like

Wave should provide a mechanism for deploying the server with multiple OIDC configurations.

Because there are so many optional command line arguments needed, it might make sense to provide these in a configuration file rather than at the command line. In a config file, each OIDC configuration could be grouped and named. Then the app developer could inspect the available OIDC configurations, and offer some or all of those options to the user for authentication.

The wave server might need some way of knowing which service to connect to for authentication, so perhaps then name of the OIDC configuration could be passed in the HTTP header or URL query?

Ideally the OIDC service selected by the user gets stored at the User level, rather than at the App or Deployment (waved) level.

Describe alternatives you've considered

The alternatives currently available seem to be:

  1. Require all users to obtain an account with the single OIDC service selected by the Wave app developer. This limits the freedom of the user to use an existing account.
  2. Start a separate waved server instance for each OIDC option, then redirect user to that URL based on the OIDC option they select. This requires repetition of app services and the waved server, and logic complexity that extends outside the current app framework of Wave.
  3. Deploy an OIDC proxy that handles the logic of offering OIDC options and maintaining the state of authentication, thus providing only a single OIDC interface to Wave. This requires each developer to independently write an OIDC server and the logic for proxying to the underlying services.
mturoci commented 1 year ago

Because there are so many optional command line arguments needed

I guess our docs need a minor update for this section - all the above params are also available as env variables allowing for making your own config files - scripts.

Thanks for a great write-up @pshafer-als! cc @lo5