- 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
- Introduces Datastore SPI for isolating data store methods
- Introduces implementation of the datastore for legacy storage
- Updates DefaultKeycloakSession to leverage Datastore SPI instead
of direct creating of area providers by the session
- 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).
- 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
