As principals and sessionIds are set in class itself so one can't share user session count across nodes(Cluster). Using constructor for setting principals and sessionIds we can pass Cache map to constructor which can enable common session count in cluster otherwise user would be allowed to logged in with multiple sessions. There is no point keeping principals and sessionIds completely internal.
When the principal of the Authentication is an object, it is not necessarily
an User: it could be another implementation of UserDetails, or even a
completely unrelated type. Since the type of the object is serialized as a
property and used by the deserialization anyway, there's no point in
enforcing a stricter type.
Not only is it more efficient without converting to an intermediate String,
using JsonNode.toString() may not even produce valid JSON according to its
Javadoc (ObjectMapper.writeValueAsString() should be used).
As of Spring 4.3 RC1 the `org.aopalliance` interfaces are once again bundled
with `spring-aop` [1]. Moreover, all modules with a dependency on
`aopalliance:aopalliance` directly or indirectly also depend on `spring-aop`.
This change drops the `aopalliance:aopalliance` dependency in all places it's
declared. Where applicable an explicit dependency on `spring-aop` was added in
its place. (This dependency was already present in most places; in one case the
module didn't require `aopalliance:aopalliance` in the first place.)
The documentation is updated accordingly.
[1] https://jira.spring.io/browse/SPR-13984
Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity).
Issue gh-4077