- 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
* KEYCLOAK-16076 added new warining when cookies are disabled
Co-authored-by: David Hellwig <david.hellwig@bosch.com>
Co-authored-by: Christoph Leistert <christoph.leistert@bosch-si.com>
Problem:
Using fine-grained admin permissions on groups, it is not permitted to create new users
within a group.
Cause:
The POST /{realm}/users API does not check permission for each group part of the new
user representation
Solution:
- Change access logic for POST /{realm}/users to require MANAGE_MEMBERS and
MANAGE_MEMBERSHIP permissions on each of the incoming groups
Tests:
Manual API testing performed:
1. admin user from master realm:
- POST /{realm}/users without groups => HTTP 201 user created
- POST /{realm}/users with groups => HTTP 201 user created
2. user with MANAGE_MEMBERS & MANAGE_MEMBERSHIP permissions on group1
- POST /{realm}/users without groups => HTTP 403 user NOT created
- POST /{realm}/users with group1 => HTTP 201 user created
- POST /{realm}/users with group1 & group2 => HTTP 403 user NOT created
- POST /{realm}/users with group1 & wrong group path => HTTP 400 user NOT created
3. user with MANAGE_MEMBERS permission on group1
- POST /{realm}/users without groups => HTTP 403 user NOT created
- POST /{realm}/users with group1 => HTTP 403 user NOT created
- POST /{realm}/users with group1 & group2 => HTTP 403 user NOT created
- POST /{realm}/users with group1 & wrong group path => HTTP 400 user NOT created
This is based on:
Author: Thomas Sørensen <tvs@flexdanmark.dk>
Date: Thu Sep 13 14:24:43 2018 +0200
Added danish translation. by FuKe · Pull Request #5567https://github.com/keycloak/keycloak/pull/5567
However, I:
* Fixed up a couple of theme.properties merge conflicts compared to
current master
* Fixed some spelling mistakes and added missing entries
* Introduced Danish to list of locales in messages_en.properties
* Squashed it all into a single commit as pr.
https://github.com/keycloak/keycloak/blob/master/CONTRIBUTING.md
- Store in config map in database and model
- Expose the field in the OIDC-IDP
- Write logic for import, force and legacy mode
- Show how mappers can be updated keeping correct legacy mode
- Show how mappers that work correctly don't have to be modified
- Log an error if sync mode is not supported
Fix updateBrokeredUser method for all mappers
- Allow updating of username (UsernameTemplateMapper)
- Delete UserAttributeStatementMapper: mapper isn't even registered
Was actually rejected but never cleaned up: https://github.com/keycloak/keycloak/pull/4513
The mapper won't work as specified and it's not easy to tests here
- Fixup json mapper
- Fix ExternalKeycloakRoleToRoleMapper:
Bug: delete cannot work - just delete it. Don't fix it in legacy mode
Rework mapper tests
- Fix old tests for Identity Broker:
Old tests did not work at all:
They tested that if you take a realm and assign the role,
this role is then assigned to the user in that realm,
which has nothing to do with identity brokering
Simplify logic in OidcClaimToRoleMapperTests
- Add SyncMode tests to most mappers
Added tests for UsernameTemplateMapper
Added tests to all RoleMappers
Add test for json attribute mapper (Github as example)
- Extract common test setup(s)
- Extend admin console tests for sync mode
Signed-off-by: Martin Idel <external.Martin.Idel@bosch.io>
