OpenID Connect has become the de facto authentication protocol in the web, and is being quickly adopted by the enterprise as well. It may be possible to create something via a smart reverse proxy and JWTs, but it would be great if ReadonlyREST had native support for OIDC.
Example
Authenticating against web-based IdP like Google, Facebook, Auth0, …
Authenticating against a standard compliant on-premise IdP like Keycloak or Gluu Server
I think authentication is applicable both to GUI based usage & API based usage.
For Kibana GUI, the canonical way would be to trigger authorization code flow to authenticate the user, and pass the acquired access token to ElasticSearch API as a bearer token. Token refresh for longer sessions would need to be managed as well.
For ElasticSearch API, the access token should be verified. Usually this is passed as a bearer token. The token could come from Kibana, or from API user who acquired it using one of the standard flows.
Standard defines the access token opaque, in practice the token may be a JWT in which case there’s no need to contact the IdP for introspection as it can be verified cryptographically. If token is not JWT, it needs to be passed to IdP introspection API. The token type depends on the issuing IdP.
In OIDC, access token can be used to get a JWT known as ID token, which contains then the actual user information, and quite often additional claims like groups.
In principle using existing JWT support I think one could put an external reverse proxy like nginx in front of both Kibana & ElasticSearch and manage the OIDC flows & token refresh there, passing the ID token as a JWT to Kibana or ElasticSearch, respectively. It’s doable with e.g. GitHub - zmartzone/lua-resty-openidc: OpenID Connect Relying Party and OAuth 2.0 Resource Server implementation in Lua for NGINX / OpenResty but requires securing the transport to only allow access through nginx to the endpoints, and takes some understanding of how the protocol works to configure correctly
ES side: we need a rule that reads tokens from Authorization header, and exchanges it with a ID token (JWT format) from a configured identity provider.
Kibana side: the full authentication to be resolved within Kibana and the identity shall be forwarded to ES using the JWT bridge we have in place for SAML.
I think it’s important that Kibana handles the whole flow on its own for two reasons:
We can use ready made library (TBD).
We don’t want to force people to expose Elasticsearch HTTP API to the external network, they are already exposing Kibana.
Would be a much appreciated feature.
Especially on the ElasticSearch plugin.
Our university provides several data sets via ElasticSearch,
Some of them open but most of the indices are closed/protected.
At the moment a server web application which is secured via SAML
or OpenID Connect accesses the ElasticSearch cluster with a service account.
If web apps (no intermediate server) could access certain ElasticSearch indices
with the OpenID connect flows, this would be perfect.
We are in the process of refactoring our Enterprise plugin so adding multiple SAML identity providers or new auth protocols like OpenID connect will be possible.
OpenID Connect Support
Example