I have deployed the OIDC provider-keycloak in a k8s cluster and it is exposed as a load balancer.
I'm using this along with Istio to redirect back to my application after successful login in keycloak.
The application is accessible at https://<istio-ingressgateway-ip>/hello
When I hit https://<istio-ingressgateway-ip>/hello, it is correctly re-directing me to Keycloak login page at https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
However, after entering the username and password for the user, I'm not able to get the redirection back to my application at https://<istio-ingressgateway-ip>/hello.
I think the user set up is correct as I'm successfully able to login to the keycloak user console at
http://<keycloak-ip>/auth/realms/<realm-name>/account
I have configured the below values as the 'valid redirect URIs' in keycloak client:
https://<istio-ingressgateway-ip>
https://<istio-ingressgateway-ip>/hello/oauth/callback
https://<istio-ingressgateway-ip>/*
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth/oauth/callback
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
Can please someone let me know what is missing here for the redirection.
Assuming you are using Authservice for the authentication and that your configuration is correct. I had the same issue and when I looked at the logs from the authservice container in my pod, I got to know that authservice failed to obtain the access token in exchange with the authorization code. The issue, as stated by Ryan from Authservice was:
When the Authservice tried to gracefully shutdown the TLS connection, and the server on the other side did not participate fully in the graceful shutdown.
This issue now has been fixed, and you can build a new docker image from the master branch to be able to fix it. More details about the issue and its resolution can be found on this github issue.
If in case this is not the issue, then there could be a problem with the flow from keycloak, you can use OpenID debugger to get the authorization code and then you can use that code to get the access token. This will help you identify if there is an issue on keycloak part.
If your configurations are correct and the above fix doesn't solve your issue, you should consider creating an issue on github with the logs from your authservice container.
Related
I am trying to add a cognito auhtentification to my load balancer following https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html?icmpid=docs_elbv2_console.
When I setup the authentification process, I have only the "oidc" type, but I expect a "cognito" type :
When I try the rest api, I have the same problem
Action type 'authenticate-cognito' must be one of 'redirect,fixed-response,forward,authenticate-oidc'
cognito is not available.
Am i missing some permissions ? I am an AmazonCognitoPowerUser
I had the exact same issue on region eu-west-3 and it's probably a bug at Amazon that costed me a day of my life.
Good thing is you can actually configure Authenticate OIDC to behave exactly like Authenticate Cognito:
Issuer: https://cognito-idp.eu-west-3.amazonaws.com/[pool-id] (make sure to use pool-id and not pool-name)
Authorization endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/authorize
Token endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/token
User info endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/userInfo
The other info to fill should be straightforward.
Make sure to select your scope(s) in the advanced settings and to allow HTTPS outbound traffic on your load balancer security group.
The Callback URL of your App client in Cognito should be:
https://[CNAME]/oauth2/idpresponse if using a custom domain to access your final app
https://[DNS]/oauth2/idpresponse if using the load balancer DNS name to access your final app
I had the same issue, I was on eu-west-3,
By switching in eu-west-1 or us-east it works perfectly,
I guess the option isn't fully deployed yet
We have developped a SPA SaaS and went to a soft production launch recently.
Everything was fine until one of our customers told us they had trouble using the app.
Once they open the app, the first request to our backend triggers their proxy credential prompt. Hopefully on the login request.
They have to enter their proxy credentials to let the request go. All subsequent requests are passing properly and they can use the app.
The problem is:
When they stop using the app, close the browser and then come back the day after, the persistent login tries to connect them to our backend, but the proxy credentials prompt is not triggered and the request fails. All subsquent requests fail also.
For it work again, they have to delete all app data in chrome (so the service worker is unregistered, the localstorage and cache are cleared). The next api call will trigger their proxy credentials prompt and they will be able to work again.
So is there any way for the app to know if the proxy is set or not ? Any way of triggering the proxy prompt if not set or whatever ?
I don't exactly know how those proxies work and we have zero access to the proxy settings.
It surely is something with the credentials expiration after some time but that's all we can figure out right now. Maybe we could monitor some params in the request headers ?
We are using VueJS with axios for the requests.
My guess is when user session credentials get expired, your UI is not handling redirection to login page. When the user login for the first time you should store that the user has logged in successfully in browser localstorage. If your server returns 401 error code, you can delete the flag and redirect the user to login page. You can achieve that using meta fields in router.
Check out this link on how to use meta fields https://router.vuejs.org/guide/advanced/meta.html
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
I have been trying to resolve this for some time now. I tried googling for this problem but didn't manage to find anything. All the questions I found were about replaying already recorded HTTPS requests.
So, I need to record HTTPS requests on a site protected with simple authentication (the pop-up window asking for username and password).
And this is where I get stuck. I enter correct login details and confirm it, nothing happens and in a second i get prompted to enter login details again, no error message nothing. When I press ESC I get 401 UNAUTHORIZED error.
Basically the site is acting as if the login details were incorrect when in fact I tried the same login details without Jmeter's proxy and the server accepted it.
What I tried:
1) Logging into this site without JMeter's proxy - works without problem
2) Recording different HTTPS site with JMeter's proxy - I tried my email and that works correctly as well
I should also mention that I am behind a company proxy, but I tried it at home and the result was same.
As for JMeter configuration, I am using everything on default having:
Thread Group
HTTP Cache Manager
HTTP Cookie Manager
HTTP Request Defaults
Recording Controller
HTTP(S) Test Script Recorder
Guessing the Thread Group doesn't really matter since I don't run any tests, only recording.
Additional Details:
Server:IIS
Logging into sharepoint website
EDIT:
Forgot to mention I tried already Blazemeter Extension, but when i try to record the logging session, it just freezes. Website hangs on trying to contact Blazemeter Cloud and Blazemeter plugin freezes, making it imposssible to stop recording and having to restart whole browser.
Also just noticed that when I am already logged in and try to access the site it records it without any issue. So it's only the login which is problematic for some reason.
JMeter removes cookies and authorization headers while recording.
You can use JMeter Chrome Extension as an alternate way of recording your test scenario.
In order to properly replay the recorded script you'll need to add HTTP Authorization Manager to it .
Sharepoint can have different authentication types, i.e.
Basic HTTP Authentication
Windows Integrated Authentication (NTLM)
Kerberos
See Windows Authentication with Apache JMeter guide to learn how to bypass each authentication challenge in your JMeter test.
So I was able to finally resolve this. The issue lied in sharepoint authentication. I was logged in a domain with my personal account, but was trying to access the sharepoint using a different account.
Sharepoint ignored the login details I was prompted to enter and used mw domain credentials instead. So the answer for me was to access the sharepoint website while being logged into domain(windows) with the same account.
My problem is as follows :
I have an application protected by a mobile security test involving a LDAP server. The corresponding realm is called LDAPrealm. I use the form-based authenticator + custom LDAP login module.
When the connection to the worklight server is lost and then re-established, I see that the current user is not authenticated in the LDAP realm anymore.
What I want is be able to re authenticate the user without having him enter credentials again.
However, since the user is still authenticated for other realms included by default in the mobile security test, the worklight server does not challenge the client again for credentials, which is causing j_security_check error when trying to submit credentials.
As a side note those credentials are stored in the encrypted json store for offline authentication and use of the app.
So my question is :
Is it possible to force the server to challenge the client again for this LDAPrealm and use submitLoginForm to re-log in?
More generally, is there a way to clear a user+device from all realms before trying to log in again?
Edit reasons : previous error was caused by a typo
In the case where the user first logs in online then loses connection then get connection again, calling
WL.Client.logout("LDAPRealm",{onSuccess:stealthed_relog});
and calling WL.Client.connect() later in stealthed_relog before sending credentials seems to wield the desired behaviour.
However, when the user logs in offline and then gets connection, when I try to use WL.Client.connect(), it says another instance of WL.Client.connect has already been called.
edit : for the log offline case, the application get challenged automatically shortly after that the connected event fires (cause of heartbeat? I do not really know), so you just have to use
login_clientside.submitLoginForm();
to successfully log in again.
If someone has a better way to implement auto-reconnecting in worklight with ldap server, feel free to post it and I'll unaccept my answer.