The following instructions guide you through upgrading from WSO2 Identity Server 5.3.0 to WSO2 Identity Server 5.4.0. In this topic, <OLD_IS_HOME> is the directory that Identity Server 5.3.0 resides in and <NEW_IS_HOME> is the directory that Identity Server 5.4.0 resides in.

Before you begin

This release is a WUM-only release. This means that there are no manual patches. Any further fixes or latest updates for this release can be updated through the WSO2 Update Manager (WUM).

If you are upgrading to this version to use this version in your production environment, use the WSO2 Update Manager and get the latest available updates for WSO2 IS 5.4.0. For more information on how to do this, see Updating WSO2 Products.

Migrating the embedded LDAP user store

It is not generally recommended to use the embedded LDAP user store that is shipped with WSO2 Identity Server in production setups. However, if migration of the embedded LDAP is required, follow the instructions below to migrate the existing IS 5.3.0 LDAP user store to IS 5.4.0.

Copy any custom OSGI bundles that were added manually from the <OLD_IS_HOME>/repository/components/dropins folder and paste it in the <NEW_IS_HOME>/repository/components/dropins folder.

Copy any added JAR files from the <OLD_IS_HOME>/repository/components/lib folder and paste it in the <NEW_IS_HOME>/repository/components/lib folder.

Copy the .jks files from the <OLD_IS_HOME>/repository/resources/security folder and paste them in <NEW_IS_HOME>/repository/resources/security folder.

If you have created tenants in the previous WSO2 Identity Server version and if there are any resources in the <OLD_IS_HOME>/repository/tenants directory, copy the content to the <NEW_IS_HOME>/repository/tenants directory.

If you have created secondary user stores in the previous WSO2 IS version, copy the content in the <OLD_IS_HOME>/repository/deployment/server/userstores directory to the <NEW_IS_HOME>/repository/deployment/server/userstores directory.

You have done many custom changes in your previous version of WSO2 IS.

These custom changes have not been tracked completely and/or are difficult to redo.

Steps:

Make a copy of the <OLD_IS_HOME>/repository/conf folder. (Do not change the original configs. You may use it as a backup in case there are any issues)

Copy the following configuration files from the <NEW_IS_HOME> and paste it in the copy of the <OLD_IS_HOME> in the relevant path.

<IS_HOME>/repository/conf/identity/charon-config.xml

<IS_HOME>/repository/conf/scim2-schema-extension.config

The two configuration files mentioned above were added in IS 5.4.0 for the SCIM 2.0 connector. For more information about the SCIM 2.0 connector, see Configuring SCIM 2.0 Provisioning Connector in the ISConnectors documentation.

The table below lists out all the configuration changes from IS 5.3.0 to IS 5.4.0. You can scroll through the table and change the relevant configurations according to the features you are using.

Tip: Scroll left/right to view the entire table below.

Note: The configuration changes listed below will not affect the existing system because these configurations are applied only at first start up and new tenant creation. If you wish to change the configurations for the existing tenants, configure it through the management console user interface.

In a production environment, there is a possibility for a deadlock/database lock to occur when running a session data cleanup task in high load scenarios. To mitigate this, the property given above was introduced to clean data in chunks. Configure this property with the required chunk size. For more information, see Deployment Guidelines in Production.

Remove the following property found within the <OperationDataCleanUp> tag.

<CleanUpPeriod>720</CleanUpPeriod>

Click for more information about the CleanUpPeriod property

WSO2 IS 5.3.0 had two separate tasks for session data cleanup and operation data cleanup. This is now combined and done through one task. Therefore the property given above is no longer needed. You can still configure the <CleanUpPeriod> property within the <SessionDataCleanUp> tag to specify the cleanup period for the combined task.

Change the default value of the following property from 300 to 0.

You can skip this step if you have already configured the <TimestampSkew> property with your own value.

<TimestampSkew>0</TimestampSkew>

Click for more information about the TimestampSkew property

The property given above specifies the maximum tolerance limit for the clock skewed between the sender and recipient. The default value was changed to 0 as the best practice is to assume that the sender and recipient clocks are synchronized and are in the same time stamp. Configure this accordingly if the clocks are not in the same timestamp.

Add the following JWT bearer grant type within the <SupportedGrantTypes> tag.

If you have already configured all the properties within the <CacheManager> tag with your own values, skip this step.

If you have only configured some properties within the <CacheManager> tag with your own values, replace the properties that are not been changed/configured with the relevant default values shown below.

If you have not configured or changed any of the properties within the <CacheManager> tag with your own values, copy the entire code block below and replace the <CacheManager> tag in the identity.xml file with the code block given below.

Add the following properties within the <OAuth> tag. The code comments explain the usage and applicable values for the properties.

