SEC-2939: Redis-backed PersistentTokenRepository

[spring-projects-issues]

Christopher Smith (Migrated from SEC-2939) said:

Increasing numbers of applications aren't using SQL datastores at all (my application is using MongoDB for long-term persistence), and the standard JdbcTokenRepositoryImpl would require provisioning a database just for remember-me.

Since Spring Session is largely using Redis as a persistent backing store, it would be very useful to be able to store remember-me tokens in Redis as well.

[spring-projects-issues]

Rob Winch said:

The current Remember Me feature is intended to offload the user information in a secure way that does not impact the memory footprint of the web application server. So, I'm wondering what the gain is over using Spring Session explicitly. If a user checks Remember Me, you could simply set the session to a longer max inactive time:

if(rememberMe) {
    request.getSession().setMaxInactiveInterval(ONE_YEAR);
}

UPDATE:

That said, we do eventually plan on coming up with Spring Security and Spring Session integrations (like this and concurrency support). It is really about finding the cycles.

See

• Spring Security Remember Me Integration spring-session#189
• Spring Security Concurrent Session Integration spring-session#65

[spring-projects-issues]

Christopher Smith said:

I'm using the UsernamePasswordAuthenticationFilter to handle authentication, and I didn't see any clear place to hook into it to do something like that, which was my first thought. Does adding support for that setting require a reimplementation of the login endpoint?

[spring-projects-issues]

Rob Winch said:

Pardon my ignorance, but what is UPAF?

[spring-projects-issues]

Christopher Smith said:

My apologies; I slip into Eclipse Open Type abbreviations. Edited.

[spring-projects-issues]

Rob Winch said:

Ahh that makes sense now thank you for the clarification.

Assuming you have Spring Session setup properly, you should be able to just implement RememberMeServices with something like this:

public class SpringSessionRememberMeServices implements RememberMeServices {

    public void loginSuccess(HttpServletRequest request, HttpServletResponse response,
            Authentication successfulAuthentication) {
        request.getSession().setMaxInactiveInterval(ONE_YEAR);
    }

    // ... i believe all other methods can just be no-op but you may need to invalidate session in loginFail ...

}

[SaltOfTheFlame]

in case of huge max inactive interval instead of remember me services, how will you differentiate "authenticated" and "fullyAuthenticated" users?

[ltkn]

It seems that the RememberMe implemented in Spring Session is very different from the original one in Spring Security where in Spring Security it is "more" secure but probably less scalable? (because of jdbc read and write on each request).

As far as I understand in spring session we are "just" extending the session time, whereas previously we could also detect if the session was stolen (see https://docs.spring.io/spring-security/reference/servlet/authentication/rememberme.html#remember-me-persistent-token)

is there any caveats in having similar algo in spring session ?
(for the background I came across this issue looking at ways to replace jwt with long expiry with something more secure without huge performance hit)
Edit: after further research I've decided to stay with jwt, the overhead to detect use of stolen token is too high for my use case, also probability it happens unnoticed as far as i understand seems very low with "Certificate Transparency" (https://certificate.transparency.dev/howctworks/).