I am trying to test my web application using JMeter which is protected by keycloak IDP. But when I try to login using the credentials the login fails saying "Please login from the client" and keycloak logs on the server says:
2021-04-16 11:10:05,316 WARN [org.keycloak.events] (default task-400) type=LOGIN_ERROR, realmId=my-realm, clientId=null, userId=null, ipAddress=10.x.x.x, error=invalid_code
attaching the screenshot of the request I recorded using Blazemeter chrome plugin, some parameters are being sent, any idea how could we configure this?
login URL :
https://Server_Address/auth/realms/my-realm/login-actions/authenticate?session_code=iXAkZuEnl25URJPfaSd8kaTdnwCqz5CY-pZoZUb33ns&execution=0e502d98-b482-4abc-a7a5-c31d06b1f9c2&client_id=my_client&tab_id=Fa8Ggyqw3tk
Unfortunately you won't be able to just record and successfully replay your scenario without prior correlation of the dynamic parameters.
These execution and tab_id and session_code guys are something you're getting as generated when you're being redirected to Keycloak instance which authenticates the user so you need to extract these values from the previous response and replace recorded hard-coded bullshit you get with the dynamic parameters
The easiest way to extract the values is using Boundary Extractor
Also these parameters should go in query string, not in the request body
Demo:
Related
How to generate OAuth2.0 access tokens in Jmeter.?
I'm able to get the setup for Postman using OAuth2.0. However, when I want to test these and develop script in JMeter, I am unable to get through it.
This postman setup doesnt ask for client_secretKey only required client_Id, instead it pops up a window where I enter the username and password and then it is redirected/called back to my application URL.
When I looked into the URL, it has the following parameters
https://product.auth0.com/authorize?
redirect_uri=abc.com
client_id=XXX
errorPath=%2Ferror
scope=openid%20profile%20email%20offline_access
response_type=code
response_mode=query
state=dynamicvalue1
nonce=dynamicvalue2
code_challenge=dynamicvalue3
code_challenge_method=S256
auth0Client=staticvalue HTTP/1.1
I know client_secretKey, now I am wondering if I can able to get to the authorisation/authentication of the application by using the client ID, secretKey grant type etc?
Please suggest on ways I can connect to and access the application.
Postman is a browser plugin, JMeter is not a browser hence it cannot "pop up w window"
The easiest way of capturing the network requests from Posman in JMeter is just recording it using JMeter's HTTP(S) Test Script Recorder.
Start JMeter's HTTP(S) Test Script Recorder
Import JMeter's certificate into Postman
Configure Postman to use JMeter as the proxy
Run your request in Postman.
JMeter should generate proper HTTP Request sampler and HTTP Header Manager and you should be able to replay the request.
Identify the dynamic parameters and perform their correlation
You should be able to replay the authorization flow using JMeter now.
I'm trying to trigger a jenkins job using the API. I got the set the token, got to run it successfully in the browser and got a json output from the API call using:
https://<MY_JENKINS_ADDRESS>/job/path/job_name/api/json/build?token=my_token
I tried to use this call in a POST or GET web activity in Azure Data Factory but I'm getting this error:
Error calling the endpoint '<MY_JENKINS_ADDRESS>'. Response status code: 'NA - Unknown'. More details: Exception message: 'NA - Unknown [ClientSideException] Invalid Url:https://<MY_JENKINS_ADDRESS>/job/path/job_name/api/json/build?token=my_token. Please verify Url or integration runtime is valid and retry. Localhost URLs are allowed only with SelfHosted Integration Runtime'.
Request didn't reach the server from the client. This could happen because of an underlying issue such as network connectivity, a DNS failure, a server certificate validation or a timeout.
It is clear data factory can't access the url. How can I solve this issue? Any thoughts?
I am assumimg that the <https://<MY_JENKINS_ADDRESS/job/path/job_name/api/json/build?token=my_token>> is not a publically available and if that the case you should know that with ADF you can only access public facing urls . What that means is that If there anything whch is running on my local network or say on my laptop , ADF will be not abe able to access that .
I am running my .net core 5 application, namely Authentication Server and API Gateway, in Docker in Linux container. And controller class in the API GateWay contains an [Authorize] attributes to validate the user. Despite the user is valid (eg register and log in successfully), API Gate is unable allow the user to access the API. And here a part of my log that is complaining:
Failed to validate the token.Microsoft.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException: IDX10501: Signature validation failed. Unable to match key:
kid: '6B7ACC520305BFDB4F7252DAEB2177CC091FAAE1'.
Exceptions caught:''.
Am I right to say that, is it due to the cookies generated by Identity Service 4; idsrv.session and .netcore related cookies failed to be shared.
This is because based on my observation when my micro-services are running in IIS. The Authentication Server, shall generates two mentioned cookies when user logs in successfully. And the mentioned cookies are "shared" among the rest of the micro-services, partly because they are in the same localhost but different port number.
When my application are migrated to Docker; the Authentication Server is able to generate the related cookies, the rest of the contains failed to get the cookies.
And as the result, which I'm guessing, that is the result that API Gateway is unable to authorise a valid user.
Hence, I am wondering is my understanding of Authorization is correct and how should I fix the issue with a valid user.
https://stackoverflow.com/a/58877655/3312570
The error code IDX10501 points to incorrect bearer token middleware.
Try adding cookies. Use the below code. My guess, it won't help.
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie();
I am working on an desktop based Java Swing application on which I have to invoke the web browser for authenticate and get the authorization code from that URI.
I was going through https://www.rfc-editor.org/rfc/rfc8252 RFC and read the "loopback interface redirection" terminology. Able to find the theocratical concept around this on Net but not able to find any example code.
Can someone help me to understand this better from code perspective or link to any example?
I have some code samples you can easily run from your local PC but they are not coded in Java. Hopefully they help you to understand how the solution works though:
Desktop Sample using Loopback Server to Receive Login Response
Desktop Sample using Private URI Scheme to Receive Login Response
The Nimbus OAuth Libraries might prove useful for a Java implementation.
We have achieved this after using the RFC 7636 https://www.rfc-editor.org/rfc/rfc7636 where in Java application, we are starting the inbuilt java http server on random port.
After starting the local server, we generate one random string called code_verifier and then client change it to code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) using SHA256 and create Bas64 encoded URL string and open the browser to do the authentication.
Once authentication is done from browser, webservice creates an auth token against the JWT token and store in DB along with code_challange.
Browser pass the auth token to client and after receiving the response, then client pass the auth token along with code_verifier to get the authorization JWT token. Webserver verifies both the entries against the stored info and passed back the authorization token after successful verification.
If you have an on-device application (e.g. desktop program, mobile device app) you can use OpenID Connect with some caveats:
Using Resource Owner Credentials (grant_type: password) is the simplest, but might not be possible if the authentication server operator won't let you use that grant-type because of trust reasons (i.e. they don't want you collecting the user's username+password yourself) - or if they have a dynamic or custom authentication UI that would be hard to replicate in a native app.
With the interactive flows (implicit, hybrid) the authentication sever's authentication page is shown in an in-app web-view. Most users will have no idea that the application can snoop on the authentication page and capture their username and password, especially on mobile devices - but this way the application code can easily capture the authorization code and/or access token, and automatically dismiss the web-view without any additional user interaction. (I'm surprised I haven't heard of more cases of users' details being captured by malicious apps this way.)
...so the advice is to always open the authentication page using the system's web-browser, but on the Windows desktop there is no good, standard way for the system web-browser to return the server response to the application code, though there are a number of approaches currently in use:
The authentication success page instructs the user to copy and paste a blob of text (containing the authorization code or access_token response) back into the desktop application.
Show the page in an app-hosted web-view, as per the notes above.
If the authentication process always only needs a username and password (for example) the application could still capture the user's username and password with its own UI and then make its own HTTP requests to make it seem like a user's web-browser session, and get the authorization code and/or access_token that way.
On Windows only:
Have a small utility program authHelper.exe that when invoked forwards its command-line arguments to a named-pipe in the user's session.
The main client-application will register authHelper.exe as a temporary URI scheme handler in the per-user HKCU\Software\Classes key, e.g. my-application: such that the contents of any my-application: URI are passed as arguments into authHelper.exe.
The URI passed to the system web-browser to open the authentication page has the redirect_uri parameter set to my-application:, so after the user authenticates in the browser, the browser will request the custom URI scheme which is handled by Windows, which invokes authHelper.exe "access_token=..." which then sends the data down the named-pipe to the running application.
If the user doesn't have permission to write to their own HKCU\Software\Classes key, or if they're using a version of Windows that doesn't support custom URI scheme handlers with EXE registrations then this doesn't work.
Windows UWP applications can also use the Web Authentication Broker.
I was wondering if a different approach could be used: why can't the application simply poll the authentication server for the status of the authentication attempt? Or does this approach already exist, and if so, what is the name of the flow or grant?
Here's the flow I'm proposing:
When the user wants to authenticate, the application opens the system web-browser as before, but with another parameter for a one-time-use opaque ID provided by the application.
As soon as the system browser is open, the application makes requests every 500ms or so (i.e. a polling loop) to the authentication server using its own HTTP client that asks for the status of the active authentication attempt associated with the same opaque ID as before.
The initial few responses from the authentication server to the application will presumably be status: pending, but eventually after the user successfully authenticates within a timeout window then the application's poll request would indicate a successful attempt and also contains the access_token or authorization code as is applicable. If the user failed to authenticate (e.g. 3 incorrect attempts) or left the window open long enough causing a timeout then the poll response would indicate failure.
Does this already exist and does it have a name? Are there any potential security risks or vulnerabilities with this approach?
It exists and has a name, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", but is not yet fully standardized, see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow
Google also implemented this flow avant-la-lettre in a vendor-specific way:
https://developers.google.com/identity/protocols/OAuth2ForDevices