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