* 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.