JMeter test with CAS not redirect to service - redirect

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..

Related

Keycloak client URL configuration of redirectURLs

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

KeyCloak Integration with Azure ADB2C - Missing State Parameter

I’ve integrated “KeyCloak” (identity broker) with Azure ADB2C for authenticating a user.
Firstly, the user ADB2C Login user flow endpoint integrated with Keycloak and tested it, which is absolutely fine. Also, we have integrated B2C “Forgot Password” userflow endpoint with Keycloak, Upon successful Forgot Password completion in B2C, while redirecting the response back to the keycloak we are seeing an error response from the Keycloak screen as - “Missing State Parameter in Response From Identity Provider”
In the request url has Scope, Client_id, State, Response_type, Redirect_URI, nonce. But in the B2C response url contains “Client_ID”, response_type, scope and redirect_Uri.
So far, unable to find a way to handle this issue. Please suggest, if there is any approach to handle this issue either from the ADB2C or Key-Cloak.
“ADB2C- Implemented with OAuth standard authentication protocol”
Keycloak error page code:- “Missing State Parameter In Response from Identity Provider”
Thank you.
• The ‘state’ parameter is used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery attacks. In your case, the keycloak identity broker service is the authorization service while Azure AD B2C is the client.
• And since, the state parameter is missing in the response URL from Azure AD B2C, it might be the case that redirect URIs for the keycloak identity broker or the application may not be correctly configured in Azure AD B2C due to which keycloak throws an error of state parameter missing.
• Keycloak might have considered this response as a CSRF attack due to the missing state parameter and thus displayed an error whereas in Azure AD B2C, the redirection URI relating to specific keycloak page might not be correctly configured due to which though the response reached keycloak default URI but not the intended application integrated URI due to which the state parameter might be missing.
Please refer the below documentation links regarding CSRF and state parameter configuration as well as redirection URI in Azure AD B2C: -
https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url

Understanding HTTP Session security mechanism in JHipster

I am trying to figure out how the JHipster uses HTTP session for securing application and logging the user.
So far I’ve managed to understand the flow like this:
1) on landing page home.component sends request to api/account
with session cookies (if there are ones)
if there is a valid session >> uses credentials from stored cookies and then login the user
if no >> backend server responds HTTP 401 and sends XSRF cookie in response
As I understand responsible for this is Spring Security
2) when there was no acitve session we can fill the login form and log in
that sends request to api/authentication (XSRF cookie from step 1 required)
if all ok >> responds HTTP 200 and sends new XSRF cookie
if no >> HTTP 403 and sends new XSRF cookie
3) when step 2 is successful then frontend sends credentials from login form to api/account
one more time Spring Security checks XSRF cookie value (from step 2 this time)
if all ok >> business logic for log in the user is invoked
But in all these steps we need to intercept the cookies sent by backend and send them back to be able to pass through CSRF protection. Which part of JHipster project is responsible for that? Does it use webpack/browsersync or there is some Angular code created by JHipster which I am missing?
EDIT
My problem appeared when I've made a lot of changes to generated project as I want to use custom templates/styling and the services generated by JHipster. I've linked the templates with jhipster services.
When I try to log in the user I get in spring console output like this:
Forbidden: Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-XSRF-TOKEN'
From previuos request to api/authentication I get response with
Set-Cookie: XSRF-TOKEN=a129cb47-ec96-47be-aaae-69f90848c466; path=/
in browser network.
So it sets the cookie with wrong name I guess. I've change the cookie name manually in browser to: X-XSRF-TOKEN and resent the request. The new error looks like this:
Forbidden: Could not verify the provided CSRF token because your session was not found.
I don't understand the flow enough so I can't spot where is the problem. Maybe I've messed up and maybe there is some code generated by JHipster which is responsible for that. There are some classes in JHipster Angular frontend like StateStorageService. Do they take part in my problem or they are irrelevant to that issue?
I was facing the same issue while connecting a mobile app to the backend of spring boot. So basically angular has a method under the core functionalities called interceptors. Under the interceptors the response is gather and X-XSRF-TOKEN is captured and updated in Browser Cookie or in my case Ionic Local Storage as Cookie.

Nexus OSS Remote User Token (RUT) for SSO

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)

not recognized cas ticket

I have a REST api in my web application where I get cas ticket generated by another webapp.
That webapp intern use cas20proxyticketvalidator to validate the ticket. Therefore, I also use Cas20ProxyTicketValidator in my custom filter to validate the ticket.
But it always give me following error:
ticket = ST-148008-jWXKeEdHkxmuktvYqXF6-cas
org.jasig.cas.client.validation.TicketValidationException:
ticket 'ST-148008-jWXKeEdHkxmuktvYqXF6-cas' not recognized
at org.jasig.cas.client.validation.Cas20ServiceTicketValidator.parseResponseFromServer(Cas20ServiceTicketValidat
or.java:86)
at org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java
:217)
Why my ticket is not recognized?
The way that cas validates tickets is:
Your client (or the other web app) requests a ticket from the relay
server for a particular service, for example case
http%3A%2F%2Fwww.mywebapp.com
The cas server generates a row that stores the user's ssoguid, the service and the ticket. It returns the ticket to the client (or
other web app)
The client (or other webapp) sends the ticket to your server
Your server then sends a request to the serviceValidate endpoint of the cas server with the ticket and the service,
http%3A%2F%2Fmywebapp.com
The cas server uses the ticket and service pair to find the row it generated. If it finds the row it: a) checks to see if the
service is real by sending a request to that url b) deletes the row
to invalidate the ticket after this validation check c) it returns
the user attached to the ticket to your server. Now the ticket can
not be validated again.
The problem you are experiencing could arise for several reasons:
The ticket has already been validated (I don't think that is the
case for you)
The service you send when generating the ticket is different to the service you send to the serviceValidate endpoint (they have to
be identical). (I would guess that this is the problem you are
experiencing, especially if another webapp generated the ticket. The
cas server would have http%3A%2F%2Fotherwebapp.com on file but would
be trying to find a row with http%3A%2F%2Fmywebapp.com, which
doesn't exist because you didn't create it)
The service sent can
not be contacted by the relay server (I'm not exactly sure of the
details about how this works or exactly when the check it done but
it is recommended that you use a service that can be contacted)
Check the serviceUrl generated, so change the log level for package org.jasig.
With SpringBoot, in the application.properties add
logging.level.org.jasig=DEBUG
In the console
org.jasig.cas.client.util.CommonUtils : serviceUrl generated: https://xxx
Verify and adapt your cas.client-host-url in the application.properties
## CAS[2.0]
cas.server-url-prefix=https://cashost.com/cas
cas.server-login-url=https://cashost.com/cas/login
cas.client-host-url=xxx
cas.validation-type=CAS
Be careful with cas.client-host-url, no slash at the end of url.
Don't forget mvn clean package after modifying .properties