I need to implement Sign Sign Out in Java using Spring Security. What CAS needs from my application is to access
https://www.home.com/cas/logout.cfm?service=myService&redirect=http://encoded.url.of.my.site
I put this URL to LogoutFilter's constructor parameter (as logoutSuccessUrl), so when I click logout URL on my site, Spring Security clears the session and redirects me to that URL, which is over HTTPS. It does what is supposed to do and the tries to redirect me back to my website's welcome address. However, this address is on HTTP protocol, not on HTTPS. So either because of sending some info in parameters when accessing that secure page, or because of redirecting back to non-secure, Firefox gives me a message:
Although this page is encrypted, the
information you have entered is to be
sent over an unencrypted connection
and could easily be read by a third
party.
OK, this is clear, but... How does logging using SSO work then? It essentially does the same thing. My website redirects to SSO's login page over https, which on success redirects back to my site, which is over plain http. How can I get rid of that message?
OK, after some research I got the answer. Firefox throws this message only if there is some post data in the redirect, which occurs from HTTPS to HTTP. This message can't be disabled, there is a corresponding comment in Firefox'es source code. The data that is posted (in form of XML) should allow to invalidate session. This also gives CAS an ability to invalidate session without any action from the user of the application (CAS posts data to that URL and application invalidates user's session).
Logging in didn't throw any messages because it was a simple redirect, without any data.
Related
Currently, I am testing an application that has a sign-in form and after successful authorization, sign-in should redirect the user to a custom URL that contains a code, for now, that URL is localhost. After redirect on GUI less, I see that redirect link on chromium, and second, after redirect, I get this kind of error:
chrome-error://chromewebdata/
Basically, it says that chrome could not connect to that specific URL. is there an option to allow Playwright to connect on redirected localhost URL? Without any proxy or some kind of other things that are being used. So far I haven't found any helpful information about this topic when the user gets redirected to an HTTP page instead of HTTPS.
I hope that there is a solution to my issue.
I have a web application that when user click on the a link it will generate security information and log on to an external application if the security information is authenticated.
At this point from security concern I don't want to expose the URL and request information on the web page, so instead I am seeking solutions to handle the process behind the scene
I know Apache Components can easily send post request within POJO, jersey client can do as well through web service. However the requirement here is also including to let browser automatically redirect to the 3rd app's front page if the login process succeeded.
My question is what could be the proper solution to handle the login process and go to the external application from web as well.
Say you have:
publicapp.com
secretapp.com
Set up an API in publicapp.com to POST the initial request to itself. When the user submits the initial login form it goes to say publicapp.com/login. This endpoint will pre-process the information then send a server to server request to secretapp.com/login.
If secretapp.com/login accepts the information it responds to publicapp.com with a success and publicapp.com redirects the client to secretapp.com/home, with a short term auth token encoded in a JWT. secretapp.com, swaps the short term token for a full auth token.
In the above scenario, the actual login endpoint is never made public. secretapp.com should also have IP whitelisting to only accepts login attempts from publicapp.com. You can also do a lot of filtering on publicapp.com to eliminate malicious requests without bothering secretapp.com.
I believe my issue is something very similar to the following question Spring security 'remember me' cookie not avaiable in first request.
Basically I have a set of applications for a corporate intranet that share authentication through a remember me cookie. The cookie's domain is set to .domain.com so it can be shared across applications since they are all on the same domain or subdomain.
If a user is not logged in and attempts to goto a secured application they are redirected to a central application for login. After logging in the user is redirected to the original application they were sent to the login screen from however here is where the issue begins. On this first request the Remember Cookie will not be present in the HttpServletRequest on the app receiving the redirect and the user will fail to login, being redirect right back to the login screen. At this point though the actual cookie is in existence and valid and the user can manually go to the url they just came from and be logged in by remember me cookie.
For example
domain.com/app -> redirect -> domain.com/main/login -> redirect -> domain.com/app -> redirect -> domain.com/main/login -> manually navigate -> domain.com/app -> logged in.
I've tried several solutions from redirecting on the backend with response.sendRedirect to send the user to an intermediate page first that redirects with JS and none of it has helped. The cookie is simply not there on the first request for the other applications. To make it even more confusing, if the login redirects to the main application that contains the login page, the cookie is there instantly on the first request.
Any thoughts?
This ended up being do to the request cache getting in the way during our series of post login redirects. Add the following to our java security config fixed the issue.
public HttpSecurity configureHttp(HttpSecurity http, IntranetSecurityAccessDeniedHandler intranetSecurityAccessDeniedHandler) throws Exception {
http
.requestCache().requestCache(new NullRequestCache()).and()}
I'm trying to authenticate my Java application with a CAS-auth-based web. What I understand so far is that I need to handle cookies. I have retrieved the cookies from the login-form HTML page, and it sends me an JSESSION cookie. The value of this cookie is retrieved with a POST submit.
My problem is that after that submit, I got an "Successful login" HTML as response, but I don't know how to get the CASTGT cookie. I need it to access the services on the web (Intranet, being specific).
Additionally, in the browser, after the login I see the two cookies (JSESSION and CASTGT) from the domain who provides the login form, and another JESSION cookie from the domain which provides the intranet.
You don't need to deal with cookies directly at all. So long as you have declared the AuthenticationFilter and ValidationFilter instances in the web.xml file of your web application, you will be able to interact with your CAS Server instance through the CAS Java client API.
See Configuring the JA-SIG CAS Client for Java in the web.xml for more information.
I have a Java application running on Tomcat 6.0.29, with Apache 2.2.3 in front.
The login page uses HTTPS, while most pages use HTTP.
If a user tries to access a page (HTTP) that is login protected, he gets redirected to the login page (HTTPS), logs in, then gets redirected back to the originally requested page.
This works great, as the JSESSIONID cookie is set as non-secure, and used for both HTTP and HTTPS.
However, if the user starts at the login page (HTTPS), the JSESSIONID cookie is set as Secure, and thus the session is not available after login when redirecting to pages under HTTP, forcing a new session and redirect to login page again. This time it works though, because this time the JSESSIONID cookie is set as non-secure.
How can I avoid that users have to log in twice when they hit the login page first?
(Update: for clarity) Starting with the login Http get/post use https and use https through out the user's logged in session.
Use Http only when there is no logged in user.
There is a reason that cookies are not allow to cross protocol boundaries - it is an attack vector! (* see update below)
How to do this very bad idea
If you really insist, encode the jsessionId in the redirect to the http url ( or always encode the jsession id in the url). When Tomcat gets the http redirect, tomcat should find the session and continue.
Why you shouldn't do this
Seriously, any site that mixes https and http content on the same page is just opening themselves to all sorts of fun (and easy) attacks.
Going from https to keep the login "secure" is pointless if the rest of the session is in cleartext. So what that the username/password (probably just the password) is protected?
Using the ever-popular man-in-the-middle attack, the attacker just copies the session id and uses that to have fun. Since most sites don't expire sessions that stay active, the MIM effectively has full access as if they had the password.
If you think https is expensive in terms of performance look here, or just search. Easiest way to improve https performance to acceptable is to make sure the server is setting keep-alive on the connection.
update 1:
For more see Session Hijacking, or Http Cookie Theft
update 2:
See Firesheep Firefox plugin for how to do this quick and easy.