After changing the domain name, Keycloak is still trying to authenticate using the old domain name. I'm using the Keycloak version 16.1 with KeycloakJS on the frontend using PKCE, on a server that runs everything in docker containers behind an Nginx reverse proxy.
I have changed all the references of the old domain to the new one, but it still redirects to the old domain:
https://auth.old-domain.com/auth/realms/dev-realm/protocol/openid-connect/3p-cookies/step1.html
All the other resources are requested from the new domain, except the step1.html, which is calling the above link.
Any idea of what may be the culprit?
Found the problem. It's not related to Keycloak.
Even though I have changed the auth URL in the frontend application to the new domain, the CI/CD pipeline wasn't updating the docker image for the frontend application, so it used the old image that had the reference to the old domain.
Related
I am trying to have users access Keycloak from a different hostname through a proxy. Instead of the actual AWS hostname aws.exampleurl.com:8080 I have a proxy which routes all traffic from example.hostname.com/auth to the AWS url. I am able to access the Keycloak welcome screen and kick off the administrator login (with failed CSS loads which I assume is due to the same issue but I'm not sure), but when I input a set of credentials I am told that there was no cookie found. I have the cookies set to allow all in my browser (Brave).
I have set the HOSTNAME_URL env var to example.hostname.com/auth, tried using a mixture of the HOSTNAME and HOSTNAME_PATH env vars. I have tried setting HOSTNAME_STRICT to false, but to no luck. I've tried restarting the service and restarting the database I have running with Keycloak but these changes have also not worked.
Any ideas on how to get this running correctly would be amazing. Let me know if more info is needed to reproduce.
Hi StackOverflow users,
I'm struggling with KeyCloak configuration because we want to change our current Identity provider to KeyCloak.
Our current solution exposes url with /openid prefix which causes i.e. issuer to be HOSTNAME/openid or event service discovery under HOSTNAME/openid/.well-known/openid-configuration.
When I'm trying to use KeyCloak everything what I have achieved is /auth/realms/openid/.well-known/openid-configuration.
Does anyone know how to remove /auth/realms prefix for KeyCloak?
Instead of changing keycloak urls (of course that is bit difficult). What if you can put a proxy in front of your keycloak to resolve '/openid/.well-known/openid-configuration' to '/auth/realms/openid/.well-known/openid-configuration'.
Or else by changing keycloak web.xml file's
<web-context>auth</web-context>
to
<web-context></web-context>
you can get rid of "auth" part.
I have setup a local (debian) installation of spinnaker and everything looks fine. I had also setup the authentication as ldap and able to sign in as well.
For authorization, I am using the FILE and have already enabled.
However, When I am trying to select an account in the application which I have created, it does not list any of the accounts.
I checked the logs and I am getting the following error in the logs:
Request GET:http://localhost:7002/applications/samit-app/serverGroups?expand=false is missing [X-SPINNAKER-ACCOUNTS] authentication headers and will be treated as anonymous.
Also, the deck and gate URLs are overridden and are behind a nginx proxy.
Can someone help me here and let me know what part I am missing in this setup?
You must choose an Account provider to deploy to and set it as a new Account in Halyard.
Set up an Account provider
I have created keycloak docker image and deployed in kubernates in my on premise server and setup localhost: as redirect URLs and when I am accessing it from other systems, it should be the IP address of that system, instead of localhost. Could you please help me to get dynamic IP setup in my keycloak from Kubernetes script?
I think you can just set the redirectUris in your realm config to *. Otherwise each system to be accessible needs to be added to the realm, which you can do from the admin console or through the API.
In Activiti we distribute a keycloak helm chart with a custom realm for activiti installations. In that we set redirectUris to * and allow that to be overridden at install time. We're doing that in a helm chart but if you weren't using a helm template then you could do a sed to replace a string. But that is for a shareable distribution. If you've just got a single installation then I'd expect you to be adding applications/clients to the realm through the console or API.
After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.