We are implementing the SSO via the Keycloak. When an user wants to access our resources on desiredUri, he is automatically redirected to the keycloak login page{keycloakServerHostname}/auth/realms/{realmName}/protocol/openid-connect/auth?response_type=code&login=true&scope=openid&state={uuidOfStateForCSRF}&client_id={clientName}&**redirect_uri**={**desiredUri**}.
Then a login form is presented, but when I fill in the credentials and the POST call submitting the request is issued on Keycloa, the response from Keycloak is 302 FOUND, but the Location header does not contain my desiredUri+paramsForGettingTokens, but consists of keycloakServerHostname+paramsForGettingTokens instead.
The weird thing is when I manually put i.e. google.com to redirect_uri param, it works and the location header points to google.com, but as soon as I put there localhost, some IP etc. (not resolvable by a public DNS), it stops working and starts to ignore the redirect uri.
It looks like the Keycloak is validating the redirect uri with some kind of DNS lookup and when it cannot resolve that DNS, it puts the baseUrl of Keycloak there instead.
How can I turn off this behavior?
My client settings are as simple as they can be:
Keycloak settings screenshot
Thanks for any advice.
Related
Premise:
I have an existing application with its own ACL.
I've also implemented the CloudFlare WAF.
My client's organization has not yet implemented a VPN.
We are seeing a lot of false-positives from the WAF for normal behavior in the application's Administration panel and because there is no predictable IP or set of IPs we can whitelist, we're struggling to unblock Administrators without turning the WAF settings down too low.
I'd like to setup something like HMAC validation, but that seems to assume that the URL of every request include the MAC hash. Instead, I'd like to store that MAC has in a cookie and use something like the user's IP address as the message. It would look something like this:
User load Administration panel's login page
User authenticate's with the panels ACL
The first page load of the panel adds a cookie with the token {time}-{hash} where the {hash} is base64_encode(hash_hmac("sha256", $userIpAddress . $time, $secret, true)) (PHP)
Future requests from the Administrator's browser include this token cookie. CloudFlare's Firewall Rules check is_timed_hmac_valid_v0 [documentation] using ip.src as the message and comparing the hash to the specific cookie.
Part of the challenge I'm facing here is that I seem to only be able to use the entire cookie string like http.cookie and can't use the values of individual cookies.
How can I use the ACL of my application to inform CloudFlare that it should all requests from that user to bypass the WAF?
For the very first time, when the user is NOT logged in (via CAS SSO), it's redirecting incorrectly after login. It is repeating everything after # tag. Example: /appname/#/service/7120 is being redirected to /appname/#/service/7120#/service/7120.
However, if already logged in, it works correctly.
The fragment after # tag stays in browser, and never reaches to server. In other words, the request URI seen by server does not include the fragment. So after login, you can not simply restore to original request to include the fragment in server. Typically, you will need store the original request (including fragment) in client side (browser) by using javascript (say create a cookie) before you redirect user to login page, then restore request to the original request URI (say from cookie) after login.
I am trying to integrate Google authentication with my ASP.Net core application. I have successfully integrated the appliation with Google authentication, after the login google redirects back to the home page of the application. I however would like it to redirect to https://localhost:44303/Home/dashboard.
To fix this, I have changed the "Authorized redirect URIs" from https://localhost:44303/signin-google to https://localhost:44303/Home/dashboard, but when i do that I get a redirect_uri_mismatch error. Is there a particular "Authorized redirect URIs" format that i need to follow? I checked the documentation at https://developers.google.com/identity/protocols/OAuth2WebServer but perhaps I am missing something very obvious.
OAuth Consent screen: I cannot add localhost in the "authorized domains" textbox.
OAuth Client Restrictions: If I add https://localhost:44303/Home/dashboard in the authorized redirect url's then I get a redirect_uri_mismatch error.
Stack Trace:
Error: redirect_uri_mismatch
The redirect URI in the request, https://localhost:44303/signin-google, does not match the ones authorized for the OAuth client. To update the authorized redirect URIs, visit: https://console.developers.google.com/apis/credentials/oauthclient/685730099587-d2rac5lt7981tjkoo5td23ogm2q1at20.apps.googleusercontent.com?project=685730099587
Learn more
Request Details
response_type=code
client_id=685730099587-d2rac5lt7981tjkoo5td23ogm2q1at20.apps.googleusercontent.com
redirect_uri=https://localhost:44303/signin-google
scope=openid profile email
state=CfDJ8HG_FpcxsWVNk9Pwwx_Fh6NNjkmrebqlP7rA3Y3u0fx42o-r6KMmiNmbmC2vjIuZLqmTZMA8O8AfMgIxXO8Tj9k3x2PLe6wNyL7xqOXi6Yj-AJUmeZFwievUqEAuCKHClYJOFPAlKTxrnYIYCXoJjvwg8BM4JBKA_NgFGjy_CbGHrI2kyUC63Z7INhYHdwEyO13AsBfYXR4LfxAGf3jz3x8-ZKDUDgFOqYYKXXcDHt2VqlERXOVXdEqNUcxUtfhM
Just run into the same problem!
Just add to the Authorized Redirect URL:
https://localhost
Without any port or additional thing!
The message
The redirect URI in the request,
https://localhost:44303/signin-google, does not match the ones
authorized for the OAuth client. To update the authorized redirect
URIs, visit:
https://console.developers.google.com/apis/credentials/oauthclient/685730099587-d2rac5lt7981tjkoo5td23ogm2q1at20.apps.googleusercontent.com?project=685730099587
tells you pretty much all you need to know. Note that you can configure multiple redirect URLs to deal with every permuatation of test, stage and production servers. Just make sure that the redirect URL your app uses is an exact string match to one of the configured URLs.
I want to use an Apache proxy server (mod_proxy) to intercept all requests and responses to a web server. However I want to change requests and responses before redirecting them. Simply rewriting URLs is easy and documented, but the changes I want to make are more sophisticated, namely they need to inspect the request for user credentials as well as conditionally make redirects.
Is this possible in Apache's mod_rewrite, possibly in combination with other modules?
While the main goal is to implement this in Apache, I would also be happy with an alternative solution which doesn't necessarily use Apache.
Here is a more precise explanation of what I want to achieve, to give a little more context:
Check each incoming request for user credentials. If credentials are present, they are replaced by the user information which the web server can use to identify the user (Ideally in the Authorization header)
For example, let's assume a request contains a cookie which authenticates the request as beeing sent from the user "John", this cookie is removed, and the Authorization header is changed to Authorization Authenticated_by_proxy {"id":12345,"name":"John"}
Check each answer to see if it's an Error 403. If this is the case and the user is not logged in, redirect the user to a login page instead of forwarding the error
From Google Developer Console page, it explains the meaning of "Google Redirect URI" is :
Determines where the response is sent. The value of this parameter
must exactly match one of the values registered in the APIs Console
(including the http or https schemes, case, and trailing '/').
Not sure, whether this explanation is same as my think or not:
On my app (web application), it allow user to sign-in via Google (Assume, I registered a Google project with ClientID/secrete configured on my web-app, and on Google COnsole page the redirectURI is "http://bbc.co.uk" ).
After I login to Google successfully by my Google account, my Web-app login page will be redirected to "http://bbc.co.uk" as on Google RedirectURI ?
That last sentence is a bit ambiguous. A better description is:
After I login to my Google Account successfully with my Google
credentials, Google will redirect my browser back to
Redirect URI http://bbc.co.uk that is registered for the web app in the Google > API Console.
Just to be sure: this means that the Redirect URI should be part of your web app. It is not actually Google's Redirect URI but it is the Redirect URI that you've configured in the Google API Console for your web app.
Let me see if i cant explain this in a different way.
What would happen if you didn't have a redirect URI?
If you go to the Developer console and create a Client ID for native application by default the redirect URI
This will redirect the Authentication back to where ever it was request from. In the case of native installed applications this is needed because there is no way to know where the user is that has installed the application.
Lets look at this in action
Request authentication:
https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
If you place the above line in a web browser the user will see something like this
Assuming they select ok then they get this displayed back at them.
That is the Authentication code, not to be confused with the access token. This is just the first step. Once your application has the Authentication code it can then exchanged that for a refresh token and a access token. Most client library handle this step internally. You and your users never see this Authentication code.
Back Redirect URI:
In the case if a web application your web application needs to be able to get a hold of that authentication code. Now I probably shouldn't be telling you this but you could just use a native application client in your web application and it will work. Why because the authentication server will just return the Authentication code back to where ever it was that requested it. For security reasons this is probably a bad practice.
So what do you need to place in the redirect uri. It is the file that you have ready to handle this authentication code. Normally its just the same as the login page, but you can have several. Just put each of them on separate lines.
http://localhost/login.php
http://www.daimto.com/login.php
I like to do this because then it works when i am testing locally vs when its up on the server.
I think the wording "Determines where the response is sent" confuses a lot of beginners as it implies that Google will somehow call that URL directly. Then the word "redirect" leads people to confuse the URL with the page of the app that the user will get to once he's authenticated.
http://bbc.co.uk is definitely NOT the redirect URL. A redirect URL would normally look like https://myapp.com/servlet_or_php_that_i_wrote_to_process_tokens.php
Google will "call" servlet_or_php_that_i_wrote_to_process_tokens.php by redirecting the browser to it. Once servlet_or_php_that_i_wrote_to_process_tokens.php as done whatever is needed with the token, it will then issue its own redirect to (say) bbc.co.uk