What Has Changed¶
WSO2 Identity Server 5.9.0 brings a range of new features and major improvements. In IS 5.9.0, the following aspects have been changed compared to the previous IS versions.
Changes to Resource Access Control¶
WSO2 Identity Server maintains a set of resources that requires user authentication.
In previous versions, if a resource is not mentioned in the configuration, it was
allowed to be accessed without user authentication. In WSO2 Identity Server 5.9.0,
the configuration is changed to deny any request to a resource that is not
mentioned in the configuration. In addition, the resources which do not require any
user authentication, has to be explicitly mentioned in the
deployment.toml
file in the <IS_HOME>/repository/conf/
directory.
Resource definition order
The order in which the resource are defined is important for permission that are defined for resources under
ResourceAccessControl
. The entries at the top get precedence over the entries at the bottom.
As all new resources and permissions are added to the top, they get precedence over the already defined
resources/permissions. A new resource can be added to the resource access control using the following config.
You can add the config to the deployment.toml
file in the <IS_HOME>/repository/conf/
directory.
[[resource.access_control]]
context="<resource>"
secure="<true/false>"
http_method="<method>"
permissions=["<permission>"]
NOTE
To revert back to the previous behaviour, add the following configuration to
the deployment.toml
file in the <IS_HOME>/repository/conf/
directory.
[resource_access_control]
default_access = "allow"
Log printing¶
WSO2 Identity Server has a log printing mechanism. With WSO2 Identity Server 5.9.0, a correlation Id is added to all the places where the logs are printed.
Correlation Id
The correlation Id is used to correlate the method calls made for a request. The correlation Id is printed after the timestamp.
[2019-09-10 20:36:09,181] [16667e80-6470-425b-b63a-253f096c7e69] INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin@wso2.com [1]' logged in at [2019-09-10 20:36:09,180+0530]
NOTE
To get the previous format in error logs, change the the log4j2.properties
file in the
<IS-Home>/repository/conf
directory as shown below.
New Format | Old Format |
---|---|
appender.CARBON_CONSOLE.layout.pattern = [%d] [%X{Correlation-ID}] %5p {%c} - %m%ex%n |
appender.CARBON_CONSOLE.layout.pattern = [%d] %5p {%c} - %m%ex%n |
appender.CARBON_LOGFILE.layout.pattern = TID: [%tenantId] [%appName] [%d] [%X{Correlation-ID}] %5p {%c} - %m%ex%n |
appender.CARBON_LOGFILE.layout.pattern = TID: [%tenantId] [%appName] [%d] %5p {%c} - %m%ex%n |
appender.AUDIT_LOGFILE.layout.pattern = TID: [%tenantId] [%d] [%X{Correlation-ID}] %5p {%c} - %m%ex%n |
appender.AUDIT_LOGFILE.layout.pattern = TID: [%tenantId] [%d] %5p {%c} - %m%ex%n |
Storing the username in consent management¶
WSO2 Identity Server supports obtaining user consent at user authentication. Consent management in previous Identity Server versions, enforced case-sensitive usernames. But, Identity Server 5.9.0 supports case-insensitive usernames by default.
NOTE
If you are using a case-sensitive
username configuration, add the following configuration to the deployment.toml
in file in
<IS_HOME>/repository/conf/
directory.
[user_store]
use_case_sensitive_username_for_cache_keys = true
Changes to the OIDC discovery response¶
WSO2 Identity Server has an OpendID discovery service that can be called by using
the https://{server-ip}/oauth2/oidcdiscovery/.well-known/openid-configuration
endpoint.
In previous versions, the response values of the request_parameter_supported
and claims_parameter_supported
properties were as follows.
"request_parameter_supported": "true",
"claims_parameter_supported": "true",
In WSO2 Identity Server 5.9.0 the values for above properties have been changed to boolean
instead of string
.
"request_parameter_supported": true,
"claims_parameter_supported": true,
Redirecting to callbackUrl in OAuth flow errors¶
In previous Identity Server versions, when an error occurs while using the OAuth 2.0 flow, the
user was redirected to an error page at the authenticationendpoint/oauth2_error.do
URL. According to the
specification, unless the provided redirect URI
and client Id
are invalid, the user should be redirected
to the provided redirect URI.
For WSO2 Identity Server 5.9.0 to be specification-compliant, unless the provided redirect URI
or
client Id
are invalid, the user will be redirected to the given redirect URI with the error
, error_description
,
and state
parameters set to the query component of the redirection URI.
NOTE
To achieve the previous behaviour, add the following configuration to the deployment.toml
in
<IS_HOME>/repository/conf/
directory.
[oauth]
redirect_to_idp_error_page_on_error=true
Redirecting to PostLogoutUri in user consent denial for OIDC logout¶
When a user rejects the OIDC logout consent, in earlier versions of the WSO2 Identity Server the user was redirected to
the oauth2_error.do
page with “access_denied - End User denied the logout request” error message. Custom
parameters such as “oauthErrorCode” and “oauthErrorMsg” were used to explain the issue to the user.
In WSO2 Identity Server 5.9.0, the user will be redirected to postLogoutUri
with the parameters error
and
error_description
which are defined in the OIDC specification.
NOTE
To achieve previous behaviour, add the following configuration to the deployment.toml
in
<IS_HOME>/repository/ conf/
directory.
[oauth.oidc]
redirect_to_post_logout_uri_on_consent_denial = false
Scope validation for token issuing¶
WSO2 Identity Server supports scope validation when issuing tokens for OAuth Service Providers.
In previous Identity Server versions, this capability was not available when issuing tokens for Authorization Code and Implicit grant types. Identity Server 5.9.0 supports these by default when using a scope validator.
NOTE
To achieve the previous behaviour, add the following configuration to
the deployment.toml
in <IS_HOME>/repository/conf/
directory.
[oauth.scope_validator.authz_implicit]
enable = false
Authentication Endpoint and Account Recovery Endpoint¶
In earlier versions of the WSO2 Identity Server the authenticationendpoint
and the
accountrecoveryendpoint
was packed in as war
files in the <IS_HOME>/repository/
deployment/server/webapps/
directory. In WSO2 Identity Server 5.9.0 the exploded war files are packed.
Log4j upgrade¶
WSO2 Identity Server 5.9.0 has switched from log4j to log4j2. You will notice that there is a
log4j2.properties
file in the <IS_HOME>/repository/conf/
directory instead of the
log4j.properties
file.
Warning
Taking the log4j.properties
file from your old WSO2 Identity Server and adding it to WSO2 Identity
Server 5.9.0 will no longer work.
Refer Migrating to log4j2 to see how to add a log appender or a
logger to the log4j2.properties
file.
Migrating to JDK 11
If you are migrating to JDK 11, you need to change the signature of the adaptive authentication script method since the improvements done for the Nashorn Engine to support ES6 in JDK 9 made the following method signature unsupported.
Unsupported method signature
function getAge(birthDate) {
...
}
Supported method signature
var getAge = function (birthDate) {
...
};
Handling Role-based or XACML-based Scope Validation for Implicit and Authorization Code Grants¶
Scope validation has been enforced for authorization code grant and implicit grants.
NOTE
If you have implemented any apps that work without scope validation and you wish to disable the behaviour, add the
following configuration to the deployment.toml
file
[oauth]
scope_validator.authz_implicit.enable = false
Multi factor Authentication using FIDO¶
From IS 5.9.0 onwards, WebAuthn API is being used instead of U2F API. If you have used FIDO previously, your devices must be re-enrolled.
Warning
If you choose to keep using the previous behavior which based on U2F API you need to use an old version of chrome where U2F API was supported so you can enroll new devices and you will also miss the new FIDO features which introduced in IS 5.9.0 like FIDO REST API
NOTE
To achieve the previous behaviour, add the following configuration to the deployment.toml
in
<IS_HOME>/repository/conf/
directory.
[fido.webauthn]
enable = false