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.

Sign up for GitHub

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

Jump to bottom

OIDC discovery blocks other connectors #1723

Open
bajnokk opened this issue May 27, 2020 · 1 comment · May be fixed by #2789
Open

OIDC discovery blocks other connectors #1723

bajnokk opened this issue May 27, 2020 · 1 comment · May be fixed by #2789

Comments

@bajnokk
Copy link

bajnokk commented May 27, 2020

It seems like there is no way to disable OpenID Connect Discovery (see also #1228) in the OIDC connector. This breaks use cases when the remote providers may be unavailable during startup and in turn it also makes other connectors non-functional (because the server won't start).

Are there any plans to either make remote OIDC discovery optional or let the server start with broken/failed/not ready connectors? That would make it possible to use DEX in environments where the local login must be provided even if external connections fail.
@nabokihms nabokihms mentioned this issue Jan 13, 2023
Closed
2 tasks
@dlipovetsky
Copy link
Contributor

dlipovetsky commented Jan 13, 2023 •
edited
Loading

I missed this issue, so I opened #2787, which states the problem in a slightly more general way. To avoid duplication, it was closed, and I'm following up in this issue

Problem Description

Dex initializes every connector when its server starts. If one connector fails to initialize, dex exits.

Dex exits even if other connectors are available and successfully initialized. This provides a bad user experience. For example, if a user adds a new OIDC connector but misconfigures it, existing users connecting via a correctly configured LDAP connector will be unable to authenticate.

Initialization of these connectors requires a network call to an external service, which can fail: Google, OIDC, OpenShift. Add LDAP to this list if/when #2776 merges.

By comparison, once the server is running, dex may need to initialize a new connector. If that connector fails to initialize, dex does not exit, but only returns an error to the client.

It therefore appears safe for dex to start its server if one or more connectors fails to initialize.

Proposed Solution

Do not initialize connectors during server start.

The current behavior (exiting) remains the default; the new behavior is enabled with a flag.

Alternatives Considered

Continue to initialize connectors during server start, but ignore errors.

Some may prefer this approach, because the server can log a message when an error happens, and that can signal misconfiguration. My current thoughts are: if you want such a signal, then you probably prefer the current behavior (exiting). I'm happy to hear feedback.

@dlipovetsky dlipovetsky linked a pull request Jan 13, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: Initialize connectors lazily (not on server start) dlipovetsky/dex
2 participants
@dlipovetsky @bajnokk