Keycloak behind a Load Balancer with SSL gives a "Mixed Content" error - keycloak

I have set up Keycloak (docker container) on the GCP Compute Engine (VM). After setting the sslRequired=none, I'm able to access Keycloak over a public IP (e.g. http://33.44.55.66:8080) and manage the realm.
I have configured the GCP CLassic (HTTPS) Load Balancer and added two front-ends as described below. The Load Balancer forwards the request to the Keycloak instance on the VM.
HTTP: http://55.44.33.22/keycloak
HTTPS: https://my-domain.com/keycloak
In the browser, the HTTP URL works fine and I'm able to login to Keycloak and manage the realm. However, for the HTTPS URL, I get the below error
Mixed Content: The page at 'https://my-domain.com/auth/admin/master/console/' was loaded over HTTPS, but requested an insecure script 'http://my-domain.com/auth/js/keycloak.js?version=gyc8p'. This request has been blocked; the content must be served over HTTPS.
Note: I tried this suggestion, but it didn't work
Can anyone help with this, please?

I would never expose Keycloak on plain http protocol. Keyclok admin console itself is secured via OIDC protocol and OIDC requires to use https protocol. So default sslRequired=EXTERNAL is safe and smart configuration option from the vendor.
SSL offloading must be configured properly:
Keycloak container with PROXY_ADDRESS_FORWARDING=true
loadbalancer/reverse proxy (nginx, GCP Classic Load Balancer, AWS ALB, ...) with proper request header X-Forwarded-* configuration, so Keycloak container will know correct protocol, domain which is used for the users

Related

Keycloak-nodejs-connect grantManager can't validateToken when configured with internal kubernetes keycloak service address

I have an issue when validating tokens using the keycloak-nodejs-connect library deployed to a kubernetes cluster - specifically when using the internal kubernete's service address for keycloak as the auth-server-url. I am using keycloak version 10.0.1.
Our workflow is as follows - our web app authenticates with a public keycloak client to obtain an access token. This token is attached to requests to the db for data. The db (hasura) uses an auth hook to validate the token before allowing access to its data. This auth hook implements the keycloak-nodejs-connect lib and through the provided middleware calls the grantManager's validateToken. However when the connect lib is configured with kubernete's service address (http://keycloak:8080/auth/) it is guaranteed to error on the issuer match because the issuer property in the JWT token (iss) will be the frontend url configured in the keycloak server (https://keycloak.public.address.uk/auth/).
Is there a way to provide a frontend and backend url to the keycloak-nodejs-connect library so that the issuer validation can occur whilst using the backend url to speak to keycloak via a kubernete's service - or should I be configuring keycloak a certain way so that the issuer is different? I am specifically needing to use a kubernete's service address here rather than a public address for keycloak communications in my cluster.
The following source location hyperlinks try to highlight the issue in code:
nodejs connect server url config (note only one url available used
for both keycloak server communication and issuer validation)
Where the config is applied
Where the token issuer is validated against the configured keycloak auth server
Keycloak server's front end url
One example of how the issuer is set to the frontend url when the token
is being generated
Many thanks for any help,
Andy.

AWS API Gateway HTTP Proxy for HTTPS connections

I cannot for the life of me get the AWS API Gateway HTTP Proxy to work, i.e. redirect http://<my-domain>.com to https://<my-domain>.com. Here is how I set it up:
Using the Test functionality on the ANY method inside the resource works. But if I simply do curl http://<my-domain>.com or run http://<my-domain>.com in Chrome, it fails to connect; https://<my-website>.com works just fine. I'm driving myself crazy trying to figure out what I'm missing here; it seems like it should just redirect http://<my-domain>.com to https://<my-domain>.com, but it doesn't (even on different devices).
So, it turns out that API Gateway's HTTP Proxy allows HTTPS traffic to go to an HTTP endpoint, but not the reverse. In fact, API Gateway won't even establish a connection on port 80; from the FAQ:
Q: Can I create HTTPS endpoints?
Yes, all of the APIs created with Amazon API Gateway expose HTTPS
endpoints only. Amazon API Gateway does not support unencrypted (HTTP)
endpoints.
API Gateway doesn't support unencrypted HTTP traffic. Here are the possible options you can do to secure your website:
If you have access to the server that hosts the website, install an SSL certificate to the webserver.
If the website is hosted on EC2, you can set up a load balancer and let it do the SSL termination.

Tell Wildfly to redirect to HTTPS after login instead of HTTP when behind HTTPS wildfly undertow-balancer

We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https (http requests are redirected to https requests), the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.
When a user hits a protected page the wildfly presents them with a login page. User enters credentials and submits the login form. The wildfly logs user in and then sends a redirect to the user to send them to the desired page. The redirect sent by the wildfly is an HTTP redirect. This gets grabbed by the load-balancer and redirected to HTTPS but I really want to avoid that second redirect. How can I tell the wildfly to return HTTPS redirect after login instead of HTTP?
I followed link but not sure how to deal same between wildlfy undertow load-balancer and wildfly server.
I followed this link also but didn't get any luck.
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https , the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
Client browser to load balancer via https
Load balancer to wildlfy nodes via http protocol .
It worked after adding proxy-address-forwarding="true" in wildlfy server node's http
listener .

How to disable HTTPS on Keycloak

Like in the title: How to disable the requirement of https on Keycloak? Using only the terminal, as I can't log in to the administrator panel, because... there's no https.
You could change "Require SSL" in Realm settings, Login tab.
The options are
external requests
Keycloak can run out of the box without SSL so long as you stick to
private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x,
and 172..16.x.x. If you don’t have SSL/HTTPS configured on the server
or you try to access Keycloak over HTTP from a non-private IP adress
you will get an error.
none
Keycloak does not require SSL. This should really only be used in
development when you are playing around with things.
all requests
Keycloak requires SSL for all IP addresses.
The SSL mode for each realm can be configured in the Keycloak admin console.

Try to make authenticated HTTPS call via Secure Gateway

I am trying to access a secured WAS URL via the Secure Gateway. I can access an unsecured page via HTTP. When I set the Secure Gateway Destination to HTTPS and try to access the secured page (requires a userid/password), the connection fails.
Last year I was told that HTTPS was not supported. However, I think that I just don't know how to configure the Secure Gateway to do it now.
In order for HTTPS to be in use on both sides of the connection (app to Secure Gateway Server, and Secure Gateway Client to on-premises resource), the protocol should be HTTPS (which it sounds like you have) and you should also enable Destination-side TLS under the Advanced options panel of the destination. This will cause the connection being made from the Secure Gateway Client to the on-premises resource to be HTTPS rather than HTTP.