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.
- removing hardcoded `jackson.version` from performance testsuite pom
- moving `jackson.annotations.version` from performance testsuite pom to the root pom
Previously firstname and lastname were derived from the name claim.
We now use direct mappings to extract firstname and lastname from
given_name and family_name claims.
Added test to KcOidcFirstBrokerLoginTest
Marked org.keycloak.broker.provider.BrokeredIdentityContext#setName
as deprecated to avoid breaking existing integrations.
- Removed duplicate servlet configuration: the HttpServlet30Dispatcher servlet is already configured by server.undertowDeployment(deployment, "");
- Disabled the HTML escaping in the ResteasyDeployment
This PR disables the Resteasy HTML Sanitizer in KeycloakServer.
Previously KeycloakTest server erroneously escapes html in error pages.
See the linked JIRA issue for details.
when attribute value is always read from LDAP and import is enabled
When userattribute value is always read from LDAP, then the value is not
available in the local store. Therfore, KC will not find a user by that
attribute in the local store. When querying the LDAP storage
provider, the user will be found. However, when it is also available in
the local store (though without the attribute) it will not get imported
and therefore not returned with the result set of the LDAP storage
provider. Hence, the user will not be found at all.
This change adds the user to the result set of the LDAP user stoage
provider, iff the attribute user by the search is set to always read
value from LDAP.
