I've tried to debug this without any success. I have a working Spring Application with GWT and Spring Security, but when I change the security-context around to use CAS authentication, I do get redirected to the cas page (usually), but after successful login, I get redirected to the correct url, but I get a "page not found error" at the browser level. After refreshing the page (same url), I'm logged in, and application loads as expected. No errors in the logs, as far as I can tell, no differences in what's happening in the application when using CAS vs normal spring security form login.
I believe this answered my question:
http://static.springsource.org/spring-security/site/faq/faq.html#faq-cached-secure-page
which basically states that if you're securing html pages, you're in charge of configuring caching, so that a cached page can't be accessed. In my case, this wasn't entirely clear, as the gwt services were still getting secured, so I wasn't seeing secured content, but still, that was the problem-
Related
I have a basic Spring (v5.3.23) web app running in an Apache Tomcat container (v9), and using eclipse as IDE. It uses Spring security for processing logins.
Everything runs almost correctly, but sometimes, after a successful login, the browser shows a white page, while there is no exception logged server-side or any other message. The problem appears both in development environment and production environment, so I don't think it's eclipse-related.
I have managed to pin down the problem to the following sequence :
Start tomcat container
Open login page in browser
After login, the secured home page is displayed correctly
Re-start tomcat (the problem occurs both when changes are made to the web app or not)
Refresh the browser, which redirects to login
Login again
The blank page is shown, no exception logged, no log messages in console
In this sequence, the problem occurs most of the time. If between steps 5 and 6 I refresh the page one more, meaning the login page is reloaded, the white page problem does not occur anymore, and the proper page is displayed.
A strong possibility is that it's something related to either the CSRF token in the login form or the JSESSION cookie of the container, but short of debugging through Spring code, I can't figure it out.
LATER EDIT
I narrowed down the issue to the CSRF token; if I change the value in the login form, I always get the blank page.
I have noticed the _csrf token has one value in the login form, then a different, but single value across all form that are used while the user is connected. Seems like the _csrf token is linked to the user session somehow.
The same happens when the login page is refreshed: different tokens in login & other app forms, but somehow,, sometimes, the initial token does not match what the server expects.
I've spent about a full day attempting to get a very basic Spring Boot app with Spring security up and running to no avail. I cannot find a single example of code that works when I run it.
This example is from spring.io. Here is what I'm seeing in that example:
I start at http://localhost:8080 and see the welcome screen.
I click a link to http://localhost:8080/hello, which redirects me to http://localhost:8080/login.
I enter "user" and "password" as specified in WebSecurityConfig.java, which redirects me back to the welcome screen. I was expecting to be redirected to http://localhost:8080/hello.
When I click the same link to http://localhost:8080/hello I get the login screen again.
I've tried debugging via #EnableWebSecurity(debug = true) but there are no errors.
The above experience is endemic of what I experience when I download every example. Admittedly I'm new to Spring, and presumably I'm making some kind of newbie configuration mistake. Any help would be greatly appreciated.
I downloaded the code and ran using maven and it works perfectly fine. After logging in, for all subsequent page loads of http://localhost:8080/hello loads the page and not the login page again unless of course I log out. The problem you have mentioned may be caused by ( with quite high probability since you have mentioned it's endemic) is that your browser may be having issue with transmitting the default JSESSIONID cookie (which is set on first page visit and updated ( as good security practise by Spring security) on first login. For subsequent visits same JSESSIONID is sent to the server and it is a key for the session object stored on server which contains the now authenticated/authorized user. If some how this cookie is not transmitted back to server ( one reason could be it's disabled in browser setting) then your application (protected by spring security) would not know that you are an already authenticated user and will show you the login page again. For e.g, for Chrome you can see the cookie settings at Settings --> Content Settings --> Cookies --> Allow sites to save and read cookie data (recommended). You can also view the cookie header getting passed on each page load post successful login by using Developer tool in respective browser.
My application will be:
- Single Page App (say in angular/backbone)
- Spring MVC based Server.
I find many examples about using Spring-Security where the login page, logout page etc.. are all HTMLs. And Spring Security directs to appropriate pages based on Session State.
But in my case the login/logout page will be in JavaScript - All interaction with the server for login/logout is over HTTP(REST style URLs), and response JSON. There is no HTML in play here.
Question
How can i use Spring Security in this case? In other words - How can i expose login/logout behavior as a API?
Since the front end is Browser based app... i guess usual cookies etc. should still work for identifying session.
Yes Cookies still work in your cases. But you need to tap on the ajax urls instead of normal urls. I had an experience with a mobile based - single page application and I managed to do it with a grails backend. When logging in tap on /j_spring_security_check?ajax=true if http response is 302 and it redirects you to /login/ajaxSuccess it means that you have logged in successfully. Otherwise you failed to login.
I have setup an application that uses Spring and the built in Spring Security CAS implementation. Everything seems to be working fine, and the users can login okay and all is fine. That is until you attempt to bookmark a page.
It seems that our system is retaining the ticket query parameter after the CasAuthenticationFilter fires in the Security Filter Chain.
We end up with users having URLs that contain the ticket query parameter in them. If they bookmark a page, and then return to it, they get a ticket doesn't exist error.
Is this expected behavior? I remember looking in the Jasig client implementation and they seem to scrub it there, but not in the Spring Sec impl?
Any thoughts?
Thanks!
Most of the Java-based CAS validation filters support RedirectAfterValidation. This will refresh the page and remove the ticket parameter.
See https://wiki.jasig.org/display/CASC/Using+the+CAS+Client+3.1+with+Spring+Security
Do a redirect (to a URL without the ticket parameter) after the user is redirected back to your app for ticket validation.
I'm using grails with spring security and the JA-SIG CAS spring security plugin.
One way I get this problem is when I have logged into the CAS server and I restart my application.
Another way is if I log into another application via the same CAS server and then when I access my application then spring reports me as being logged out. If I try and go to a secured page then the login controller sends the browser into the same redirect loop.
I can observer a stream of get requests to the cas server which is redirecting back to the application.
Basically the problem is that spring security isn't aware that I've already logged in to the CAS server, so bounces back to CAS server which says I'm logged in and bounces back to the app
I'm also using the single sign out. One workaround is to force a renew login when the application thinks someone is not logged in but it's not really a satisfactory solution.
Basically the problem is that spring security isn't aware that I've already logged in to the CAS server, so bounces back to CAS server which says I'm logged in and bounces back to the app
Check PreAuthentication docs. You'd have to implement a pre-auth-filter to let Spring know of an external authentication.