Moved logic from AuthorizationCodeAuthenticationProvider
to OAuth2UserAuthenticationProvider (new) related to
loading user attributes via OAuth2UserService.
This re-factor is part of the work required for Issue gh-4513
The AuthorizationCodeAuthenticationProvider implements part of the
Authorization Code Grant flow as defined in
OAuth 2.0 Authorization Framework and OpenID Connect Core 1.0.
The implementation needs to be de-coupled to allow for better re-use and readability.
This commit introduces the AuthorizationGrantAuthenticator and extracts logic from
AuthorizationCodeAuthenticationProvider and provides different implementations
for OAuth 2.0 and OpenID Connect 1.0.
This re-factor is part of the work required for Issue gh-4513
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
Rob Winch
Joe Grandja
shazin.sadakath@gmail.com
Stephan Schroevers
Craig Andrews