<!-- Specify the Token issuer class to be used.
Default: org.wso2.carbon.identity.oauth2.token.OauthTokenIssuerImpl.
Applicable values: org.wso2.carbon.identity.oauth2.token.JWTTokenIssuer-->
<!--<IdentityOAuthTokenGenerator>org.wso2.carbon.identity.oauth2.token.JWTTokenIssuer</IdentityOAuthTokenGenerator>-->
<!-- This configuration is used to specify the access token value generator.
Default: org.apache.oltu.oauth2.as.issuer.UUIDValueGenerator
Applicable values: org.apache.oltu.oauth2.as.issuer.UUIDValueGenerator,
org.apache.oltu.oauth2.as.issuer.MD5Generator,
org.wso2.carbon.identity.oauth.tokenvaluegenerator.SHA256Generator -->
<!--<AccessTokenValueGenerator>org.wso2.carbon.identity.oauth.tokenvaluegenerator.SHA256Generator</AccessTokenValueGenerator>-->
<!-- This configuration is used to specify whether the Service Provider tenant domain should be used when generating
access token.Otherwise user domain will be used.Currently this value is only supported by the JWTTokenIssuer. -->
<!--<UseSPTenantDomain>True</UseSPTenantDomain>-->

Add the following properties related to token persistence within the <OAuth> tag.

<!-- True, if access token alias is stored in the database instead of access token.
Eg.token alias and token is same when
default AccessTokenValueGenerator is used.
When JWTTokenIssuer is used, jti is used as the token alias
Default: true.
Applicable values: true, false-->
<!--<PersistAccessTokenAlias>false</PersistAccessTokenAlias>-->

Replace the <OAuth2DCREPUrl> property with the property value given below.

Add the following commented property to the file. You can place it after the </EnableAssertions>closing tag.

<!-- This should be true if subject identifier in the token validation response needs to adhere to the
following SP configuration.
- Use tenant domain in local subject identifier. - Use user store domain in local subject identifier.
if the value is false, subject identifier will be set as the fully qualified username.
Default value: false
Supported versions: IS 5.4.0 beta onwards-->
<!--<BuildSubjectIdentifierFromSPConfig>true</BuildSubjectIdentifierFromSPConfig>-->

Uncomment the <UserType> property that has the value "Federated" and comment out the <UserType> property that has the value "Local" as seen below. The property can be found within the <SAML2Grant> tag.

<SAML2Grant>
<!--SAML2TokenHandler></SAML2TokenHandler-->
<!-- UserType conifg decides whether the SAML assertion carrying user is local user or a federated user.
Only Local Users can access claims from local userstore. LEGACY users will have to have tenant domain appended username.
They will not be able to access claims from local userstore. To get claims by mapping users with exact same username from local
userstore (for non LOCAL scenarios) use mapFederatedUsersToLocal config -->
<!--<UserType>LOCAL</UserType>-->
<UserType>FEDERATED</UserType>
<!--UserType>LEGACY</UserType-->
</SAML2Grant>

Add the following properties to the file. You can place the code block after the </SCIM> closing tag.

<SCIM2>
<!--Default value for UserEPUrl and GroupEPUrl are built in following format
https://<HostName>:<MgtTrpProxyPort except 443>/<ProxyContextPath>/<context>/<path>
If that doesn't satisfy uncomment the following config and explicitly configure the value-->
<!--UserEPUrl>${carbon.protocol}://${carbon.host}:${carbon.management.port}/scim2/Users</UserEPUrl-->
<!--GroupEPUrl>${carbon.protocol}://${carbon.host}:${carbon.management.port}/scim2/Groups</GroupEPUrl-->
</SCIM2>

Add the following properties to the file. You can place it after the </EnableAskPasswordAdminUI> closing tag.

Replace "https://localhost:9443" in all instances of the accountrecoveryendpoint URL with the {{carbon.product-url}} placeholder. The URL should look similiar to the URL shown in the code block below. The placeholder will retrieve the value configured in the carbon.xml file.

You can skip this step if you have already configured this with your load balancer URL.

WSO2 IS 5.4.0 introduces a set of new XACML policies that load at server startup when the PAP.Policy.Add.Start.Enable property is set to true. Therefore, when you upgrade to IS 5.4.0, follow one of the steps below depending on whether you want to add the new policies:

If you want to add the new policies on server startup, set both PDP.Balana.Config.Enable and PAP.Policy.Add.Start.Enable properties to true.

If you do not want to add the new policies on server startup, set both PDP.Balana.Config.Enable and PAP.Policy.Add.Start.Enable properties to false.

Note

If you set the PDP.Balana.Config.Enable property to false, while the PAP.Policy.Add.Start.Enable property is set to true, the server does not look for the balana-config.xml file on startup. This results in an error as follows because the balana-config.xml file includes functions required by the new XACML policies:

As this property will only apply at first startup of the server or for new tenant creations, switch off the account disabling feature via the management console as well. For more information on how to do this, see Account Disabling.