- replace non-cryptographic PRNG usage (java.util.Random, Math.random)
- use SecureRandom in JwtCNonceHandler for nonce length generation
- use SecureRandom in TimeClaimNormalizer for time claim randomization
- introduce centralized secure random utility (SecretGenerator)
- ensure uniform and unpredictable randomness in security-sensitive flows
Closes#47271
Signed-off-by: Awambeng Rodrick <awambengrodrick@gmail.com>
Address review comments from @IngridPuppet
Signed-off-by: Awambeng Rodrick <awambengrodrick@gmail.com>
Pre-compute the full effective role set once in
ClientRoleMappingsResource.getCompositeClientRoleMappings() using
RoleUtils.getDeepRoleMappings(), then filter by client. This replaces
the previous O(C*M*D) approach of calling user.hasRole() for every
client role, which recursively expanded composites without memoization.
RoleUtils.getDeepRoleMappings(RoleMapperModel) is introduced to handle
both RoleMapperModel implementations correctly: UserModel includes
group-inherited roles (matching UserModel.hasRole() semantics), while
GroupModel expands only its direct composite mappings.
The CompositeClientRoleMappingsTest is migrated from the deprecated
Arquillian framework to the new Keycloak test framework (JUnit 5).
Signed-off-by: Alexey Skosyrskiy <askosyrskiy@metropolis.io>
Pre-compute user's effective roles via RoleUtils.expandCompositeRoles()
(BFS) instead of calling user.hasRole() per client role which
recursively expands composites without memoization.
Closes#47157
Signed-off-by: Alexey Skosyrskiy <askosyrskiy@metropolis.io>
I added getResourcesCommonUrl() following the same URL/Path pattern already used by getResourcesUrl() and getResourcesPath(). Email clients can't resolve relative paths so the existing getResourcesCommonPath() wasn't enough for email templates.
I also pulled out the common-path lookup into a private getCommonPath() helper to avoid duplicating it between getResourcesCommonPath() and the new method. Updated the theme docs with a usage example and a note about absolute URLs in emails.
Closes#33198
Signed-off-by: Hager Khamis <hagerm98@hotmail.com>
closes: #47139
Signed-off-by: Steve Hawkins <shawkins@redhat.com>
Signed-off-by: Alexander Schwartz <alexander.schwartz@ibm.com>
Co-authored-by: Alexander Schwartz <alexander.schwartz@ibm.com>
ClientSecretRotationContext was passing null for the AdminAuth parameter
to its parent constructor. When a client policy with the
client-updater-context condition is active, the condition evaluates
context.getToken() which delegates to adminAuth.getToken(), causing a
NullPointerException because adminAuth is null.
Pass the AdminAuth instance from the admin endpoint through to the
context constructor, consistent with how AdminClientUpdateContext and
other admin CRUD contexts are constructed elsewhere in ClientResource.
Closes#47063
Signed-off-by: easonysliu <easonysliu@tencent.com>
Closes#47187
Signed-off-by: Pedro Ruivo <1492066+pruivo@users.noreply.github.com>
Signed-off-by: Alexander Schwartz <alexander.schwartz@ibm.com>
Signed-off-by: Pedro Ruivo <pruivo@users.noreply.github.com>
Co-authored-by: Pedro Ruivo <1492066+pruivo@users.noreply.github.com>
Co-authored-by: Alexander Schwartz <alexander.schwartz@ibm.com>
Co-authored-by: Steven Hawkins <shawkins@redhat.com>
Includes some NPE fixes (no client attribute) and refactors handling of verifying authz request resource param matching token request resource param.
Closes#47180
Signed-off-by: stianst <stianst@gmail.com>
Closes#46164
Signed-off-by: Peter Skopek <peter.skopek@ibm.com>
Update model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/changes/remote/updater/loginfailures/LoginFailuresUpdater.java
Co-authored-by: Pedro Ruivo <pruivo@users.noreply.github.com>
Signed-off-by: Peter Skopek <peter.skopek@ibm.com>
Add recovery codes to the list of brute force checked authenticators.
Closes#46164
Signed-off-by: Peter Skopek <peter.skopek@ibm.com>
* Allow exposing WellKnown providers via ServerMetadataResource (#46292)
Add new availableViaServerMetadata default method to WellKnownProviderFactory to control the availability of via '/.well-known/<alias>'.
Defaults to false, order to keep the behavior as before.
Also update the existing provider factories to let they decide if they need to be exposed on the root .well-known or not.
Fixes#46292
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Resolve WellKnownProviderFactory by alias and update provider logic
Introduce `WellKnownProviderUtil.resolveFromAlias(..)` to centralize alias-based factory resolution with priority ordering. Adjust `ServerMetadataResource` and `RealmsResource` to use the new method, replacing direct alias resolution logic. Streamline handling of aliases for consistent provider behavior.
Fixes#46292
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Rename methods in `ServerMetadataResource` for consistency
Align method names with streamlined naming conventions by replacing `getOAuth2AuthorizationServerWellKnownVersionPreflight` with `getWellKnownPreflight` and `getOAuth2AuthorizationServerWellKnown` with `getWellKnown`.
Fixes#46292
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Add test to verify `.well-known/openid-configuration` is not exposed via server metadata root by default.
Ensures an HTTP 404 response when the configuration is accessed with incorrect settings.
Fixes#46292
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Use more idiomatic nullcheck in ServerMetadataResource isValidProvider
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Format ServerMetadataResource
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Added wellKnownProviderUrl method to ServerMetadataResource
We could also have non-oauth well-known providers.
Marked the old wellKnownOAuthProviderUrl as deprecated.
Changed current call-sites to use wellKnownProviderUrl.
Fixes#46292
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
* Optimize lookup in WellKnownProviderUtil.resolveFromAlias(..)
Fixes#46494
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
---------
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
