I need to realise "logged in system" policy which means only one session per login. But problem is that I have sessionCreationPolicy.STATELESS and sessions actually doesn't exist. So how can I solve this task? What is the best approach?
I don't think you have a problem here. Since you're using STATELESS approach it means that Spring will not create any session: no security context, no cookies, every request must be authenticated on its own.
Related
I have a NextJS app that communicates with a Spring backend, I'm getting the SESSION and X-CSRF cookie correctly but they only last for the browser session, when the browser window is closed and then reopened I want my users to be able to still be in the session and not have to login again every time.
I know that Spring Security has "Remember me" unfortunately I'm using WebFlux Security and ServerHttpSecurity doesn't have the remember me functionality, I saw this issue https://github.com/spring-projects/spring-security/issues/5504 but couldn't understand well what they mean with the solution.
I'm using Spring Session and since we can't have remember me, I don't know what exactly are the best steps to take? Would I have to set the Max Age of both cookies and used them for the days that I want my users to be logged in? Is this the best course of action?
I don't want to migrate to regular Spring Servlet Security unless it was the only way to solve this.
Since RememberMe isn't on WebFlux Security applications therefore the only solution I think of, is with the cookies.
You could modify the session cookie in the webflux application by using this guide from Spring Session, for the CSRF token, you could set the max age on CookieServerCsrfTokenRepository, like it was implemented here and that change is coming in the next Security versions.
By setting the max age, you can still use the same session when you reopen the browser window, unless the server session times out.
I don't know if that's the best solution, but if someone wants to add something else that would be great.
What is difference between the following options:
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
and
http.sessionManagement().disable()
?
Seems like in the first case SessionManagementFilter will be added and do nothing. While in the second case it will not be added at all. So, seems like it is better to always use the second option if you don't need sessions. But I'm not sure.
Behaviour-wise I've noticed that, as you say, setting it as STATELESS adds a SessionManagementConfigurer to the SecurityBuilder and disabling it just adds null as the configurer.
This affects the SessionAuthenticationStrategyies added when configuring security. For example, enabling CSRF protection will add a CsrfAuthenticationStrategy even for statless case but will not for disabled session management.
To sum up: disabling it will not execute session authentication strategies at all but enabling it will execute it on each authenticated request for a stateless scenario.
Hope it helps, this is based on personal experience (configuring, trial-error, debugging).
Some users of my application can use it for a fixed maximum amount of time. At the first request happening past the expiration time, after checking the user is part of the target group, I want to invalidate the session, update the user and return a 401.
In theory a servlet filter invoked post-session-validation could be used for this. I am looking for pointers on how to do this using spring security.
Thanks!
While you could most certainly just add a normal servlet filter that executes at the very end of the chain (or at least after the Spring Security filter stack) where you get the SecurityContext and inspect the user (potentially logging out the user like this or this), I would suggest you instead simply change the session duration on per-user basis. After a successful login (AuthenticationSuccessHandler is a good place) you could simply call setMaxInactiveInterval on the session and give it a different value depending on the user's role. This seems a lot cleaner to me as you don't have to separately handle otherwise semantically equal actual and forced session expiration/logout cases.
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.
Sorry for the noobish question, this is the first time i try to implement a REST interface (in PHP). Anyway, because the stateless nature of HTTP protocol, what's the best practice in order to ensure that:
GET/ /user/{id}/friends
is always and only executed by the current authenticated user? Is session usually used as a method to restrict REST access?
You can use HTTP sessions, which are nothing more than server-side cookies. They're usually ok, but there has been a lot of reports of session hijacking lately. So my answer if you're really concerned about this is to use HMAC. It's tricky to set up, but once it is you can be sure that the message really did come from an authenticated user.