OpenID Connect support

(Sampsa Tuokko) #1

:bulb: OpenID Connect Support

Idea description

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.

:eyes: Example

  1. Authenticating against web-based IdP like Google, Facebook, Auth0, …
  2. Authenticating against a standard compliant on-premise IdP like Keycloak or Gluu Server

(Simone Scarduzio) #2

Hey @took! I agree this would be a very nice feature to have.
I assume you mean we support this in the Kibana plugin, right?

(Sampsa Tuokko) #3

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.

(Sampsa Tuokko) #4

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. 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 :slight_smile:

(Simone Scarduzio) #5

OK, so to summarise:

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

  1. We can use ready made library (TBD).
  2. We don’t want to force people to expose Elasticsearch HTTP API to the external network, they are already exposing Kibana.

(Sampsa Tuokko) #6

Looks good to me. I’d expect to see at least the following config parameters:

  • Client ID
  • Client secret
  • OIDC discovery URL

Rest of the OIDC related parameters could be fetched from the discovery URL.