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
Sometimes the error message is blank, which results in an empty error line getting logged.
Since the catch always logs "failed to turn code into token" and "status from server: " + failure.getStatus() (on separate lines) this extra blank line is simply noise in the log.
Fix debug message that does not properly handle single quotes
according to java.text.MessageFormat, which in turn causes the
replacement to not be handled.
Signed-off-by: Phil Brown <brownp@stellarscience.com>
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.
Users who want to use PKCE support with the KeycloakInstalled adapter need to set the property
``"enable-pkce": true` in the adapter configuration / `keycloak.json`.
This adds support for the "S256" code_challenge_method to the JS Adapter.
Note that the method "plain" was deliberately left out as is not recommended
to be used in new applications.
Note that this PR includes two libraries:
- [base64-js]{@link https://github.com/beatgammit/base64-js}
- [js-sha256]{@link https://github.com/emn178/js-sha256}
`base64-js` is needed for cross-browser support for decoding the
Uint8ArrayBuffer returned by `crypto.getRandomValues` to a PKCE
compatible base64 string.
`js-sha256` library is required because the `crypto.subtle.digest`
support is not available for all browsers.
The PKCE codeVerifier is stored in the callbackStore of the JS Adapter.
Note: This PR is based on #5255 which got messed up during a rebase.
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
The root cause is that NodesRegistrationManagement.tryRegister can be
called from multiple threads on the same node, so it can require
registration of the same node multiple times. Hence once it turns to
tasks that invoke sendRegistrationEvent (called sequentially), the same
check has been added to that method to prevent multiple invocations on
server side, or invocation upon undeployment/termination.
* 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
As KEYCLOAK-6585 concerns only hybrid flow, this commit restores the behavior for implicit flow.
This commit partially reverts #5041 (061049e41a6b0e6fb45c75f05748023ad7ab7d92).
In commit d70859ef keycloak-pax-web-jetty94 was added.
org.keycloak:keycloak-jetty94-adapter:jar is a dependency of this module, and
isn't produced outside of the community profile. So, the jetty94 module here
must be consistent with that.
This commit can only be merged once the Camel 2.21.2 would be
released, otherwise the code won't compile due to missing dependencies.
See https://issues.apache.org/jira/browse/CAMEL-12514 for details.
KEYCLOAK-2606 Added cordova native
KEYCLOAK-2606 Some more fixes and tweaks
Fix redirect in example realm
feature(cordova-native): fix universalLinks and kc options
Added 'cordova-native' to typings
Added an option to define a "default" redirectUri in keycloak.js
Added 'login' and 'logout' event to universalLinks configuration in config.xml
Improved 'cordova-native' example to always use a redirectUri and
update state after successfull logout
Setting the 'authenticated' flag for the keycloak instance to 'false'
after a logout redirect
KEYCLOAK-2606: Simplify example for cordova-native
I wanted to make it explicit which options are actually needed, so I didn't want to reuse the keycloak conf
KEYCLOAK-2606: simplify example
The update state after logout shouldn't be necessary as it is set in `keycloak.onAuthLogout = updateState;`
Not sure why it is called after the login promise...
Fixes
This commit contains a POC for the issue "Roles get lost after security context was propagated back to wildfly-swarm, if using jwt for authentication" (KEYCLOAK-7309).
