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
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.
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.
If GroupLDAPStorageMapper is running under IMPORT mode, getGroupMembers should not return users in LDAP, which, according to how UserStorageManager.query works (getting both user federation and Keycloak storage), will cause duplicate users in the list.
A test has been added as well, which will fail before the fix in the mapper.
This reverts commit e018ca3e29 from:
Simplifying logic for determining disabled status (#6416)
Co-authored-by: brunomedeiros-visagio <55057005+brunomedeiros-visagio@users.noreply.github.com>
of LDAP groups from federation provider to Keycloak, perform the search if the
currently processed group already exists in Keycloak in log(N) time
Signed-off-by: Jan Lieskovsky <jlieskov@redhat.com>
(in the direction from LDAP provider to Keycloak) from exponential to
linear time in the case of syncing flat LDAP groups structure
Add a corresponding test (intentionally configured as to be ignored
by CI/CD due to higher demand on time, required fo the test completion)
Signed-off-by: Jan Lieskovsky <jlieskov@redhat.com>
Allows to use the full PEM encoded X.509 certificate from client cert
authentication as a user identity. Also allows to validate that user's
identity against LDAP in PEM (String and binary format). In addition,
a new custom attribute mapper allows to validate against LDAP when
certificate is stored in DER format (binay, Octet-String).
KEYCLOAK-10158 Allow lookup of certs in binary adn DER format from LDAP
This commit sends the STARTTLS on LDAP 389 connections is specified.
STARTTLS doesn't work with connection pooling so connection pooling will
be disabled should TLS be enabled.
Use CommonLDAPGroupMapperConfig.getMembershipLdapAttribute() instead of
constant LDAPConstants.MEMBER to honor the "membership.ldap.attribute"
config key when creating a LDAP group. This fixes an error when trying
to create a group on a DS server configured with a different member
attribute than the standard "member" (eg. 389ds).
