We want OpenID Connect (OIDC) because it is a widespread authentication mechanism.

1. Write the ADR and define the CRD API - OIDC AuthenticationClass ADR documentation#460
2. Implement

### Tasks - [ ] https://github.com/stackabletech/nifi-operator/issues/519 - [ ] https://github.com/stackabletech/airflow-operator/issues/337 - [ ] https://github.com/stackabletech/druid-operator/issues/473 - [ ] https://github.com/stackabletech/documentation/pull/460 - [ ] https://github.com/stackabletech/kafka-operator/issues/630 - [ ] https://github.com/stackabletech/superset-operator/issues/405 - [ ] https://github.com/stackabletech/trino-operator/issues/473 

OAuth2 instead?

Superset supports OAuth2 out of the box. Trino does as well. Keycloak supports it too. Maybe we can do that instead?

AuthenticationClass

ADR draft: stackabletech/documentation#460

We need to define an AuthenticationClass for OIDC. Which settings go into it?

• Druid has the following settings: cookiePassphrase, readTimeout, enableCustomSslContext, clientID, clientSecret, discoveryURI, oidcClaim, scope

For Superset, the settings are:

'client_id': 'KEYCLOAK_CLIENT_ID', 'client_secret': 'KEYCLOAK_CLIENT_SECRET', 'api_base_url': 'http://10.96.80.198:8080/realms/master/protocol/openid-connect', 'client_kwargs': { 'scope': 'email profile openid' }, 'access_token_url': 'http://10.96.80.198:8080/realms/master/protocol/openid-connect/token', 'authorize_url': 'http://localhost:8080/realms/master/protocol/openid-connect/auth', 'request_token_url': None, 

NiFi:

nifi.security.user.oidc.discovery.url=https://accounts.google.com/.well-known/openid-configuration nifi.security.user.oidc.connect.timeout=5 secs nifi.security.user.oidc.read.timeout=5 secs nifi.security.user.oidc.client.id=<YOUR-CLIENT-ID> nifi.security.user.oidc.client.secret=<YOUR-CLIENT-SECRET> nifi.security.user.oidc.preferred.jwsalgorithm= 

Common settings: Client ID, Client Secret, scope. But the i.e. Druid and Superset are different clients in this case, should the clientsecret be part of the AuthenticationClass?

Adjacent topic: Running Keycloak

Running a keycloak instance in k8s works. However it is important that all requests to it go to the same address. Since it needs to be accessible from the browser (outside the cluster), all traffic from inside the cluster needs to go to the same address, so it needs to be routed outside.

In the "real world" a client would most probably already have a keycloak running somewhere, with a dedicated address and TLS maybe already configured, so this is not an issue.

This is a bit of a novel situation, for LDAP nothing like this was necessary.

TLS

How can we run Keycloak with TLS? Currently our secret operator cannot issue certs for nodeport/Loadbalancer, so I don't think it's possible at the moment.