Add external Keycloak functionality

[alemsh]

Premise

Currently, clowder2 relies on an internal keycloak instance for handling authentication, but does not have functionality for using an existing keycloak instance. This should be pretty simple but requires a few changes to some of the requests made back to the keycloak server for oauth2 flow.

Changes

• Change the auth and token requests to use the python-keycloak packages KeycloakOpenID object to construct these URLs/requests.
• Add an auth_redirect_uri environment variable instead of constructing it in each request
• Update helm values.yaml to include an auth section to override the auth_server_url environment variable, as well as add environment variables for auth_realm, auth_client_id, auth_redirect_uri

Comments

Tested this with docker compose, and both local and external keycloak instances in kubernetes deployed with helm in kubernetes

[CLAassistant]

All committers have signed the CLA.

[lmarini]

Thanks for submitting this PR @alemsh ! Could you please sign the CLA? Also can you take a look at #862 and see how it compares to yours?

@tcnichol @longshuicy can you also please take a look at this and compare it to #862.

Thanks!

[alemsh]

Ah, I had signed it but was using my org email for the commit, had to verify it.

I think #862 looks good, but this commit should be for a separate issue, but would be necessary in case the keycloak realm uses something else other than email for a preferred_username (as is our case). I believe these two PRs should solve the issues we've ran into.

[lmarini]

Ah, I had signed it but was using my org email for the commit, had to verify it.

I think #862 looks good, but this commit should be for a separate issue, but would be necessary in case the keycloak realm uses something else other than email for a preferred_username (as is our case). I believe these two PRs should solve the issues we've ran into.

Thanks @alemsh , we will take a closer look. Would you be able to test #862 in your environment? Thank you.

[alemsh]

Thanks @alemsh , we will take a closer look. Would you be able to test #862 in your environment? Thank you.

Can confirm that is looks like it is working quite well in our environment

[longshuicy]

is it possible to make one minor change of the default config so our dev stack works seamlessly? Instead of the fixing the redirect url to port 80, can we allow the flexibility of using the HOST_API; and I realize host api have to be localhost instead of 127.0.0.1 to match our default keycloak setting.
Details see below:

Everything else looks good!

[alemsh]

is it possible to make one minor change of the default config so our dev stack works seamlessly? Instead of the fixing the redirect url to port 80, can we allow the flexibility of using the HOST_API; and I realize host api have to be localhost instead of 127.0.0.1 to match our default keycloak setting. Details see below:

Sure thing @longshuicy . Should we also add the API_V2_STR as well? like

auth_redirect_uri = f"{API_HOST}{API_V2_STR}/auth"

[longshuicy]

is it possible to make one minor change of the default config so our dev stack works seamlessly? Instead of the fixing the redirect url to port 80, can we allow the flexibility of using the HOST_API; and I realize host api have to be localhost instead of 127.0.0.1 to match our default keycloak setting. Details see below:

Sure thing @longshuicy . Should we also add the API_V2_STR as well? like

auth_redirect_uri = f"{API_HOST}{API_V2_STR}/auth"

Yes that will be awesome. Nice catch :D

[tcnichol]

marking approved ready to merge.