- 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>
* KEYCLOAK-12870 - Allow to pick arbitrary user for IdP linking
* KEYCLOAK-12870: always allow to choose user if password reset is called from first broker login flow
* KEYCLOAK-12870: remove "already authenticated as different user" check and message
* KEYCLOAK-12870: translations
* KEYCLOAK-12870: fix tests
The '+' in the allowed CORS origins does not replicate a '*' wildcard
from the Valid Redirect URIs. This information is now available in the
tooltip.
Also translated changed message into german.
In french, the "forgot password" email displays the full link instead of having a message like other languages.
`Lien pour réinitialiser votre mot de passe` = `Link to reset your password`.
* KEYCLOAK-6618 Update German translations
Add missing translations for OTP authenticator settings and update
outdated translations for OTP authenticator
Fix minor issue for the username property (plural -> singular)
Add missing translations
* KEYCLOAK-6618: Include review feedback into German translations
* KEYCLOAK-6618: Reword translation for multi-factor authentication and fix minor translation issues
* KEYCLOAK-6618: Update German translation for the login theme
Message bundle keys have been reordered to be in sync with the english
version to improve scanning through the message bundles side-by-side.
The updated German translations from the account theme were applied to
the login theme as well (where applicable).
* KEYCLOAK-5244 Add BlacklistPasswordPolicyProvider
This introduces a new PasswordPolicy which can refer to
a named predefined password-blacklist to avoid users
choosing too easy to guess passwords.
The BlacklistPasswordPolicyProvider supports built-in as
well as custom blacklists.
built-in blacklists use the form `default/filename`
and custom ones `custom/filename`, where filename
is the name of the found blacklist-filename.
I'd propose to use some of the freely available password blacklists
from the [SecLists](https://github.com/danielmiessler/SecLists/tree/master/Passwords) project.
For testing purposes one can download the password blacklist
```
wget -O 10_million_password_list_top_1000000.txt https://github.com/danielmiessler/SecLists/blob/master/Passwords/10_million_password_list_top_1000000.txt?raw=true
```
to /data/keycloak/blacklists/
Custom password policies can be configured with the SPI
configuration mechanism via jboss-cli:
```
/subsystem=keycloak-server/spi=password-policy:add()
/subsystem=keycloak-server/spi=password-policy/provider=passwordBlacklist:add(enabled=true)
/subsystem=keycloak-server/spi=password-policy/provider=passwordBlacklist:write-attribute(name=properties.blacklistsFolderUri, value=file:///data/keycloak/blacklists/)
```
Password blacklist is stored in a TreeSet.
* KEYCLOAK-5244 Encode PasswordBlacklist as a BloomFilter
We now use a dynamically sized BloomFilter with a
false positive probability of 1% as a backing store
for PasswordBlacklists.
BloomFilter implementation is provided by google-guava
which is available in wildfly.
Password blacklist files are now resolved against
the ${jboss.server.data.dir}/password-blacklists.
This can be overridden via system property, or SPI config.
See JavaDoc of BlacklistPasswordPolicyProviderFactory for details.
Revised implementation to be more extensible, e.g. it could be
possible to use other stores like databases etc.
Moved FileSystem specific methods to FileBasesPasswordBlacklistPolicy.
The PasswordBlacklistProvider uses the guava version 20.0
shipped with wildfly. Unfortunately the arquillian testsuite
transitively depends on guava 23.0 via the selenium-3.5.1
dependency. Hence we need to use version 23.0 for tests but 20.0
for the policy provider to avoid NoClassDefFoundErrors in the
server-dist.
Configure password blacklist folder for tests
* KEYCLOAK-5244 Configure jboss.server.data.dir for test servers
* KEYCLOAK-5244 Translate blacklisted message in base/login
This PR adds:
* an endpoint to Role that lists users with the Role
* a tab "Users in Role" in Admin console Role page
* it is applicable to Realm and Client Roles
* Extends UserQueryProvider with default methods (throwing Runtime Exception if not overriden)
* Testing in base testsuite and Console
