There are several problems with the concurrent session control code, mostly stemming from the fact that it is largely to do with Http sessions (although in theory the session could be something else) but the checks are applied through the AuthenticationManager and not in the web layer. This requires that a session already be created eagerly, wasting resources, before the ConcurrentSessionController is invoked. The creation of a separate internal AuthenticationManager for use by the <http> namespace block is also incompatible with the current approach (
Ideally the sequence should be:
1. the AuthenticationManager is called first to authenticate the request.
2. If successful, the ConcurrentSessionController is invoked to determine whether the authentication will exceed the allowed sessions
3. A new session is created to store the authentication and provide an Id to add to the SessionRegistry
4. The ConcurrentSessionController is invoked again to register the authentication with the SessionRegistry
This creates some issues:
1. The control cannot be enacted from a single point (the AuthenticationManager). It could be integrated with the existing SessionManagementFilter and the AuthenticatedSessionStrategy interface.
2. Event generation will not be as simple as before. the AuthenticationManager will generate a success event and subsequently, the AuthenticatedSessionStrategy (with the concurrent checks built in) will reject the authentication.