The SessionRegistry bean is useful to configure Spring Security session concurrency.
Combined with https://github.com/spring-projects/spring-security/pull/8548 Spring Session concurrency management would work automatically and as expected with Spring Session.
Right now, for Spring Session concurrency limits to work, one has to configure a bean and configure Spring Security to use it. In my experience, developers don't realize those two steps need to be taken, or simply forget to do them. So I've submitted a PR here to auto-confgure a SessionRegistry bean, and a PR to Spring Security to automatically use a SessionRegistry bean if one exists. Together, Things Just Work.
For the original report to Spring Session, see https://github.com/spring-projects/spring-session/issues/1629
Comment From: rwinch
I want to emphasize my comments on the linked issue above. In particular, I'm not sure that this is a good candidate for Spring Boot's auto configuration because it is not clear that adding Spring Session + Spring Security someone wants to create a SessionRegistry. For this to be useful, the user also needs to opt into concurrency control. There really isn't a good way to determine if this active. I suppose one option might be to make the bean lazy since Spring Security will request the bean only if needed, but I'm not sure if there is precedent for lazy beans with Spring Boot.
Comment From: candrews
Understood.
I'm aiming to make something work as folks expect. I've seen 14 projects now (2 of them my own, so I'm guilty of this mistake too) that use Spring Session and have the Spring Security session concurrency limit configured but neglected to configure the sessionRegistry. It's very easy to not realize that the sessionRegistry has to be configured, and catching this mistake through testing is also difficult.
I'd really like to figure out a solution to making this Just Work - so if Lazy is acceptable, I'm happy to amend this PR accordingly. Or if there's another approach that's more acceptable, I can explore that as well.
Thank you again for your help and consideration.
Comment From: candrews
Is there anything I can do to make this PR more acceptable or otherwise help with its review?
Thanks again!
Comment From: philwebb
@candrews This one has been flagged for team attention so that we discuss it on one of our calls.
I'm personally not too keen on the lazy bean idea, it's not that common for auto-configurations. In this instant, it would be nice if we could configure SessionManagementConfigurer so that the sessionRegistry must be provided. It feels like the confusion is caused by the fact that getSessionRegistry creates the SessionRegistryImpl for you. If it actually failed and made you configure something, at least you'd be making a conscious choice.
Comment From: philwebb
We discussed this one the team call and decided that all things considered we'd rather leave things as they are. We don't think auto-configuring a lazy bean is the correct approach, and we don't have a strong enough signal about when a SessionRegistry bean should be created eagerly. There's unfortunately no good answer for this one.
Thanks anyway for the discussion and PR.