-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add OpenID Connect auth provider #36201
Conversation
Contrary to what happens in the SAML realm, we do not support consuming unsolicited Responses from OpenID Connect Providers. This means that the only way that a behavior such as the one described in elastic#33644 can be observed is when - a user initiates a login in a tab but stalls in the OP authentication form - user opens a new tab in the same browser and completes authentication - user returns to original tab, submits the OP form and lands in Kibana's oidc endpoint while actually already having a session. Not sure if this is a corner case we need to cater for, so removing this for now.
- Add a fake plugin, used to mock the token endpoint and userinfo endpoint of an OpenID Connect Provider - Add various integration tests for the OIDC auth provider
Pinging @elastic/kibana-security |
💔 Build Failed |
💔 Build Failed |
Looks like you need to run |
💔 Build Failed |
Relative paths from x-pack to OSS aren't yet supported in the prod build, so you'd need to use |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
ACK: will take a look tomorrow, I'll skip integration tests for now, but will review them as soon as we solve this nasty CI & |
This fails because
if I make the realm parameter optional in the authProvider , i.e.
then calling something like
also fails as Any suggestions on what is the proper way to handle this @azasypkin ? |
Hey @jkakavas! I'll be off next week and won't be able to do the second review pass till May 27th. If it can't wait till then, please, feel free to forward review request to someone else on @elastic/kibana-security team. |
Understood @azasypkin , I hope Brandon or Larry can lend a pair of eyes over the next few days ! |
@jkakavas I'll take a look a bit later today. |
Based on #25431 (comment), this is something that you recommended initially but we held off on doing so because we wanted to see if this was a commonality between all SSO providers. |
Use provider specific settings
💚 Build Succeeded |
The OpenID Connect authProvider is the accompanying authProvider for the OpenID Connect authentication realm in Elasticsearch. This is very similar to the saml authProvider in most ways with three noticeable differences: - We require explicit configuration regarding the Elasticsearch realm name instead of trying to build an environment aware string (like ACS URL in saml) and pass that to Elasticsearch for it to resolve the realm. - We do not support multiple values for the realm specific nonces (state and nonce) as we do with requestId in the SAML realm. Instead if an existing value ( for state and nonce) is present in the user's session, we pass that to Elasticsearch to be reused. The end goal is the same, allow a better UX for users attempting many requests over different tabs in the same browser context. - IDP initiated SSO ( Third Party initiated authentication in OIDC-speak ) is implemented but starts as an unsolicited request to initiate the handshake, instead of an unsolicited request with an authentication response (which is not supported here) This change also adds a fake plugin named oidc_provider to be used in integration tests for mocking calls to the token and userinfo endpoint of an OpenID Connect Provider This does not support the OpenID Connect Implicit flow as that depends on fragment handling/processing as described for instance in the spec Co-Authored-By: Brandon Kobel <[email protected]>
💚 Build Succeeded |
The OpenID Connect authProvider is the accompanying authProvider for the OpenID Connect authentication realm in Elasticsearch. This is very similar to the saml authProvider in most ways with three noticeable differences: - We require explicit configuration regarding the Elasticsearch realm name instead of trying to build an environment aware string (like ACS URL in saml) and pass that to Elasticsearch for it to resolve the realm. - We do not support multiple values for the realm specific nonces (state and nonce) as we do with requestId in the SAML realm. Instead if an existing value ( for state and nonce) is present in the user's session, we pass that to Elasticsearch to be reused. The end goal is the same, allow a better UX for users attempting many requests over different tabs in the same browser context. - IDP initiated SSO ( Third Party initiated authentication in OIDC-speak ) is implemented but starts as an unsolicited request to initiate the handshake, instead of an unsolicited request with an authentication response (which is not supported here) This change also adds a fake plugin named oidc_provider to be used in integration tests for mocking calls to the token and userinfo endpoint of an OpenID Connect Provider This does not support the OpenID Connect Implicit flow as that depends on fragment handling/processing as described for instance in the spec Co-Authored-By: Brandon Kobel <[email protected]>
The OpenID Connect authProvider is the accompanying authProvider for the OpenID Connect authentication realm in Elasticsearch. This is very similar to the saml authProvider in most ways with three noticeable differences: - We require explicit configuration regarding the Elasticsearch realm name instead of trying to build an environment aware string (like ACS URL in saml) and pass that to Elasticsearch for it to resolve the realm. - We do not support multiple values for the realm specific nonces (state and nonce) as we do with requestId in the SAML realm. Instead if an existing value ( for state and nonce) is present in the user's session, we pass that to Elasticsearch to be reused. The end goal is the same, allow a better UX for users attempting many requests over different tabs in the same browser context. - IDP initiated SSO ( Third Party initiated authentication in OIDC-speak ) is implemented but starts as an unsolicited request to initiate the handshake, instead of an unsolicited request with an authentication response (which is not supported here) This change also adds a fake plugin named oidc_provider to be used in integration tests for mocking calls to the token and userinfo endpoint of an OpenID Connect Provider This does not support the OpenID Connect Implicit flow as that depends on fragment handling/processing as described for instance in the spec Co-Authored-By: Brandon Kobel <[email protected]>
Summary
The OpenID Connect authProvider is the accompanying authProvider for the OpenID Connect authentication realm in Elasticsearch. This is very similar to the saml authProvider in most ways with three noticeable differences:
state
andnonce
) as we do withrequestId
in the SAML realm. Instead if an existing value ( forstate
andnonce
) is present in the user's session, we pass that to Elasticsearch to be reused. The end goal is the same, allow a better UX for users attempting many requests over different tabs in the same browser context.Third Party initiated authentication
inOIDC-speak
) is implemented but starts as an unsolicited request to initiate the handshake, instead of an unsolicited request with an authentication response (which is not supported here)This change also adds a fake plugin named
oidc_provider
to be used in integration tests for mocking calls to the token and userinfo endpoint of an OpenID Connect ProviderMissing:
Limitations
This does not support the OpenID Connect Implicit flow as that depends on fragment handling/processing as described for instance in the spec
Co-Authored-By: Brandon Kobel [email protected]
"Release Note: Added support for authenticating using OpenID Connect"