I have a Spring Boot application and in that I have done Keycloak integration with my REST API.
Now I want to build a Docker image for my app to host in the cloud.
First I tried:
docker container run -d -p 8081:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
That was not working; I couldn't open the login screen for Keycloak.
So I tried this:
docker container run -p 8443:8443 -d -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
Using this now I can login to Keycloak.
Then I tried disabling SSL in Realm->Login tab.
I can do this as this is my development environment and I am not much worried about SSL.
Is there any option of disabling SSL while running Keycloak in Docker?
If not how I can disable it?
If it is not possible to disable SSL in Keycloak while running on Docker, how can I integrate the SSL connection of Keycloak with the Spring Boot REST API?
If you're going to run a reverse proxy in front of Keycloak anyway, PROXY_ADDRESS_FORWARDING=true is what you're looking for.
This will disable the TLS requirement if you also send X-Forwarded-Proto: https in the header.
Running without TLS at all is not supported.
Documented here:
https://github.com/keycloak/keycloak-containers/blob/master/server/README.md#enabling-proxy-address-forwarding
Update the REALM table to disable requiring SSL by :
UPDATE REALM SET SSL_REQUIRED='NONE' WHERE ID=<RECORD_ID>;
Related
I am looking for a simple solution to start a squid-like proxy server that supports username/password authentication.
It should be able to tunnel HTTPS requests using CONNECT.
A docker-based solution is
docker run --rm -it -p 3128:8080 mitmproxy/mitmproxy mitmdump --set proxyauth=user:pass
The --ignore-hosts option also enables TLS pass-through for stuff like mTLS and certificates not signed by a trusted root (i.e. via. mkcert or self-signed).
I'm having some issues with configuring keycloak to run on our server.
Locally it works great but on on our test environment, after login, on any call using the received access token, we get "Invalid token issuer. Expected "http://keycloak:8080/auth/realms/{realmnName}" but was "http://{our-test-server-IP}/auth/realms/{realmName}""
So basically, our backend connects to the internal keycloak docker image but when the request comes it expects that the issuer is the configured external IP so even though the issuers are basically the same service keycloak sees them as being different and responds with a 401.
docker-compose.yml:
keycloak:
image: jboss/keycloak:12.0.4
restart: on-failure
environment:
PROXY_ADDRESS_FORWARDING: "true"
KEYCLOAK_USER: admin
KEYCLOAK_PASSWORD: password
KEYCLOAK_LOGLEVEL: DEBUG
KEYCLOAK_IMPORT: /etc/settings/realm.json -Dkeycloak.profile.feature.upload_scripts=enabled
TZ: Europe/Bucharest
DB_VENDOR: POSTGRES
DB_ADDR: db
DB_DATABASE: user
DB_SCHEMA: keycloak
DB_USER: user
DB_PASSWORD: user
ports:
- 8090:8080
volumes:
- ./settings:/etc/settings
depends_on:
- db
Spring application.yml:
keycloak:
cors: true
realm: Realm-Name
resource: back-office
auth-server-url: http://keycloak:8080/auth/
public-client: false
credentials:
secret: 8401b642-0ae9-4dc8-87a6-2f494b388a49
keycloak-client:
id: bcc94ed5-0099-40e0-b460-572eba3f0214
If we change the backend properties auth-server-url to connect to the exposed endpoint and no to the internal docker container we get a timeout, seems like it doesn't want to connect to it. I understand that the main issue is that we are running both the keycloak instance and our backend application on the same server but I don't see why it shouldn't work and why they can not connect to each other.
We tried setting up the FRONTEND_URL in the environment when running the container and in Keycloak admin console but nothing has changed. We've also tried to set forceBackendUrlToFrontendUrl to true in standalone.xml/standalone-ha.xml(./jboss-cli.sh --connect "/subsystem=keycloak-server/spi=hostname/provider=default:write-attribute(name=properties.forceBackendUrlToFrontendUrl, value=true)") files and reset the keycloak instance inside the docker container using ./jboss-cli.sh --connect command=:reload but nothing has changed.
I understand that basically by setting up the FRONTEND_URL all tokens should be signed by the keycloak instance and we would not have this issue but I've tried everything I've found so far on this issue regarding the keycloak configuration and nothing seems to change things. How can I make sure that the issuer that signs the access token and the one that the backend service expects are the same(hopefully the frontend)? And how can I configure this, is there some property I'm missing or was there something I did wrong while configuring it?
Might be related to this answer on here: https://stackoverflow.com/a/64095482/13494285
You could set Host header value to be the expected url.
To override this behavior, you might try to set KEYCLOAK_HOSTNAME environment variable to be the expected url.
Seems like documentation might not be up-to-date (it suggests KEYCLOAK_FRONTEND_URL variable on here), but instead KEYCLOAK_HOSTNAME is used to set fixed provider, as seen on here.
On this context, also the KEYCLOAK_HTTP_PORT is required to set the port to be 8080
Setting the KEYCLOAK_HOSTNAME to the external hostname (as defined in the KEYCLOAK_FRONTEND_URL) definitly worked for my case (eclipse che installation on a vanilla kubernetes cluster)
I have recently started exploring the microservice architecture using jhipster and was trying to install and run the jhipster-registry from docker hub. Docker shows that the registry is running, but I am unable to access it on port 8761.
Pulled the image with docker pull jhipster/jhipster-registry
Started the container with docker run --name jhipster-registry -d jhipster/jhipster-registry
Here's a snapshot of what docker container ls returns:
Am I missing something over here?
You are starting the JHipster Registry container, but you aren't exposing the port.
You can expose a port by passing the port flag -p 8761:8761 which will enable you to connect to it via localhost:8761 or 127.0.0.1:8761 in a browser.
You may need to configure some environment variables for the JHipster Registry to start correctly. These may depend on your generated app's options, such as authentication type. For convenience JHipster apps come with a docker-compose.yml file. You can start it with docker-compose -f src/main/docker/jhipster-registry.yml up, as documented.
I'm running an example solace broker (using the command here) and trying to connect to it from a web browser. I've succeeded in connecting to it using the client libraries, but I understand it should be possible to connect to it using the paho-mqtt library. Unfortunately, all the examples are for the Java library, which uses a different connection API. Does anyone have an example that literally just called "mqtt.Connect" and gets a successful return code?
Solace totally supports the Eclipse Paho MQTT libs... the problem is that quick-and-dirty getting started on that page (new location: https://solace.com/software/getting-started/) doesn't expose all the ports you need. Unfortunately, Docker needs the exposed (published) ports defined at create time (unless you're on a Linux machine and you created your Docker container with "host" networking). So if you're on Docker for Windows or Docker for Mac, you'll have to recreate your container.
The default MQTT non-TLS WebSockets port is 8000. (There's a whole bunch more: https://docs.solace.com/Configuring-and-Managing/SW-Broker-Specific-Config/SW-Broker-Configuration-Defaults.htm). So your container create command will be something like:
docker run -d -p 8000:8000 -p 8080:8080 -p 55555:55555 -p:80:80 --shm-size=2g --env username_admin_globalaccesslevel=admin --env username_admin_password=admin --name=solacePSPlusStandard solace/solace-pubsub-standard
That should allow your Paho JS API to connect! Maybe add 1883 (MQTT over TCP) and 9000 (REST messaging) ports as well, just in case.
Spring Boot app is configured (default) to run Tomcat on port 8080. This application gets deployed on AWS via BoxFuse tool and exposed at port 8080 (as expected/configured).
I have tried setting server port to 80 in boot application properties but it causes permission denied issue and the solution seems to be modifying iptables or reverse proxy. ipTables modification is not possible due to boxFuse image/env not being editable.
Question: Is there a way in BoxFuse to setup the spring boot application on port 80 without actually setting up another instance for reverse proxy? It is an overhead to setup an instance just for port correction since can't change the iptables.
Also, Is it possible that this application is run with root privileges on the AWS instance so that I do not need to modify iptables or set up reverse proxy?
There is a -ports.Name option available when deploying the application with BoxFuse.
Docs: https://cloudcaptain.sh/docs/gradle/run
Example:
boxfuse -ports.http=80 -env=test run myapprepo/myapp:0.1
Verified on local dev environment. For Mac, it should be run as a privileged command via sudo
sudo boxfuse -ports.http=80 run myapprepo/myapp:0.1
To add, works for 443 too.