- 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>
* 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.
* KEYCLOAK-14209 KEYCLOAK-17988 Client policies admin console support. Changing of format of JSON for client policies and profiles. Refactoring based on feedback and remove builtin policies
* KEYCLOAK-16805 Client Policy : Support New Admin REST API (Implementation)
* support tests using auth-server-quarkus
* Configuration changes for ClientPolicyExecutorProvider
* Change VALUE of table REALM_ATTRIBUTES to NCLOB
* add author tag
* incorporate all review comments
Co-authored-by: mposolda <mposolda@gmail.com>
* rename putIfAbsent() to create(), get() to read(), put() to update(), remove() to delete()
* move ConcurrentHashMapStorage to org.keycloak.models.map.storage.chm package
* Add javadoc to MapStorage
- this ensures that providing implementation for the collection-based methods is enough, which preserves
backwards compatibility with older custom implementations.
- alternative interfaces now allow new implementations to focus on the stream variants of the query methods.
- Add parameters idpAlias and idpUserId to the resource /{realm}/users and allow it to be combined with the other search parameters like username, email and so on
- Add attribute "federatedIdentities" to UserEntity to allow joining on this field
- extend integration test "UserTest"
Adds the capacity to add both public and secret algorithm
specific data to a PasswordCredentialModel. The default
way to create the models in maintained to minimize the change
impact for the default hash infrastructure.
Publishes the PasswordCredentialModel constructor to
ease in building such extended credential models.
Bug: SerializedBrokeredIdentityContext was changed to mirror
UserModel changes. However, when creating the user in LDAP,
the username must be provided first (everything else can
be handled via attributes).
Setting an attribute should be possible with a list
containing no elements or a null list
This can happen e.g. when creating users via idps
using a UserAttributeStatementMapper.
Fix this unprotected access in other classes too
- In order to make lastName/firstName/email/username field
configurable in profile
we need to store it as an attribute
- Keep database as is for now (no impact on performance, schema)
- Keep field names and getters and setters (no impact on FTL files)
Fix tests with logic changes
- PolicyEvaluationTest: We need to take new user attributes into account
- UserTest: We need to take into account new user attributes
Potential impact on users:
- When subclassing UserModel, consistency issues may occur since one can
now set e.g. username via setSingleAttribute also
- When using PolicyEvaluations, the number of attributes has changed
- Store in config map in database and model
- Expose the field in the OIDC-IDP
- Write logic for import, force and legacy mode
- Show how mappers can be updated keeping correct legacy mode
- Show how mappers that work correctly don't have to be modified
- Log an error if sync mode is not supported
Fix updateBrokeredUser method for all mappers
- Allow updating of username (UsernameTemplateMapper)
- Delete UserAttributeStatementMapper: mapper isn't even registered
Was actually rejected but never cleaned up: https://github.com/keycloak/keycloak/pull/4513
The mapper won't work as specified and it's not easy to tests here
- Fixup json mapper
- Fix ExternalKeycloakRoleToRoleMapper:
Bug: delete cannot work - just delete it. Don't fix it in legacy mode
Rework mapper tests
- Fix old tests for Identity Broker:
Old tests did not work at all:
They tested that if you take a realm and assign the role,
this role is then assigned to the user in that realm,
which has nothing to do with identity brokering
Simplify logic in OidcClaimToRoleMapperTests
- Add SyncMode tests to most mappers
Added tests for UsernameTemplateMapper
Added tests to all RoleMappers
Add test for json attribute mapper (Github as example)
- Extract common test setup(s)
- Extend admin console tests for sync mode
Signed-off-by: Martin Idel <external.Martin.Idel@bosch.io>
* KEYCLOAK-12469 KEYCLOAK-12185 Add CredentialTypeMetadata. Implement the screen with authentication mechanisms and implement Account REST Credentials API by use the credential type metadata
- Adds the elytron-cs-keystore provider that reads secrets from a keystore-backed elytron credential store
- Introduces an abstract provider and factory that unifies code that is common to the existing implementations
- Introduces a VaultKeyResolver interface to allow the creation of different algorithms to combine the realm
and key names when constructing the vault entry id
- Introduces a keyResolvers property to the existing implementation via superclass that allows for the
configuration of one or more VaultKeyResolvers, creating a fallback mechanism in which different key formats
are tried in the order they were declared when retrieving a secret from the vault
- Adds more tests for the files-plaintext provider using the new key resolvers
- Adds a VaultTestExecutionDecider to skip the elytron-cs-keystore tests when running in Undertow. This is
needed because the new provider is available only as a Wildfly extension
- automatically parses ${vault.<KEY>} expressions to obtain the key that contains the secret in the vault.
- enchances the capabilities of the VaultProvider by offering methods to convert the raw secrets into other types.
* KEYCLOAK-8460 Request Object Signature Verification Other Than RS256
also support client signed signature verification by refactored token
verification mechanism
* KEYCLOAK-8460 Request Object Signature Verification Other Than RS256
incorporate feedbacks and refactor client public key loading mechanism
* KEYCLOAK-8460 Request Object Signature Verification Other Than RS256
unsigned request object not allowed
* KEYCLOAK-8460 Request Object Signature Verification Other Than RS256
revert to re-support "none"
Previously remember-me sessions where tied to the SSO max session
timeout which could lead to unexpected early session timeouts.
We now allow SSO timeouts to be configured separately for sessions
with enabled remember-me. This enables users to opt-in for longer
session timeouts.
SSO session timeouts for remember-me can now be configured in the
tokens tab in the realm admin console. This new configuration is
optional and will tipically host values larger than the regular
max SSO timeouts. If no value is specified for remember-me timeouts
then the regular max SSO timeouts will be used.
Work based on PR https://github.com/keycloak/keycloak/pull/3161 by
Thomas Darimont <thomas.darimont@gmail.com>
