We now use authenticationSession instead of clientSession to reflect
the renaming of ClientSessionModel to AuthenticationSessionModel.
Note that this is a breaking change which needs to be mentioned in
the upgrade notes!
Added support for user friendly email addresses as well as dedicated
reply-to addresses for emails being sent by Keycloak.
Both can be customized via the email settings per realm in
the admin-console.
User friendly email addresses use the format:
"Friendly Name"<email@example.org> and provide way to add a meaning
full name to an e-mail address.
We also allow to specify an optional envelope from bounce address.
If a mail sent to a user could not be delivered the email-provider
will sent a notification to that address.
See: https://en.wikipedia.org/wiki/Bounce_address
Add test for proper email headers in sent messages
Previously the ClientRoleMapper and RealmRoleMapper returned
roles as a comma delimited String in OIDC tokens which
needed to be parsed by client applications.
We now support to generate the role information as JSON
arrays by setting "multi valued" to "true" in the
client role mapper or realm role mappers respectively
which makes it easier for clients to consume.
The default setting for "multi valued" is "false" to
remain backwards compatible.
An example AccessToken that shows the two modes can be found here:
https://gist.github.com/thomasdarimont/dff0cd691cd6e0b5e33c2eb4c76ae5e8
Previously the ScriptBasedAuthenticator did not expose the current
clientSession from the AuthenticationFlowContext.
In order to implement client specific authentications with javascript
one needs information about the current client.
Previously ScriptAuthenticator required a user to be authenticated
before it could be used as an additional authentication step which
limited the scenarios the authenticator could be used.
We now allow ScriptAuthenticators to be used without requiring an
user to be authenticated before.
Adapted the authenticator-template.js with a null safe username check.
Note that existing custom ScriptAuthenticators might need some additional
null checks since the user can now be undefined.
Moved methods `transformUserInfoToken`, `transformAccessToken`,
`transformIDToken` to the `AbstractOIDCProtocolMapper` base class
in order to reduce code duplication.
Previously every mapper implemented at least one or two of those
methods with exactly the same code.
Having those methods in the base class ensures that the code is the
same for all mappers. Since the mentioned methods are declared
on the `OIDCIDTokenMapper`, `OIDCAccessTokenMapper` and `UserInfoTokenMapper`
interfaces `AbstractOIDCProtocolMapper` implementations can now choose
how they should be handled by the `TokenManager`
by implementing the desired set of interfaces `*TokenMapper`-interfaces.
I think this provides a good balance between ease of use, reduced code duplication
and ensured backwards compatiblity.
Existing protocol mapper implementations will still work since they just implement
their own logic for `transformUserInfoToken`, `transformAccessToken`,
`transformIDToken`.
The "claim" information provided by a `ProtocolMapper` to a `*Token` can now
be provided by overriding the `AbstractOIDCProtocolMapper.setClaim` method.
Adapted all eligible ProtocolMapper implementations within the
`org.keycloak.protocol.oidc.mappers` package accordingly.
The dependency on commons-io through the use of IOUtils in
ScriptBasedAuthenticatorFactory resulted in
NoClassDefFoundError org/apache/commons/io/IOUtils when building the
keycloak-distribution.
We now use the StreamUtil from keycloak-common to avoid this dependency.
Refactored the scripting infrastructure and added documentation.
Added tests and an authenticator template in JavaScript for a quickstart.
Increased height of ace code editor to 600px to avoid scrolling.
Wasn't used within the Keycloak codebase and wouldn't have worked either
since the OperationType lookup would always fail since there are no
"_ERROR" operation types.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
Previously the service account roles remain visible when changing
the client type from confidential to public or bearer only.
We now only show the service account roles tab iif:
- service accounts are enabled
- client access type is set to confidential
Liquibase Moved schema evolution configuration from jpa-changelog-2.1.0
to jpa-changelog-2.2.0.
Corrected wrong ResourceType references in tests.
Adapted AdminEvents copy-routines to be aware of resourceType attribute.
Added ResourceType enum to exposed ENUMS of ServerInfoAdminResource.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
Introduced new ResourceType enum for AdminEvents which lists
the current supported ResourceTypes for which AdminEvents
can be fired.
Previously it was difficult for custom EventListeners to figure
out which ResourceType triggered an AdminEvent in order
to handle it appropriately, effectively forcing users to parse
the representation.
Having dedicated resource types as a marker on an AdminEvent helps
to ease custom EventListener code.
We now also allow filtering of admin events by ResourceType in the
admin-console.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
We now use the {{authUrl}} prefix for the OIDC configuration link
in the admin-console to honor different web-context paths.
Previously when a different web-context than /auth was configured
the generated link pointed to the wrong location.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
We now allow configuration of path patterns which should not
be handled by the `KeycloakOIDCFilter` than can be specified via
the new init-parameter `keycloak.config.skipPattern` of
the `KeycloakOIDCFilter`.
Patterns are matched against the requestURI without the context-path.
A request for `/myapp/index.html` would be matched with `/index.html`
against the skip pattern.
This allows for for more flexible path handling when using the
`KeycloakOIDCFilter` in combination with existing applications.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
This adds support for using Jetty together with the Keycloak
spring-boot-adapter. Sadly the KeycloakSpringBootProperties.SecurityCollection
definition is mostly inspired by Tomcats SecurityConstraint/SecurityCollection
which doesn't provide a good fit for jettys structures.
In cases where jetty only allows one setting, we use the first value.
We only initialize KeycloakJettyServerCustomizer if jetty is used, same
applies for tomcat.
Revised configuration and extracted serverCustomizer code into
dedicated classes.
Prepared infrastructure for Undertow support.
Client mappers can now be configured to be limited to the
userinfo endpoint. This allows to keep access-tokens lean
while providing extended user information on demand via the
userinfo endpoint.
More sensible default for number of users shown per page in
the user listing of the admin console.
This is also recommended in the patternfly guidelines.
Prior to the PR only 5 users were shown per page.
Introduced two new client protocol mappers to propagate assigned user client / realm roles to a JWT ID/Access Token.
Each protocol mapper supports to use a prefix string that is prepended to each role name.
The client role protocol mapper can specify from which client the roles should be considered.
Composite Roles are resolved recursively.
Background:
Some OpenID Connect integrations like mod_auth_openidc don't support analyzing deeply nested or encoded structures.
In those scenarios it is helpful to be able to define custom client protocol mappers that allow to propagate a users's roles as a flat structure
(e.g. comma separated list) as a top-level (ID/Access) Token attribute that can easily be matched with a regex.
In order to differentiate between client specific roles and realm roles it is possible to configure
both separately to be able to use the same role names with different contexts rendered as separate token attributes.
We now include the full group representation in AdminEvents
for Group Membership changes.
This enables EventListener to propagate potential role / attribute
chnages based on the removal / addition of the group.
Due to the removal of the realm-displayname as a result of changes made for KEYCLOAK-2410
the otpauth URI no longer included the realm display name as a hint for the user to which system an
authenticator belongs to.
We now ensure that the realm display name is again part of the label component of the otpauth URI.
This enables a user to better distinguish between user accounts for different systems.
We now handle ModelExceptions thrown while creating and updating
a new User by rolling back the transaction and presenting
an error message with a HTTP 409 (conflict) code.
Previously only ModelDuplicateExceptions were handled and
ModelExceptions, e.g. due to a failed database operation
lead to a HTTP 500 server error.
This is a POC for script based authenticator support.
Introduced a ScriptBasedAuthenticator that is bootstraped via a
ScriptBasedAuthenticatorFactory can be execute a configured script
against a provided execution context.
Added an alias property to the AuthFlowExecutionRepresentation in order
to be able to differentiate multiple instances of an Authenticator
within the same AuthFlow.
For convenience editing the AngularJS bindings for the ACE editor were
added for fancy script editing - this needs to be cut down a bit wrt to
themes and supported scripts - e.g. we probably don't expect users to write
authenticator scripts in Cobol...
Removed currently not needed ACE sytax highlighting and themes.
Scripting is now available to all keycloak components that have access to the KeycloakSession.
Introduced new Scripting SPI for configurable scripting providers.
Previously the adapter configuration did not support specifying a proxy
for auth-server requests issued via the Apache HTTP Client by Keycloak.
This made it very difficult to connect an Application with Keycloak
that was required to use a proxy.
Introduced new `proxy-url` attribute to the adapter configuration
which makes it possible to configure a proxy to be used for auth-server
requests. Proxy-Host, Proxy-Port and Proxy-Scheme are taken from the
configured proxy URL.
Note that proxies that require authentication are currently not supported.
Since the `Map` returned by `realm.getBrowserSecurityHeaders()` is unmodifiable
we need to add the new header setting to a copy of the map which we then set
on the realm.
Previously one had to configure hardcoded urls to link from one client
application to others since keycloak didn't provide a way to get the
actual client URL by providing clientId and realm information.
We now support a new endpoint with the path {realm}/clients/{client_id}/redirect
that responds to GET requests with a 307 (temporary redirect) with the
configured client URL. This allows to refer to any client just by the
realmName and clientId and let Keycloak redirect to the actual client
application.
Add documentation for new redirect endpoint.
We now propagate the generated internal id to the given IdentityProvider instance.
Previously if one creates a new IdentityProvider in a Realm with activated admin event listeners,
then a admin event is created that contains a resourcePath that ends with /null instead of /some-uuid.
We now allow specify a role to skip OTP.
Previously it was not possible to specify that OTP authentication should be skipped via a role but the
ConditionalOtpAuthenticator allowed to specify to show/skip OTP via a user attribute or HTTP request header pattern.
Having the "skip role" aligns the role based configuration options with the user attribute and HTTP request header configuration.
Previously it was not possible to conditionally show a OTP authentication
form. This PR adds support to conditionally require OTP authentication
based on a custom user attribute, a role, a request header pattern
(with black- and whitelisting) as well as a configurable default in
case no condition matches.
We now iterate over custom-user attributes in a deterministic way such that new attributes don't lead
to a complete reordering of the properties in the custom user attributes listings.
Previously the order of custom attributes in the user attributes listings was not deterministic which lead
to cases where keys that shared a common prefix where not placed at arbitrary positions.
Introduced a custom angularjs flter "toOrderedMapSortedByKey" that helps to deterministically iterate
over object properites.
UserFederationProvidersResource is now aware of ConfiguredProvider and allows sophisticated
configuration of configuration properties via ProviderConfigProperty definitions.
See DummyUserFederationProviderFactory. getConfigProperties() for example.
Previously UserFederationProvidersResource did only support simple key-value pairs for expressing
configurable options.
Tested this by launching a standalone KeycloakServer and creating a new Dummy UserFederationProvider.
The default values, labels and help messages are correctly displayed and the values are stored correctly.
Previously navigating to the group members tab of a group breaks other groups links (RoleMappings, Attributes etc.) because the groupId part of the url is missing.
One sees:
/auth/admin/master/console/#/realms/master/groups//role-mappings
Instead of:
/auth/admin/master/console/#/realms/master/groups/0f77aeed-7d16-4938-9fcc-c74b1125e5e0/role-mappings
We now explicitly order the AuthenticatorFlows, AuthenticatorConfig, as well
as RequiredActions to ensure a consistent order for the configuration export to make
it easier to diff / version keycloak configuration files.
Previously the order of the json properties of an configuration export were
non deterministic. The configuration file could look partially different after a
export, import, export sequence even if no changes were made.
When using the `org.keycloak.adapters.servlet.KeycloakOIDCFilter` a `NullPointerException`
can be thrown in the `org.keycloak.adapters.servlet.FilterSessionStore` within the `getParam`
method of the generated wrapper in `buildWrapper` when the `content-type` is not set.
Since the `content-type` is only used to parse the body. We just check whether the `body`
is `null` and if so avoid touching the `content-type` which prevents the NPE.
If the `body` is null we return an empty `MultivaluedHashMap` for the parameters.
Introduced description field with support for i18n for more descriptive client information.
Applications can use the description to display a "slightly" longer gist of
what the client / application is about, especially useful for tooltips.
The description is currently limited to 255 characters.
Added input form that allows to specify the OTP token period
in the `OTP Policy` section of the `Authentication` settings.
Since the value is already backed by the provided `otpPolicyPeriod`
field in the `RealmRepresentation` class we only needed to show the value
in the admin ui.
Thomas Darimont