Refactoring ThemeSelector and DefaultThemeManager to re-use the same logic for selecting default theme as there used to be two places where one had a broken implementation
Closes#14889
- no longer throw an exception, when a role or group cannot be found, log a warning instead
- update mapper references in case of the following events:
- moving a group
- renaming a group
- renaming a role
- renaming a client's Client ID (may affect role qualifiers)
- in case a role or group is removed, the reference still will not be changed
- extend and refactor integration tests in order to check the new behavior
Closes#11236
Provide startup time in UserSessionProvider independent of Infinispan,
cleanup code that is not necessary for the map storage as it isn't using Clustering.
Move classes to the legacy module.
Closes#12972
- class SingleUserCredentialManager to SingleEntityCredentialManager
- method UserModel.getUserCredentialManager() to credentialManager()
Renaming of API without "get" prefix to make it consistent with other APIs like for example with KeycloakSession
- UserStorageManager now handles authentication for old Kerberos+LDAP style
- new getUserByCredential method in MapUserProvider would eventually do the same.
- Introduction of new AdminRealmResource SPI
- Moving handler of /realm/{realm}/user-storage into model/legacy-service
- session.users() and userStorageManager() moved refers legacy module
IMPORTANT: Broken as UserStorageSyncManager is not yet moved
- Introduces Datastore SPI for isolating data store methods
- Introduces implementation of the datastore for legacy storage
- Updates DefaultKeycloakSession to leverage Datastore SPI instead
of direct creating of area providers by the session
Instead of DEFAULT_OAUTH2_DEVICE_POLLING_INTERVAL, constant for the
lifespan was used to initialize the default polling interval.
This leads to inability to continuously poll the result as the result
stuck in the actionTokens cache for far longer than expected (600
seconds instead of 5 seconds). As a result, only the first request for
the token succeeds if a resource owner already did grant the access. If
that has not happened, any additional polling within 600 seconds would
get rejected with a 'slow_down' response.
This makes hard to write OAuth 2.0 clients using device code
authorization grant flow against multiple IdPs. Microsoft's
implementation of OAuth 2.0 device code grant flow requires 'nudging'
the Authorization Server's token endpoint before it even starts
recognizing the device code. Keycloak mismatch of the polling interval
default makes this flow impossible.
Closes#12327
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
