Im currently trying to load test a website with keycloak authorization.
The problem is that i cant find the authorization code anywhere in the previous https requests, so i cant use the regular expression extractor to grab it and turn it to a dynamic variable. So how do i configure it to be dynamic?
the auhorization code as it was recorded with blazemeter
i already turned to session_code, tab_id and executive into dynamic variables, but it still returns "{"error":"invalid_grant","error_description":"Code not valid"}"
As per Authorization Code Flow:
Browser visits application. The application notices the user is not logged in, so it redirects the browser to Keycloak to be authenticated. The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect that Keycloak will use when it finishes authentication.
Keycloak authenticates the user and creates a one-time, very short lived, temporary code. Keycloak redirects back to the application using the callback URL provided earlier and additionally adds the temporary code as a query parameter in the callback URL.
The application extracts the temporary code and makes a background out of band REST invocation to Keycloak to exchange the code for an identity, access and refresh token. Once this temporary code has been used once to obtain the tokens, it can never be used again. This prevents potential replay attacks.
My expectation is that you don't see the code anywhere because the code has been passed from keycloak to the application via the redirect URL.
So instead of asking keycloak to send the redirect back to application with the temporary code you need to ask it to send the request to JMeter and catch it via i.e. HTTP Mirror Server, once the request reaches JMeter you should be able to get the temporary code using Regular Expression Extractor or Boundary Extractor from the Location header.
Related
I am facing one problem that i am unable to login to the liferay website using JMeter.
The problem i know already but don't know how to hanmdle it.
I get to know that "p_auth" token is requried to access the sub pages, but here i am facing an issue in which i don't even able to acccess the login page itself if run the script second time.
My concerns:
how to check "p_auth" token parameter for login page (i.e without login)
Please help me to solve the problem.
Note: i tried to extract the "p_auth" token , but i am unable to see any "p_auth" token for login page itself(i.e without login.. just a login page(get api))
Your test plan need to look like:
Open Login Page - HTTP GET request
Extract p_auth dynamic parameter value using a suitable JMeter Post-Processor
Perform the login - HTTP POST request where you need to provide your credentials and the p_auth token value from the previous request
You won't be able to "see" the token in the page, it's hidden in the page source so you will need to use browser developer tools or JMeter's View Results Tree listener in order to "see" the token value.
Also don't forget to add HTTP Cookie Manager to your test plan as missing CSRF token is not the only thing which can stop you from logging in.
I'm currently working on an application that would rely on connecting with Coinbase and am relying on OAuth2 for authorization.
After reading and watching tutorials on implementing it via Spring, I'm able to open the authorization request page for Coinbase but cannot redirect to retrieve the token. When it redirects, it goes to the same port (localhost:8080) that is used to establish authorization. Whereas in other tutorials I've seen the application handle this properly and continue, the application instead launches the authorization page again.
What I'm wondering is how is Spring supposed to retrieve the token/code once the redirect occurs? If I change the redirect to something besides the url used to start authorization (8080 to some other number), then I see the url containing the code in my browser, but my application can't programmatically use it (unless I copy paste but this would be improper). If the redirect is 8080 then, it starts the process all over again and I can't use the code that was passed. It's probable a simple error but I appreciate any feedback as I'm still new to this.
security.oauth2.client.clientId=[redacted]
security.oauth2.client.clientSecret=[redacted]
security.oauth2.client.scope=wallet:accounts:read
security.oauth2.client.accessTokenUri=http://www.coinbase.com/oauth/token
security.oauth2.client.userAuthorizationUri=https://www.coinbase.com/oauth/authorize
security.oauth2.resource.userInfoUri=https://www.coinbase.com/oauth/authorize
security.oauth2.resource.preferTokenInfo=true
security.oauth2.client.pre-established-redirect-uri=http://127.0.0.1:8080
security.oauth2.client.registered-redirect-uri=http://127.0.0.1:8080
security.oauth2.client.use-current-uri=false
I am running spring web application in broswer. I logged in to my account and update some value using a url say localhost:80/update/name. On the controller side I check principal==null if not redirect to login page.
Now while login to this application. I open other web application page in the same browser and execute the same update url localhost:80/update/name through ajax call and it is updating the value. How can i avoid this security threat.
How can i make sure that Application1 update url will be executed by application1 request only? Application2 should not be allowed to execute app1's update request no matter whether it is in same browser ?
Why are you surprised ? You are logged, thus the browser has a valid session cookie. You ask the browser to send a request to the host (be it in first window or any other window, it is the same) : it sends the request with all relevant cookies, including session cookie and if appropriate any other security cookie. The server receives a request containing a valid session cookie for a valid logged user and even if it controls IP addressed coming from same address : all is valid and it proceeds with the request.
If you have a different browser on your client machine and if you open the connection from this unrelated browser, the server should reject your request, because the browser would not present a valid cookie.
You are describing a variant of cross-site request forgery, you should enable Spring Security CSRF protection. You can read about it in the reference manual.
Even if the two applications are on the same server, they will get different CSRF tokens, which will protect your case.
You described Cross-Site request forgery attack. Typically when POST method is used hidden token is added to prevent it. I assume You are using GET method - It is good practice to not change any state using GET method.
I have implemented an OAuth2 authentication mechanism in my GWT app. The OAuth2 server is based on Spring framework 3.x (using its Spring security OAuth2 implementation).
I am using the OAuth2 "Authorization code flow" to get the user authenticated (though implicit flow may have been a better choice in our case). So at first, the user is redirected to the OAuth2 server authentication page, he enters his credentials and if he is successfully authenticated, he is redirected back to a url with an oauth code. He will then make a second call to get an access token from the OAuth2 server.
Now, the issue is, we would like the user to be able to bookmark a page in the application and directly access it. If he has already authenticated then he would have direct access to it (no more auth involved). Otherwise, he would have to go into the OAuth2 authentication flow but in the end, should be redirected back to the bookmarked page he intended to access at the beginning.
How can I store this page url and get redirected to it after the user successfully authenticates ?
any help would be appreciated. Thanks!
EDITED
The initial url redirection is done via javascript's document.location.href
The way to maintain the original URI in an OAuth 2.0 Authorization Grant flow is to pass it in the state parameter so that the redirection endpoint can use it, after it exchange the authorization code for an access token, to redirect the user back to that URI.
FYI, this is exactly what Google suggests in the examples in their OAuth 2.0 documentation, e.g. https://developers.google.com/accounts/docs/OAuth2Login
Original answer:
The problem is using the hash part of the URL for the place, which is not sent to the server and thus cannot be used in the redirection to the OAuth2 server authentication page.
You have 2 (maybe 3) solutions:
stop using the hash for the place and switch to HTML5 History; either through gwt-pushstate at the History level, or a custom PlaceHistoryHandler.Historian if you use the Places API. That limits your audience though: http://caniuse.com/history
stop using an HTTP redirect, and instead use JavaScript so you can put the hash in the OAuth2 redirect_uri. So instead of redirecting, send an error page with the appropriate scripts bits.
some browsers append the hash to the URL after a redirection, so your OAuth2 server might be able to pick it (in JavaScript) and append it to the redirect_uri. That might depend on the HTTP status code used for redirecting (from experience, it works with a 301, but you don't want a 301 here). Needs testing.
You can do this using GWT activities and places.
I'm trying to access a REST service via a server-to-server GET request that is secured by OpenSSO/Spring Security and am unable to. It's like my Spring Rest Template client is not stateful to hold the cookies it should as I get redirected through the authentication workflow.
When doing this with a browser, the initial request is redirected to OpenSSO, I'm challenged for my cert (PKI), I present it, get a response with my authentication cookie header. Then I am redirected back to my original destination, I present my auth cookie in the request header and I'm on my way.
This isn't happening in my server-to-server invocations.
I've searched for quite a while now and can't seem to find any solutions that hold onto this state across redirects!
Following the link in zagyi's comment may have worked, but I spent some more time and found the following solution, which does not involve overriding anything:
To handle the authentication cookie in the REST controller, you have to explicitly tell it to accept cookies. Before handling the call, add the following line of code:
CookieHandler.setDefault(new cookieManager(null, CookiePolicy.ACCEPT_ALL));