Deploy Keycloak at auth.pdco

[jasonaowen]

Currently, Keycloak is living in a subdirectory on pilot.philanthropydatacommons.org, along with the back-end.

During today's team meeting, we decided to instead deploy Keycloak at auth.philanthropydatacommons.org.

This follows standard IdP patterns, and should avoid future turbulence if/when we sunset pilot.pdco: partners and other applications that are authenticating through Keycloak will not have to change. That will also let us avoid any cookie issues that come from two apps sharing the same domain name, and it also sets us up to disentangle the deployment of Keycloak from the deployment of the back-end (although we do not necessarily need to tackle that just yet).

[bickelj]

At the moment, the auth repository is agnostic with regard to target environment hostname or domain name. All the specifics are in the deploy repository (and even that is relatively agnostic). This is as good a place as any to track progress, though. The change to auth.[pdco] is pending the creation of the subdomain at the moment.

[bickelj]

I changed my mind about where this ticket should live because I went to the deploy project to find it and it wasn't there. If it is clearly better to track it over in auth, please move it back.

[bickelj]

Last night I discovered it was not as easy as expected to get the reverse proxy config and keycloak command line args to cooperate with the goal of keeping the development-friendly configuration of having keycloak run under /auth while the reverse proxy would use /. This morning I remembered that there are two issues, not one. Issue #65 is straightforward: change from pilot to api subdomain. That is now done. This one should also be straightforward but the trick is deciding how much configuration to keep development-friendly in the actual configuration vs documented differences.

[bickelj]

Currently, Keycloak is living in a subdirectory on pilot.philanthropydatacommons.org, along with the back-end.

That is a technically correct view (of a possible future) but it can also be stated another way. Keycloak lives in a bitnami image, our configuration of keycloak lives in a compose.yml file, and additional configuration or code can be added to the host where compose.yml is used. The pilot domain names pointed to machines where this configuration lives, along with configuration for a reverse proxy to terminate TLS and proxy to the container.

The change for a new domain name is to

• [X] Point the new domain names to the existing hosts.
• [x] Reconfigure the reverse proxy to account for the new domain names.
• [x] Reconfigure the reverse proxy to further separate the proxy settings for auth (versus piggy-backing off of web).
• [x] Generate new certificates for the new domain names.
• [x] Reconfigure keycloak within the compose.yml script to cooperate with the above changes.
• [x] Include a new page and/or redirect at the root of the auth service because by default we would not proxy to it.
• [x] Hopefully keep it development-friendly but if not, document the unfriendly parts.

[bickelj]

I have a working version of all but the last (documentation) point developed on the test host. The next step is to update the repo with the changes.

[bickelj]

Completed.