Add OpenID Connect auth provider

[jkakavas]

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:

• 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)

Missing:

• Documentation

Limitations

This does not support the OpenID Connect Implicit flow as that depends on fragment handling/processing as described for instance in the spec

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-security

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[kobelb]

The code for this is looking great, almost all nits. I haven't had a chance to try it out with the OIDC realm in ES yet, and ideally we'd have some API integration tests for this. If you'd like for us to add these, I don't mind at all, but I'm starting to think that 6.7/7.0 is looking challenging.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[jkakavas]

Thanks for the review @kobelb. Sorry for the left over debug logging, my "search and replace"-fu failed me.

Regarding the API integration tests, you are right. The relevant branch in Elasticsearch will hopefully be merged today so we couldn't have run them even if we had some. The real problem here is that

• Kibana doesn't support the implicit flow in which the tokens are sent in the front channel via the browser and which would allow us to generate and consume synthetic ID tokens in a way similar to what we do for SAML responses for example.
• The authorization code grant flow requires backchannel comms so it needs either a working OP or a mocked one so that the Elasticsearch instance in the kibana integration tests would make HTTP requests to the Token Endpoint to exchange the code for an ID Token and possibly to the UserInfo endpoint to get additional claims for the user. I was not sure how to approach this.

I added tests for whatever I could think off can be tested without an OpenID Connect Provider.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[kobelb]

Kibana doesn't support the implicit flow in which the tokens are sent in the front channel via the browser and which would allow us to generate and consume synthetic ID tokens in a way similar to what we do for SAML responses for example.
The authorization code grant flow requires backchannel comms so it needs either a working OP or a mocked one so that the Elasticsearch instance in the kibana integration tests would make HTTP requests to the Token Endpoint to exchange the code for an ID Token and possibly to the UserInfo endpoint to get additional claims for the user. I was not sure how to approach this.

Gotcha, we're in a similar position with Kerberos and we're intending to borrow the Kerberos Vagrant test fixture from ES and run it along-side Kibana/ES for our api integration tests. Do you know if we have the same capability with this auth provider?

[jkakavas]

You mean as discussed in #18188 ? Yes, there are a few options for an on prem OP that we can run in there. I'll look into it

[kobelb]

You mean as discussed in #18188 ? Yes, there are a few options for an on prem OP that we can run in there. I'll look into it

Yup! I feel bad putting this burden on you, as you've already done so much to help us out, but merging a auth provider without integration tests puts a lot of burden on our QA people because it's such a laborious task to test this manually. If you'd at any point in time like to hand this off to us, we can definitely take it from here.

[jkakavas]

Yup! I feel bad putting this burden on you, as you've already done so much to help us out, but merging a auth provider without integration tests puts a lot of burden on our QA people

No worries, I'd be wary of merging without integration tests also. I'll take a look and we can reshuffle ownership as needed for the next minor release ;)

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[jkakavas]

Closed in favor of #36201