Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -470,6 +470,12 @@

The OpenID Connect realm is designed to allow users to authenticate to {{kib}}. As a result, most sections of this guide assume {{kib}} is used. This section describes how a custom web application could use the relevant OpenID Connect REST APIs to authenticate the users to {{es}} with OpenID Connect.

::::{note}
The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted.

Check warning on line 474 in deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Latinisms: Latin terms and abbreviations are a common source of confusion. Use 'using' instead of 'via'.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted.
The OpenID Connect protocol enables authentication for interactive users through a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted.

{{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you wish to authenticate a service, the [JWT](jwt.md) realm may be a suitable alternative.

Check notice on line 475 in deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.WordChoice: Consider using 'can, might' instead of 'may', unless the term is in the UI.

Check notice on line 475 in deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Acronyms: 'JWT' has no definition.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: it might help to clarify that the JWT realm does (or at least, can) leverage the customer's existing OpenID Provider as the source of signed JWTs and provides the PKI for verifying said JWTs?

My sense from the SDHs we have had is that customers tend to think "JWT realm" is something alien that will take them away from the comfort and familiarity of their Entra, Okta, etc setups. They're not seeing their infra fitting into the picture.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably. I struggled to come up with the right words that were succinct enough but didn't over promise.

Whether JWT actually
a. works with their existing infrastructure
b. solves their problem
is hard to predict. It probably does, but that requires more words than we want to put here.

Do you have suggested words?
In the end all it really needs to prompt is "Really, please follow that link and go read that page and hopefully it will all make sense to you" but I don't think we want to write that.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"If you wish to authenticate a service, the JWT realm (which can integrate with tokens issued by an Open ID Provider) may be a suitable alternative. "

is what I can come up with. If we don't like parentheses, we can probably re-arrange it a bit!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you wish to authenticate a service, the [JWT](jwt.md) realm may be a suitable alternative.
{{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you want to authenticate a service, the [JWT](jwt.md) realm might be a suitable alternative.

The JWT realm is able to authenticate tokens that are produced by OpenID Connect providers.

Check notice on line 476 in deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Acronyms: 'JWT' has no definition.
::::

Single sign-on realms such as OpenID Connect and SAML make use of the Token Service in {{es}} and in principle exchange a SAML or OpenID Connect Authentication response for an {{es}} access token and a refresh token. The access token is used as credentials for subsequent calls to {{es}}. The refresh token enables the user to get new {{es}} access tokens after the current one expires.

::::{note}
Expand Down
Loading