- 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
Previously, Keycloak did only support syncing groups from LDAP federation provider as top-level KC groups.
This approach has some limitations:
- If using multiple group mappers then there’s no way to isolate the KC groups synched by each group mapper.
- If the option "Drop non-existing groups during sync” is activated then all KC groups (including the manually created ones) are deleted.
- There’s no way to inherit roles from a parent KC group.
This patch introduces support to specify a prefix for the resulting group path, which effectively serves as a namespace for a group.
A path prefix can be specified via the newly introduced `Groups Path` config option on the mapper. This groups path defaults to `/` for top-level groups.
This also enables to have multiple `group-ldap-mapper`'s which can manage groups within their own namespace.
An `group-ldap-mapper` with a `Group Path` configured as `/Applications/App1` will only manage groups under that path. Other groups, either manually created or managed by other `group-ldap-mapper` are not affected.
* KEYCLOAK-12958 Preview feature profile for WebAuthn
* KEYCLOAK-12958 Ability to enable features having EnvironmentDependent providers without restart server
* KEYCLOAK-12958 WebAuthn profile product/project
Co-authored-by: Marek Posolda <mposolda@gmail.com>
We now consider intermediate Locales when performing a Locale based
ResourceBundle lookup, before using an Locale.ENGLISH fallback.
Co-authored-by: stianst <stianst@gmail.com>
- 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