Look at Keycloak lightweight alternatives for local development

[l0rd]

Running Keycloak takes 500MB+ (in the documentation we ask users to allocate 1GB). That can be annoying when running multi user Che locally and can be a blocker to drop Che single user support #10996.

In this issue we want to discuss some alternatives for running Che locally (where Keycloak full feature set is useless). For example replacing Keycloak with other OIDC providers that use less resources.

cc @skabashnyuk @davidfestal

[skabashnyuk]

what about https://github.com/coreos/dex with etcd or SQL backend?

[davidfestal]

FYI I'm currently testing with https://github.com/panva/node-oidc-provider/ with upstream Che running inside Minishift

Was able to pass the authentication / token retrieval step, and I'm now coping with fixed redirect urls, which should be done quite soon.

I'll give more details about it when my tests are finished / fully successful.

[l0rd]

@skabashnyuk 👍 . @davidfestal has already started to look at node-oidc-provider, we can look at a couple of others alternatives and decide what is the best option.

[davidfestal]

Just one point about the node-oidc-provider: when running in a POD on a nodeJS 8 POD (based on the service catalog image), it only take 39 MB memory.

[l0rd]

In the decision we need to take into account:

• performances: RAM/CPU/Image Size/Time to start
• simplicity: the less we need to customize the better, ideally it should be just a matter of starting a docker image (not maintained by us) with some config provided as environment variables
• project activity/maturity
• licensing (that should not be an issue)

[skabashnyuk]

https://github.com/coreos/dex Apache2, 2471 stars, 511 likes

ps x -o rss,vsz,command | grep config-dev.yaml
 17448  4426988 ./bin/dex serve examples/config-dev.yaml

I asume it's about 4meg.

[davidfestal]

@skabashnyuk nice !

[davidfestal]

I can test dex as well very easily with the same setup I currently use to test node-oidc-provider

[skabashnyuk]

@davidfestal you right. My numbers worth nothing if dex can't be easily integrated with che.

[benoitf]

https://github.com/ory/hydra https://hub.docker.com/r/oryd/hydra/

[davidfestal]

@benoitf yes, I quickly looked into hydra a bit already, but was a bit stopped by this sentence:

Hydra is not an identity provider (user sign up, user log in, password reset flow), but connects to your existing identity provider through a consent app. Implementing the consent app in a different language is easy, and exemplary consent apps

[davidfestal]

However that's a solution we could explore as well

[davidfestal]

about the dex possibility, I just saw that dex doesn't support the userinfo endpoint, that is used by Che to retrieve the profile from Keycloak (of from the OIDC provider). That might be a blocker I assume.

[benoitf]

@davidfestal about Hydra there is another repo for the consent stuff https://github.com/ory/hydra-login-consent-node

[davidfestal]

interesting.

[davidfestal]

OTOH hydra doesn't seem to be in the list of certified providers: http://openid.net/developers/certified/

[benoitf]

I see Hydra there http://openid.net/certification/ ? (among a long list)

[davidfestal]

OK, strange that it is not in the other list.

[davidfestal]

Another point in the hydra FAQ (https://www.ory.sh/docs/guides/master/hydra/8-faq/#is-jwt-supported):

Is JWT supported?

Mufid @mufid 03:29 Could Hydra's Access Token be a JWT? So that my resource server does not need to call Introspection API for each request.

Mufid @mufid 03:39 Yes, the access token looks like JWT, but i am unable to decode it. Here is my example token form Hydra: LpxuGoqWy7lYp9N0Cea8mEGR6IHhyr37jxZXRHqSjRM.nU-jMnAJ7dUKQPjWF4QBEL9OQWVU8zj_ElhrT-FQrWw (JWT Tokens should have 2 dots (3 segments), so this is not a valid JWT)

Mufid @mufid 03:56 *form --> from, typo, sorry. Aeneas @arekkas 11:50 @mufid JWT is not supported at the moment, we might add it, but not as part of the hydra community edition

It seems that access token cannot be returned as JWT tokens, which is still a pre-requisite of Che milited support for alternate OIDC providers: (see the Using an alternate OIDC provider instead of Keycloak section in https://www.eclipse.org/che/docs/openshift-config.html#multi-user-using-own-keycloak-and-psql)

[davidfestal]

Finally I have a POC of upstream Che integrated with a node-oidc-provider.

Here is a video that explains how it was setup and shows a demo of it running: https://youtu.be/UQQNACvb52k

Let me summarize the content:

• For this to work, some small changes were required in upstream Che, which are described in detail in PR https://github.com/eclipse/che/pull/11090. These changes should be done anyway, since they are related to Upstream Che requirements that go beyond the OIDC specification and are not supported by a number of providers.

  • The provider itself is run in Openshift by simply using the service catalog NgInx template with this GitHub repository: https://github.com/davidfestal/node-oidc-provider-openshift Then the s2i build takes care of NPM build through the package.js, and the server.js file is started in a POD

• In the OIDC provider deployment, we setup 2 variables the define the authorized URLs for both the Dashboard and the IDE applications. We also define the external URL of the provider itself as well as the PORT it should listen on

• In the Che installed by default in Minishift (single-user Che), we do the following changes:

  • point to the Eclipse Che image that includes required compatibility changes (see PR https://github.com/eclipse/che/pull/11090)
  • Change MULTI_USER env variable to set it to true
  • deployed a Postgres instance in the same namespace as Che by following the multi-user instructions in theChe docs
  • Change the property CHE_KEYCLOAK_AUTH__SERVER__URL to NULL
  • Set the following env variables:
    • CHE_KEYCLOAK_OIDC__PROVIDER to the URL of the installed node-oidc-provider
    • CHE_KEYCLOAK_USE__NONCE to false to disable the use of the nonce optional feature
    • CHE_KEYCLOAK_USERNAME__CLAIM to sub since node-oidc-provider never includes the preferred_username claim into JWT access tokens

[sleshchenko]

@davidfestal I have an issue with opening demo by the following link https://youtu.be/UQQNACvb52k Does it work for you?

[skabashnyuk]

@sleshchenko I have the same issue

[davidfestal]

@skabashnyuk @sleshchenko sorry, it had kept it in private mode. Just shared it, so you should be able to see it now.

[garagatyi]

@davidfestal is this issue still actual?

[cccanderson]

Just offering a possibility- have you looked at using OpenLiberty https://openliberty.io as the OIDC provider? It has an extremely small footprint. It is listed on https://openid.net/certification/ (but there was an important fix that went into 19.0.0.1 for an OIDC issue, so please use 19.0.0.1 or later).

Disclaimer- I work for IBM, but I am not part of the OpenLiberty team.

[l0rd]

@davidfestal do you remember if you had investigated OpenLiberty at the time?

[davidfestal]

@l0rd No I had not. I assume that now we could also look into Java-based options, especially if they would support compilation to native through graalvm or quarkus.io.

[l0rd]

https://news.ycombinator.com/item?id=20326931

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.