* Use a valid SemVer format for the SNAPSHOT version
* Update pom.xml
* Update pom.xml
---------
Co-authored-by: Stian Thorgersen <stianst@gmail.com>
Co-authored-by: Stian Thorgersen <stian@redhat.com>
It was incorrectly relying on web application listeners on session
destruction.
While it's used as a Spring Bean (declared in
KeycloakWebSecurityConfigurerAdapter) so it has to use Spring-based
facility.
See also https://lists.jboss.org/pipermail/keycloak-user/2016-March/005479.html
I use Keycloak Spring Adapter (KSA) to secure existing application. Today I realized that some functions didn't work anymore because of security checking like this:
```
GrantedAuthority adminRole = new MySpecialGrantedAuthority( "superadmin" );
for ( GrantedAuthority role : userRoles ) {
if ( role.equals( adminRole ) ) {
return true;
}
}
```
In this example, when I use KSA authorization fails.
I believe, that more preferable in `KeycloakRole` use this implementation of `equals` method.
I use Keycloak Spring Adapter (KSA) to secure existing application. Today I realized that some functions didn't work anymore because of security checking like this:
```
GrantedAuthority adminRole = new MySpecialGrantedAuthority( "superadmin" );
for ( GrantedAuthority role : userRoles ) {
if ( role.equals( adminRole ) ) {
return true;
}
}
```
In this example, when I use KSA authorization fails.
I believe, that more preferable in `KeycloakRole` use this implementation of `equals` method.
This is an issue with the Spring Security Keycloak Adapter relating to
the way the Authentication is stored in the SecurityContext, causing a
race condition in application code using that. It does not seem to
affect actual Spring Security operation.
We had a pretty strange race condition in our application. When many
requests were incoming at the same time, occasionally the old
unauthenticated Authentication provided to
KeycloakAuthenticationProvider for performing the actual authentication
would stay the current authentication, as returned by
SecurityContextHolder.getContext().getAuthentication(). That resulted
in authenticated users' JavaScript requests occasionally (~1/50 given a
large request volume) returning a 403 because the 'old' token was still
in the context, causing Spring Security to see them as unauthenticated.
This PR resolves this issue by replacing the whole context, as suggested
by a Spring Security contributor in jzheaux/spring-security-oauth2-resource-server#48. By default,
SecurityContextHolder keeps the actual context object in a ThreadLocal,
which should be safe from race-conditions. The actual Authentication
object, however, is kept in a mere field, hence the reason for this PR.
JIRA issue: https://issues.jboss.org/browse/KEYCLOAK-9539
* PreAuthActionsFilter registers deployment during authentication attempt to enable, well,
node registration if filter is used by itself (if no securityConstraints when using spring boot and spring security)
* deregistering node during clean shutdown
* added unit test
