Releases: TNG/keycloak-mock
v0.18.0
Following a request to make the list of audiences configurable, I have reworked the way audiences and resource-based roles work. Instead of defining a list of resources to apply roles to (via ServerConfig.Builder::withResourceToMapRolesTo
or ServerConfig.Builder::withResourcesToMapRolesTo
), the user can now define a list of default audiences (via ServerConfig.Builder::withDefaultAudience
or ServerConfig.Builder::withDefaultAudiences
). In a new, separate setting ServerConfig.Builder::withLoginRoleMapping
, the user can decide whether the roles given by the login shall be applied to the realm, all audiences (which double as resources), or both. Whenever a resource-based role is added to a token configuration, its resource is now automatically added to the audience of the token.
In addition, the deprecated methods in ServerConfig
were removed.
New features
- the login workflow now supports redirect URLs which contain request parameters or fragments
- the login page now uses CSS and is a lot nicer to look at 😁
- there is a new endpoint
/docs
which documents all endpoints implemented by the mock
Changed behavior
- the built-in keycloak.js script is now back to version 25.0.6, the latest version of Keycloak that still shipped keycloak.js
- the keycloak.js file is now served on the context path even if a non-standard path is configured
v0.17.0
Bugfixes
- the logout endpoint now also supports POST requests (#173)
- requests to realms other than the default one are now supported again when not using the default context path
/auth
- when introducing support for different context paths, one hard-coded usage of
/auth
has been overlooked before
- when introducing support for different context paths, one hard-coded usage of
Removed functionality
- the endpoint
[/auth]/realms/:realm/protocol/openid-connect/delegated
has been removed- this functionality has been dropped in Keycloak with version 16, see keycloak/keycloak#9106
v0.16.0
New features
- it is now possible to set the token lifespan in ServerConfig, TokenConfig or via CLI option (thanks @Akvel for the idea and PR #150 )
- it is now possible to set the scopes of the token via CLI option
Changed behavior
To make it consistent with the rest of the API, default scopes defined in ServerConfig are now no longer appended to those in the TokenConfig. Instead, if scopes are defined in TokenConfig, they replace any default scopes defined in ServerConfig.