In my code I am using spring direct login.
Once controller switches between https to http a new session is created, once new session is created, how do I pass/ copy the session attribute to new session Which was created by http?
Check the Spring Security FAQ. Basically, you can't copy the session attributes - all the session data from the previous is lost when you switch back to HTTP. Since the browser won't send the secure cookie, you have a new session and it's as if you hadn't logged in at all.
There are ways of working around this (see the FAQ for more details and search the web) but they are generally a bad idea. You should start in HTTPS and stay that way if security is important.
Related
So, I would like to implement complex session management in my application. Essentially, I would like to store user sessions both in the postgre and Redis.
So, the algorithm should be the following:
A request is sent to the app, the application parses incoming request cookies and extracts a session parameter;
Spring server tries to retrieve respective session object by id from Redis
If the previous step succeeds, then the server verifies the session and lets the request pass through if the session is active and valid. Otherwise - unauthorized path.
If the session object isn't present in the Redis, then the server tries pulling a member session from the postgre. Does the same verifications and caches the response. If the session isn't valid or isn't present in RDBMS - go to the unauthorized path.
Is there any elegant way to implement the following mechanism using existing packages? Or will this require custom logic?
So, I watched this video - https://www.youtube.com/watch?v=TggWLDAXmb4
And I was able to get a gist of how basic security mechanisms work in Spring and implement the workflow described above;
Basically, you will need to have:
Custom security filter that will be preparing specific Authentication;
Custom authentication provider that will be performing authentication (checking session)
I am working on Security scan(to avoid cross site forgery) with the CSRF approach of tomcat(apache-tomcat-6.0.32) but I am getting following issue with firefox:
1. Firefox is not supporting CSRF provided by tomcat in a proper way firefox creating multiple sessions.
2. Whenever any exception (like JSP exception) comes on page. Firefox redirects it to CSRFPreventionFilter and this filter creates new session.
3. Sometimes while traversing through application also CSRFPreventionFilter filter creates new session.
The creation of an HttpSession is by design: the CSRFPreventionFilter uses an HttpSession object to store the nonces used to protect your URLs.
CSRFPreventionFilter only calls HttpServletRequest.getSession(true) and never invalidates the session, so it shouldn't be creating any additional sessions (or switching a session).
Note that recent versions of Tomcat will change the session id when crossing an authentication boundary (i.e. when you enter your username and password). This is a mitigation against a different kind of attack: session fixation.
I have a web application running on JBoss server based on JSF framework.
I need to redirect my request to an entirely new web application running on some other server and on some other machine geographically located.
My doubt is if I redirect the request from my web page to another web application web page will it expose the session parameter at the other end.
I have some very critical information stored in the session and I cannot afford to expose the details to another web application..
Along with the redirect request I would be sending some parameters to the remote web application which will use these parameters for certain mathematical computation.
Can anyone guide me on this?
Is it possible for the other web application to see what is present in the session
No. That would have been a huge security hole throughout the current world wide web. Think about it once again, are you able to see what for example google.com and stackoverflow.com have in its session? No? Then the other web application definitely also can't. All which the web application can see from outside is the sole incoming HTTP request in its entirety.
This problem/question has at least nothing to do with JSF.
If you invalidate the session before the redirect then it doesn't matter if the external web application sees your session cookie. They couldn't turn around and emulate requests on your session anyway because the session is no longer valid.
request.getSession().invalidate();
I don't think this will be an issue though because I doubt that the request header to another web application would include the same session cookie.
i have a Swing-client and a Server running on tomcat 7, which communicate with each other using Spring (3.1) HTTP invoker. The communication works fine so far (even with TSL), but now i am trying to add Spring Security.
side-note: In a typical webapplication i would use basic authentication to authenticate the user. After my CustomAuthenticationProvider returns an Authentication object for the user, everything "just works", meaning that on every further request the SecurityContext is automatically set. I guess the login returns a session-key to the client which is send on every request to identify the session.
That is pretty much what i am looking for with HTTP-Invoker. At the moment it seems like i get a new context on every request, which is bad, because my customAuthenticationManager.authenticate(Authentication auth) method is pretty costy and should really only be called once per user-session.
Any Idea?
edit i found some hints on this at http://forum.springsource.org/showthread.php?10764-Maintaing-State-while-using-HttpInvoker ,but as this link is more then 8 years old, i was hoping for an easier solution.
I found the solution now. First you need to know that the spring-security part is completely the same as it would be in a webapplication (which is great).
On client-side you need a more complex HTTP-client implementation. I used org.springframework.remoting.httpinvoker.HttpComponentsHttpInvokerRequestExecutor. On server-side you could use the create-session="always"-Attribute of the <http-element to ensure that a session is always created. However, i found it better to create the session myself (just call httpServletRequest.getSession() which creates a session if non exists), because that way you can specify when to do that. In my case i create the session in my authenticationProvider only if authentication was successful.
How do Spring sessions work when you login to a form on Spring security as described in this tutorial? http://static.springsource.org/spring-security/site/tutorial.html
Is it cookie based? Im not sure what exactly is going on that allows the user to log in and have it remember and keep you logged in for the remainder of the browsing session.
It is cookie based similar to how the servlet maintains sessions . If cookies are disabled, you would have to resort to URL rewriting .According to the FAQ here.
"All it sees are HTTP requests and it ties those to a particular session according to the value of the the JSESSIONID cookie that they contain. When a user authenticates during a session, Spring Security's concurrent session control checks the number of other authenticated sessions that they have. If they are already authenticated with the same session, then re-authenticating will have no effect. "
also
"If clients have cookies disabled, and you are not rewriting URLs to include the jsessionid, then the session will be lost. Note that the use of cookies is preferred for security reasons, as it does not expose the session information in the URL. "
See here for the Single sign on feature