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>
* Allow exposing some initial provider config options via web site
Co-authored-by: Stian Thorgersen <stian@redhat.com>
Closes#10571
* Include type to provider options, and hide build-icon column as it's not relevant
Co-authored-by: stianst <stianst@gmail.com>
Always show the consent screen when a dynamic scope is requested and show the requested parameter
Improve the code that handles dynamic scopes consent and add some log traces
Add a test to check how we show dynamic scope in the consent screen and added missing template file change
Fix merge problem in comment and improve other comments
Fix the Dynamic Scope test by assigning it to the client as optional instead of default
Change how dynamic scopes are represented in the consent screen and adapt test
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
Users can now be searched by custom attributes using 'q' in the query parameters. The implementation is roughly the same as search clients by custom attributes.
Use of boxed types as started in 009d4ca445 is finalized here
to enable storing data in a map. MapClientEntity methods are
reordered for the sake of grouping the collection-based
properties together and understanding the connections between those.
- fix RealmAdapter to create a new map instead of trying to change unmodifiable map
- only provide POST endpoints for creating or updating the texts (to have the endpoints consistent with other Admin API endpoints)
- add tests
- extend RoleMapperModel with method hasDirectRole(RoleModel), which only checks for direct assignment in contrast to the existing method hasRole(RoleModel)
- extend ScopeContainerModel with method hasDirectScope(RoleModel), which only checks for direct scope mapping in contrast to the existing method hasScope(RoleModel)
- use the new hasDirectRole and hasDirectScope methods to check whether a role is in the "available" list and whether it can be assigned (previously, the hasRole method was used for this purpose)
- add hint to UI that available roles contain effectively assigned roles which are not directly assigned
- adjust and extend tests
* There are errors in the deprecation notes in the javadoc where the new methods are referred.
* Some places where getCredentialData() and getSecretData() have been referred to should actually refer to getPasswordCredentialData() and getPassowordSecretData() respectively for PasswordCredentialModel.
* Similarly, for OTPCredentialModel, getOTPCredentialData() anad getOTPSecretData() should be referred.
