Since the acr_values are not picked up from the "Forwarded Query Parameters" of the External IDP configuration, I tried to attach the same to the "Authorization URL" by appending https://host:port/authorize?acr_values=....&
However, when I launch the external IDP page for credentials the redirection is happening with /oauth2/authorize?=acr_values=...& -- I had to remove the "=" character that's getting injected to get it properly redirected.
Is there anyway by which I can remove the same -- I tried escaping the same with
https://host:port/authorize/?acr_values
https://host:port/authorize?acr_values
https://host:port/authorize?\acr_values
https://host:port/authorize?\acr_values
Nothing seemed to work. Any clue?
Related
I am having trouble trying to figure out what the values should be for 'Valid Redirect URIs', 'Base URL', 'Backchannel Logout URL'.
I am using Keycloak 15.02 along with 10 Spring Boot applications, and 2 Realms. The suite of applications and Keycloak are deployed to our customer sites, and may have more than 2 realms in some cases.
In our dev environment we have two hosts (api.dev, and web.dev) that are running Keycloak, and client apps. Everything is running Docker containers.
The client config for `Valid Redirect URIs', and 'Backchannel Logout URL' currently include the host name web.dev. I'd like to be able to remove that host name to make the Realm configs portable between environments. Having to configure each client in each realm makes for a lot of repetitive and mistake-prone work.
But when I remove the hostname, I get the error: Invalid parameter: redirect_uri.
The redirect URL shown by Keyloak in the request parameters looks the same for both configurations so I dont really understand why its telling me that its invalid.
This works:
That configuration produces the redirect_uri value seen in the following request:
http://api.dev.etisoftware.local:8080
/auth/realms/OSS/protocol/openid-connect/auth
?response_type=code
&client_id=launchpad
&scope=openid%20profile%20email%20roles
&state=E-8VBZUc1CbsIUi5HdPG68pNK1IVNB8bzDT3Aengx9Q%3D
&redirect_uri=http://web.dev.etisoftware.local/launchpad/login/oauth2/code/OSS
&nonce=3OUMxVmrglSC0KK-WGWDjG4yB9TOuvqBO5TMnDk4R-A
But this does not:
That configuration produces the redirect_uri value seen in the following request:
http://api.dev.etisoftware.local:8080
/auth/realms/OSS/protocol/openid-connect/auth
?response_type=code
&client_id=launchpad
&scope=openid%20profile%20email%20roles
&state=cGh1zZ3et0ssogIsNclL2sHcrfDxNePaHf5UXxw0aR8%3D
&redirect_uri=http://web.dev.etisoftware.local/launchpad/login/oauth2/code/OSS
&nonce=Qm846RYZZnU3fG4Cj75e8lBejupf24VbV1WjDVW1NJA
As you can see the values for redirect_uri in the request parameters are same for both requests and client configurations so its unclear (to me) what Keycloak is trying to tell me.
I also happen to have Keycloak and the client apps running in a K3s cluster. For some reason on that environment I dont have to have the hostname in the Valid Redirect URIs and it works perfectly fine. Is it just a fluke?
Redirect URIs tooltip:
"Valid URI pattern a browser can redirect to after a successful login or logout. Simple wildcards are allowed such as 'http://example.com/’. Relative path can be specified too such as /my/relative/path/. Relative paths are relative to the client root URL, or if none is specified the auth server root URL is used. For SAML, you must set valid URI patterns if you are relying on the consumer service URL embedded with the login request"
So if you want to use relative paths in the redirect URIs, then configure properly Root URL, not Base URL.
I got this answered on Keycloak's site but Jangaraj.
https://keycloak.discourse.group/t/trouble-with-configuring-client-valid-redirect-uris/13251
I configured a SAML identity provider in keycloak by importing metadata provided by Microsoft ADFS.
I could see the option of IdP on my client login page for login.
After clicking on that on that button it redirects to external identity provider login page.
After login, I get success with a SAMLResponce. (Checked with SAML tracer).
The page is redirected to IDP redirect URL.
After redirecting page shows me "invalidFederatedIdentityActionMessage"
I saw the docker logs it gives me ---
23:58:09,035 WARN [org.keycloak.events] (default task-181) type=IDENTITY_PROVIDER_RESPONSE_ERROR, realmId=rak-development, clientId=null, userId=null, ipAddress=172.18.0.4, error=invalid_saml_response, reason=invalid_destination
Can you please help what I am doing wrong.
This happens when you configure the Identity Provider to 'Validate Signature'. When you turn that switch on, Keycloak validates the SAML response against the text in 'Validating X509 Certificates'. That field should contain a valid certificate from your Identity Provider; in this case the App registration in Microsoft.
Try turning the 'Validate Signature' switch off to see if that removes the error. Then you can debug the certificate value.
I had a similar problem and it turned out to be a misconfiguration of the F5 proxy/firewall. It sent the wrong header "X-Forwarded-Proto: http" instead of "X-Forwarded-Proto: https". Maybe this can help.
I found a solution. For me, the issue was that I needed to set the PROXY_ADDRESS_FORWARDING=true envvar. I had already done that but I typoed the name.
I am using the AWS ALB which sets the X-Forwarded headers. I know those are also needed.
What I want to do is this:
I have keycloak integrated with my application. So when my app is launched , keycloak login page is shown to user. Now , I am trying to provide an option to login with PingFedrate. So a button to login with PingFed appears(once a new SAML provider is configured in keycloak). On PingFedrate I tried to integrate SP inititated SSO:
I added a new SP connection and there I configured it as SSP initiated SSO. (It forced me to configure SOAP Authentication , where I selected basic and configured random username password). Then I downloaded metatdata.xml from this SP and imported in keycloak which autofilled the login url as : https://myserver:9031/idp/SSO.saml2 (i.e. without client id). After this when user clickon Login with PingFed - PingFed gives following error:
Unexpected System Error Sorry for the inconvenience. Please contact
your administrator for assistance and provide the reference number
below to help locate and correct the problem.
I found the solution to this.
Firstly, we need to add SP inititated SSO in Pingfed for keycloak.
Secondly, the reason I could not make SP inititated SSO work was that keycloak's entityId should be same as Pingfed SP connection's Partner's Entity Id / Connection Id.
Keycloak, by default keeps entity id equal to url of keyloak server containing your realm. E.g
https://(keycloak-server)/auth/realms/(realm-name)
(and I could not find a way to change it through Keycloak UI)
You need to enter this URL in Pingfed.
To avoid adding this manually, you can download the keycloak config from download export tab of identity provider.
And on Pingfed , import this file.
On a side note, though I was importing it earlier, I was changing value of Partenr id to some other name as I was not aware of above restriction until I started decoding the SAML tokens in request.
Hello I am using Nexus OSS, and wanted to simulate SSO, using Remote User Token. Currently the Nexus is configured to LDAP authentication, and is working fine.
As per the instructions found here https://books.sonatype.com/nexus-book/reference/rutauth.html
Basically enabled Remote User Token and added header field Name "REMOTE_USER". This user is ldap and has access.
This instance is behind apache, so from apache, To test this RUT, I can set the header value REMOTE_USER, whoever, I don't see passed in user getting logged nor I see cookie being generated. I even tried firefox rest api client and set header, but with the same results. I can see that HTTP header is being set right.
Am I missing something?
Is there a way to debug that? Appreciate any help.
Thanks
S
RUT handles authentication, but the authenticated user still needs to be authorized to access the web UI. What this means is that you need an LDAP user or group mapping in Nexus which assigns the necessary roles and privileges to the user.
I had a similar issue with Nginx, the header was not set using the correct value.
This can be quite confusing, as the reverse proxy does not complain and simply sends a blank request header to Nexus.
Using Keycloak and Nginx (Lua), instead of a preferred_username field in the IdP response:
-- set headers with user info: this will overwrite any existing headers
-- but also scrub(!) them in case no value is provided in the token
ngx.req.set_header("X-Proxy-REMOTE-USER", res.preferred_username)
I had to use the preferred_username field returned in the response's id_token element:
-- set headers with user info: this will overwrite any existing headers
-- but also scrub(!) them in case no value is provided in the token
ngx.req.set_header("X-Proxy-REMOTE-USER", res.id_token.preferred_username)
I am doing a jmeter test with CAS , but encountered a problem.
I got it logged in succesfully with full of CAS parameters(username/password/lt/service/_eventId), but the response data was not my page specified in the parameter "service".
It is not redirected.
Why? Does anyone know this issue?
I admit that I am not so familiar with CAS...
After reading the protocol of CAS, I find this:
(from http://www.jasig.org/cas/protocol)
2.2.4. response
One of the following responses MUST be provided by /login when it is operating as a credential acceptor.
successful login: redirect the client to the URL specified by the "service" parameter in a manner that will not cause the client's credentials to be forwarded to the service. This redirection MUST result in the client issuing a GET request to the service. The request MUST include a valid service ticket, passed as the HTTP request parameter, "ticket". See Appendix B for more information. If "service" was not specified, CAS MUST display a message notifying the client that it has successfully initiated a single sign-on session.
So ,I add a new request using GET with two parameters:service, ticket(its value is the same with lt).
Then the script run successfully and finally redirected..