Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for IdP AIuthentication [Do not merge yet - Feedback requested] #1465

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Stwissel
Copy link

Overview

** Preliminary pull request - not ready for merge yet. To collect feedback. **

This PR adds support for OIDC / JWT authentication by adding a button to the login screen and a screen to login using IdP parameters.

Screenshot 2024-10-23 at 21 39 56

The (WIP) IdP authentication screen looks like this:

Screenshot 2024-10-23 at 21 40 48

Ideally I would read the parameters from the server, so the experience would be similar to Cloudant, some advice needed.

Changes

  • Added a button: Login with IdP
  • Added a form to capture IdP info and store in session store
  • Added code to obtain authorization code, access token & refresh token
  • Added code to spin up CouchDB & Keycloak containers including documentation
  • Added IdP.md to document
  • modified ajax.js to add authorization header if token is still valid
  • added code to use refresh token to obtain new access token

Testing recommendations

  • Follow the steps in idp.md.
  • There's a shell script (macOS/Linux only) that configures containers to so CouchDB recognizes the Keycloak public key.

Open questions / feedback

  • How to optimize user flow? (e.g. let the IdP URL point to .well-known?)
  • What should be tested
  • should the config dialog be hidden once set?
  • should the code changes be less sprinkled over?
  • currently the IdP login is its own page, should it be merged and show/hide with login page
  • more impressions/suggestions

GitHub issue number

Fixes #1457

Checklist

  • Code is written and works correctly;
  • Changes are covered by tests;
  • Documentation reflects the changes;
  • Update rebar.config.script with the correct tag once a new Fauxton release is made

@janl
Copy link
Member

janl commented Oct 31, 2024

Heya, thanks for this contributions, there are a lot of moving parts here, so a review will be a bit slow, but overall this looks pretty cool. I hope we can give this a spin soon. In the meantime, I have approved the PR tests to run on this.

@Stwissel
Copy link
Author

Awesome thx. The big question is user experience. Ideally (?) it would be a server side configuration, if there is a way without altering CouchDB.

Or maybe it is ok like that?

@janl
Copy link
Member

janl commented Oct 31, 2024

I might be missing something, but what changes in CouchDB would be needed?

@Stwissel
Copy link
Author

Stwissel commented Nov 2, 2024

What would be nice is the ability to store the IdP information sever side.

For this some URL where an unauthenticated http fetch request could read a json file with the IdP information.
There might already be such an option (?) to retrieve a configuration value.

It would need to work even when you prevent unauthenticated access otherwise (require_valid_user=1)

@janl
Copy link
Member

janl commented Nov 3, 2024

Does the file have to have any particular format or is this just to hardcode the URL, so we don’t have to have that field in Fauxton?

@Stwissel
Copy link
Author

Stwissel commented Nov 4, 2024

any format will do

my thought was a fixed URL (e.g. /_idp) that delivers some content.

We need:

  • the IdP URL
  • the application Id (we could hardcode it to "fauxton", so we only need one valuea0

So 1-2 lines of plain text would do. Whatever is available.

In case there is no option in current config, I can modify the code to first check an URL (in a future version of CouchDB) e.g. /_idp and if that's not available fall back to a local config.

Another thought: as a stopgap measure: use http(s)://couchdburl/idp/fauxton. It wouldn't work with require_valid_user=1, but prove the approach.

What options do you see?

@Stwissel
Copy link
Author

Stwissel commented Nov 5, 2024

I'm warming up to the idea of using http[s]//couchDBserver[:port]/[_idp|idp/fauxton]

This would work (with the limitation of require_valid_user=0) on any existing server and with a future _idp URL once it is becoming available.

However it would require _idp to send JSON.

Does that make sense / would that be a way forward?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow Fauxton to obtain and use an JWT access token for authentication
2 participants