Parse scopes to RAR representation and validate them against the requested scopes in the AuthorizationEndpointChecker
Parse scopes as RAR representation and add the created context on the different cache models in order to store the state and make it available for mappers in the ClientSessionContext
Create a new AuthorizationRequestSpi to provide different implementations for either dynamic scopes or RAR requests parsing
Move the AuthorizationRequest objects to server-spi
Add the AuthorizationRequestContext property to the MapAuthenticationSessionEntity and configure MapAuthenticationSessionAdapter to access it
Remove the AuthorizationRequestContext object from the cache adapters and entities and instead recalculate the RAR representations from scopes every time
Refactor the way we parse dynamic scopes and put everything behind the DYNAMIC_SCOPES feature flag
Added a login test and added a function to get the requested client scopes, including the dynamic one, behind a feature flag
Add a new filter to the Access Token dynamic scopes to avoid adding scopes that are not permitted for a user
Add tests around Dynamic Scopes: replaying existing tests while enabling the DYNAMIC_SCOPES feature and adding a few more
Test how the server genereates the AuthorizationDetails object
Fix formatting, move classes to better packages and fix parent test class by making it Abstract
Match Dynamic scopes to Optional scopes only and fix tests
Avoid running these tests on remote auth servers
Previously lookups for embedded theme-resources did not work for Keycloak.X because of a missing
`ClasspathThemeResourceProvider` registration.
This PR ensures that a `ClasspathThemeResourceProvider` is registered in Keycloak.X based deployments.
Added empty constructors to ClasspathThemeResourceProvider to enable dynamic instantiation by Quarkus.
Fixes#9653
Currently, the CodeQL scanner has been analyzing the whole
codebase,including folders like testsuite, or examples. Those folders
are not relevant from the security standpoint, considering that they do
not expose our users and customers to any risks. They are only relevant
in the context of our pipelines, but never used in production.
Closes#9631
- makes it the default provider when no provider is explicitly configured
- avoid NPE at server startup when other providers are present and none is set as default
