This release focuses on introduction of the following new features and improvements:
Mobile Connect is a global identity service provided by GSMA which enables mobile users to share sensitive information through their mobile phone number in, for example authentication use cases. Ubisecure has enabled possibilities for Mobile Operators to pilot Mobile Connect since November 2015. With this latest release we have extended the support related to Mobile Connect Authentication and Authentication Plus which will facilitate Mobile Operators to take Mobile Connect into commercial use. In order to use Mobile Connect authentication method for your application, you will need to integrate with a Mobile Connect service provider - contact a Mobile Connect Operator in your country.
There are several of improvements made to SSO's handling of scopes and logs when using OpenID Connect. This to enable Administrators to specify which information is needed for certain applications and log the information in the audit logs for processing and forwarding to GSMA for billing purposes. Authorisation policies have been updated to specify which scopes should be evaluated when accessing a specific OAuth 2.0 application. This will make sure that no additional information is shared with the application that is outside of the specified scopes. This will also enable additional benefits to the consent page that has been improved in this release.
Ubisecure Identity Server has had the possibility for a long time to include a consent page after login that informs the end user on what information will be forwarded to the application that is being accessed. Within this release we have improved the consent page for OAuth 2.0 applications to be much more dynamic and user-friendly compared to the previous static page.
Administrators are now able to specify which scopes that should be shown to the user when accessing the OAuth 2.0 application using OpenID Connect as well as localise the different scopes to more user-friendly names. For other applications and methods a static consent page will be shown for the users.
Related to these changes, additional language keys have been added and one has been changed in uas.properties. The previous 'CONFIRM' language key is now used as confirmation of consent and the new language key for confirming new password in login_expiring and login_expired pages is 'NEW_PASSWORD_CONFIRM' as can be seen from Internationalization - SSO documentation.
There are also changes to the so called "passive consent screen" that existed before. If an application is configured with "consentrequired=true" there needs to be an active confirmation of the consent, in the case of "prompt=none", the request return an access_denied from the requested application.
Corrections and improvements
This release also includes corrections and improvements in the code as well as our documentation. You will find improvements made to our developer portal pages, such as the System Recommendations and Supported Platforms with information of the browsers and operating systems we support, software requirements related to java and databases as well as hardware recommendation for running operational environments. We have also added more information to the Security considerations for production environments - SSO on how to ensure that no system specific information is leaked to end users in an error situation.
For CustomerID there are a couple of corrections related to the user experience when displaying search results.
Improvements have been made for both application to use consistent versioning of the applications. This will make it easier to see in the logs and SSO Management UI which version is currently installed. The version deployed to Tomcat and Wildfly will be the same as the one specified in the installation package (i.e. for this release you will see: sso-8.5.0-unix.tar.gz / customerid-5.5.0-linux.tar.gz).
Additionally, you will find a listing of known issues, with internal ticket references at the bottom of this page.
Reminder: Please note that since IDS 2018.1 release Java Runtime Environment (JRE) is no longer included in the distribution package. Both CustomerID and SSO can utilise the same Java installation See Documentation
What does this mean for our customers?
- Excluding Java from the installation media reduces the size and allows use of existing installations
- Faster customer environment Java upgrades independent of the Ubisecure release cycle
- IDS-2869 - An improvement has been made for CustomerID when used with User Driven Federation (UDF) during registration. SSN is checked during UDF authorization step in registration to verify that there is not already a user with same SSN in the system. Previously the user was able to proceed to the registration and register another user with same SSN (which could not be used)
- IDS-2309 - Encrypted organizational attributes are now shown in human-readable format for user approval step in the Administrator UI. Earlier these attributes were shown in encrypted format for the Administrator
- IDS-2257 - Error handling has been fixed when attempting to create a new organization, but with a case, such as "New Organization" vs "new organization". Previously this returned a stack trace in the Administrator UI. This has also been resolved in REST API 1.0, 2.0 and 2.1 to return error 409 in these cases
- IDS-2170 -
general.unsecure.debuglog.include.rest.passwordconfiguration key is removed due to its insecure nature of making queried passwords logged in the debug log file
- IDS-2579 - REST API 1.0 (REQ001b) List Users now takes into account maxResults above 127 in AD LDS setup. Previously value above 127 returned all users (or maximum page size of 1000 users)
(CustomerID 5.5.1 was omitted from public release due to a severe issue found and fixed during final release testing)
- IDS-2616 - Language keys in messages_xx.properties have been change to be case-insensitive to help Administrators with localisation
- IDS-2446 - Updating email address for a user through the Administrator GUI now updates all required fields in the database. One field was previously not updated and caused issues with new registrations for previously registered email addresses
- IDS-2528 - Emptying custom attribute field through API 2.0 (MOD04) now also empties the LDAP field. This field was previously left populated while the SQL field was emptied
- IDS-2650 - Duplicate language keys in messages_en.properties have been removed. With this fix, there was a change to the role removal confirmation language key "general.ui.actions.removerole" that has been replaced with "general.ui.confirm.removerole". Changes between versions can be found from Configuration changes in versions - CustomerID
- IDS-2640 - Emptying custom attribute field mapped to SSN through API 2.0 (MOD04) now also empties the LDAP field. This was previously left populated while the SQL field was emptied
- IDS-2225 - Improved version handling of CustomerID components in order to have a better understanding of which version is currently installed. Deployment of correct (i.e. same as the release version) versioned components are shown in the logs
- IDS-2304 - CustomerID again shows the full path of the organisation in the organisation search results in Administration view, this previously only showed the organisation friendly name
- IDS-2330 - CustomerID roles for main and sub-organisations are again shown in different tables if configured to search for roles in sub-organisations as well (ui.organization.roles.recursive = true)
- IDS-2719 - ubixmlsec library has been updated to version 18.104.22.168494 to support http://www.w3.org/2009/xmlenc11#aes128-gcm encryption algorithm that will be taken into use by Suomi.fi service in the near future
- IDS-1303 - Mobile Connect integration has been extended with support related to logging and consent. This enables Mobile Operators to take Mobile Connect Authentication and Authentication Plus product into commercial use. The items that have been updated for this feature can be found in the improvements section.
- IDS-2516 - OAuth 2.0 applications can be extended with compatibility flag ExtendedOAuth2AuditLogging. This enables additional log entries to the audit log to facilitate Mobile Connect billing use cases. This can also be use for other OpenID Connect use cases. More detailed information can be found from Additional audit logging for OAuth 2.0
- IDS-1304 - Authorisation policies have been updated with scope field. This will allow Administrators to specify which scopes should be evaluated for OpenID Connect and OAuth 2.0 applications. You can read more about how to Manage authorization policies - SSO here
- IDS-2522 - Improved consent page includes requested scopes and confirm/cancel buttons instead of previous static text and checkbox. This improvement can be used for OpenID Connect methods and OAuth 2.0 applications. For other applications and methods, an updated static page of consent information will be shown to the end user. Read more about how to configure the consent screen from our Login screens - SSO and Internationalization - SSO documentation pages.
- IDS-1591 - Mobile ID (Mobiilivarmenne) phone number input field has been changed from 'text' to 'tel' to improve the user experience on mobile devices. Users default screen will show number keypad rather than alphabet keyboard, easing use of the service
- IDS-2486 - Optimisation of LDAP search in Password Reset application related to lookup of available methods
- IDS-2014 - Additional information for the different entry types has been added to our Audit log description - SSO
- IDS-2034 - Improved documentation how to setup authentication methods using SSO Management API can be found from OpenID Connect authentication method - SSO
- IDS-750 - Improved documentation related to handling of error situation not to expose any sensitive server or software information. Read more about how to use reverse proxy in our Security considerations for production environments - SSO
- IDS-1487 - Improved version handling of SSO components in order to have a better understanding of which version is currently installed. Logging of correct version (i.e. same as the release version) during SSO startup
- IDS-2445 - Improvement to how threads are handled for Health check API. In clustered environments it was noticed that the health check calls could go into a deadlock due to timing issue when connection was shutting down
- IDS-2615 - OAuth2 / OpenID Connect Token responses have been changed to exclude the id_token for refresh requests. This is to make sure that no additional information is shared with the application that the user has not approved to be shared. Read more about Access Token and ID Token from Authorization code grant and web single sign-on - SSO
- IDS-2608 - Updated audit log field "Web Application User ID" to get username sent to the application in the log entries that have this field available. More information can be found from Audit log description - SSO
- IDS-2158 - Version number in the footer of SSO Management UI now correctly displays the installed version of the application
- IDS-2317 - UsernameUserMappingIdentityFactory flag has been set to disabled as default as specified in SSO 8.4.1 release notes. If this functionality needs to be enabled follow the Enabling UsernameUserMappingIdentityFactory instructions
- IDS-2032 - Changing log levels in SSO management UI will now come into affect without restarting SSO application, this would previously require a restart
- IDS-1182 & IDS-1469 - Documentation has been updated related to how to configure your reverse proxy in order not to expose any sensitive server or software information. Read more about how to use reverse proxy in our Security considerations for production environments - SSO page
- IDS-2537 - Correction to jQuery call that broke WS-Federation logout in 8.4.0 and 8.4.1. If using WS-Federation methods, we suggest to upgrade to SSO 8.5.0 to resolve this issue
|IDS-561||There is a known issue where SSO does not check the mappingURL value when creating or editing an inboundDirectoryMappings when using the SSO REST API. Directory Mappings are possible to be created, but then not opened or edited.|
|IDS-608||There is a known UI/UX issue where a very large site list is displayed within the SSO management UI. This results in hard to use UI if large lists of sites are present in the SSO deployment. A possible workaround is to use an ldap editor to configure the authorization policies and groups.|
|IDS-941||There is a known issue where unregistered SMTP OTP authentication will not permit TLS or any secure authentication. Documentation improvement will be made to ensure proper configuration is shown if unsecure SMTP servers are required.|
|IDS-1030||There is a known issue where running the CertAP setup.cmd in a windows environment will post errors of missing linux tags. While these errors are unsightly, they can be safely ignored. This issue will be corrected in a future release.|
|IDS-1039||There is a known issue where a user account will ask for a sixth OTP verification after five consecutive failed OTP verifications have occurred. The five consecutive failures results in a locked account, the user should be informed that they must wait for the OTP timeout to expire before they attempt to login again.|
|IDS-1127||There are known documentation issues within OpenLDAP clustering with SSO.|
|IDS-1171||There is a known issue when using OpenLDAP 2.4.44 when performing SSO session cleanup which will cause replication issues.|
|IDS-1499||There is a known issue where SSO will return http 401, rather than http 400 when token introspection without an authentication header or when invalid credentials are present.|
|IDS-1511||There is a known issue with the tokens used to reset your password. If a user requests multiple password reset tokens, the old ones are not invalidated, however they are not refreshed and will become invalid after expiration time.|
|IDS-1525||There is a known issue where SSO logs will contain a stopped search warning entry when tomcat is shutdown. This error can be safely ignored. |
|IDS-1526||There is a known issue where SSO logs will contain a unstopped thread warning entry when tomcat is shutdown. This error can be safely ignored.|
|IDS-1832||There is a known issue where editing an existing authorisation policy (example case added an attribute) resulted in the alteration of ubiloginNameValue. This affects SSO 8.3.0 and later. There is no work around at this time.|
|IDS-1893||There is a known issue if you use OpenID authentication, a user cannot access SAML or Ubilogin web applications. Work around use any other non-OpenID authentication method. If OpenID is required, then use OAuth 2.0 application.|
|IDS-1995||When using BankID and Safari, during initial login Safari displays a 0kb file being downloaded when there is no downloaded file|
|IDS-2059||There is a known issue where the authorisation endpoint may become corrupted if a URL contains "%b" in URL encoded format.|
|IDS-2089||There is a known issue where shutting down Ubisecure Accounting service on a windows server will show errors within the ids-accounting.log.|
|IDS-2090||There is a known issue where the SSO management UI will not filter results correctly if the filter expression is short, contains incorrect filter expressions and there are Scandinavian characters included.|
|IDS-2092||There is a known issue where the tomcat log will show a severe servlet warning for com.ubisecure.ss-ui. However, this warning is due to a user repeating the same action (double clicking an item or using the back button). This warning can be safely ignored and will be addressed in a future release.|
|IDS-2094||There is a known issue where disabling the main account in the SSO login directory does not disable the User Driven Federation accounts. Users are still able to login to services with the Federated account even while the main account is disabled. Work around: Administrators who are disabling a main login directory account should ensure that they check and disable any associated UDF accounts at the same time. This issue will be addressed in a future release.|
There is a known issue where attempting to use exceptionally long SAML Entity IDs will result in creation failure (larger than 64 characters) . There is no known work around and may not be possible to resolve due to LDAP field limitations. We will address this in a future release.
|IDS-2120||There is a known issue where dual node SSO will require jndi.properties to be manually configured on the second node during SSO upgrade.|
|IDS-2121||There is a known issue where dual node SSO will require settings.sh to be manually configured on the second node during SSO upgrade.|
|IDS-2226||There is a known issue with using escape characters like '=' for a Site that causes the SSO management UI to be unable to map applications to the site. Workaround is to make sure not to use any Escape values for Site names (https://ldapwiki.com/wiki/DN%20Escape%20Values).|
|IDS-2247||There is a known issue with OTP_LOGIN_REMAINING_PASSWORD_AMOUNT configuration that prevents SSO from showing warning message to the end-user when OTP list is running out. Currently there is no workaround known.|
There is a known installation issue when using SSO Password reset. Using the installation instructions for password reset tool requires an administrator to run tomcat update. This occasionally results in an empty context.xml file being created which causes SSO to fail when being restarted. Workaround, repeat the run tomcat update step which will create a correct .xml file and SSO will restart.
|IDS-2314||There is a known issue with passing a refresh token to token endpoint results in "invalid_grant" error, if the refresh token has been issued to an unregistered user from an authentication method having a connected Directory Service.|
|IDS-2315||There is a known issue that SSO returns refresh token for un-registered users. This should not be done since there is no way of handling the lifecycle of the un-registered user's refresh token.|
|IDS-2332||There is a known issue when using OpenLDAP in SSO where slapd runs out of connections to process incoming requests.|
|IDS-2478||There is a known issue in SSO that it is not possible to have different localisations for access_denied returned by IdP and local access_denied, for example if directory user mapping fails after successful authentication|
|IDS-2498||There is a known issue with policy.password.history configuration. While setting this configuration for password.2 it does not have any effect on the history check of previous passwords used.|
There is a known issue with user approvals from Users view. If there are required attributes for the approval step, these are not validated if approval is done through the Users view.
|IDS-1332||There is a known issue with CustomerID where it is not possible to use one email account for multiple UIDs created in CustomerID. Work around: It is possible for the system administrator to use custom attributes holding the same email address in the second or third CustomerID UID.|
|IDS-1358||There is a known issue within CustomerID where an administrator applying permissions across a whole organization will result in a failure of CustomerID to initialise. Work around: Admins should ensure that they do not apply permissions to an entire organisation, but apply the permission to a specific organisation class. All classes within an organisation may have the permission added, but not to the whole organisation at the same time, during the same commit.|
|IDS-1365||There is a known UI improvement for lists of Users and Roles for CustomerID administrators. Currently the lists are not ajax based, which means that cannot be called via popup, unlike other lists seen in CustomerID Admin UI. While this does not cause an error, it is not ideal from a usage point of view.|
|IDS-1373||There is a known issue in CustomerID when a new user is created in a non-virtual organisation, the invitation can contain a role when no role has been approved for that user.|
|IDS-1380||There is a known issue with CustomerID organisational attributes where the UI validation (validation.json) is not utilised. This impacts MOD001, POST100, PUT101 and MOD003. Using the API calls will result in good responses, but no organisational attribute change will be made.|
|IDS-1382||There is a known issue within CustomerID mandates where no email is sent to the user or organisation when the configuration is set to false ( mandate.receiver.approval = false), even though the administrator requests a mail to be sent. No error or warning screen is displayed.|
|IDS-1389||There is a known usage limit in CustomerID Mandates. When viewing a mandate, currently only the role is shown. It would be more user friendly to show both the role and its organisation within the mandate view. There is no workaround.|
|IDS-1411||There is a known issue within the CustomerID XML schema ID, if an administrator makes an error and reuses and existing variable ID, this second use of the variable ID will not be assigned but the organisation will still be created. No error is reported. This can cause troubleshooting and usage errors. Workaround: Administrators should ensure that variable IDs are unique prior to creating new variable IDs within the system installation.|
|IDS-1413||There is a known error in CustomerID mandates if the mandate name is longer than 61 characters. If longer than 61 characters, creating the mandate will fail. Workaround: Do not create mandate names longer than 61 characters.|
|IDS-1418||There is a known issue with CustomerID REST API MOD008. If an administrator removes a single mandate role from a user with multiple mandate role, the original (removed) mandate template still exists within the LDAP database. This can result in troubleshooting errors and database checking errors (backup, etc).|
There is a known issue with CustomerID REST API MOD021 when creating a new user. Even when the API call appears to work, the user is not added to the organisation. Workaround: Do not use REST MOD021 (modification) during the of a new account. Please ensure you use create APIs when making new users.
|IDS-1446||There is a known issue when using CustomerID REST API MOD009 to create a new user. The API will return 200 OK even when the new user password is not set; this results in a failed account creation. Workaround: Do not use REST API MOD009 (modification) to create a new user account. Please ensure you use create APIs when making new users.|
|IDS-1463||There is a known issue when using the CustomerID lost password recovery wizard where the wildfly server will log an exception in the error log. The password reset works correctly for the end user, but the resulting log file is cumbersome for large deployments where end users often reset their passwords. The error exceptions can be safely ignored, these will be corrected in a future release.|
|IDS-1468||There is a known issue caused by an Administrator altering the name of an Organisation when a new user has registered but not yet been approved. An application error occurs and is logged. Workaround: To avoid this only change an organization name when the pending user view is empty.|
|IDS-1474||There is a known issue that results in unsaved organisational custom attributes occurring when approval is set to false; attributes are saved when they should not be.|
|IDS-1476||There is a known issue within User DrivenFederation (UDF) of a social login during registration. If a user attempts to register more than one social login (UDF) against an external account a warning error message is presents. Resolution will be to provide the user a message explaining that they have already UDF'd a social account to this internal account and it is not possible to register a second social account.|
|IDS-1478||There is a known issue that results in a null pointer exception with stack trace if a user attempts Self Service User Driven Registration (UDF) of a social login account when UDF is not enabled within the CustomerID service.|
|IDS-1494||There is a known issue that causes occasional error pages to be displayed when a user logs out of their federated (User Driven Federation, UDF) social login account.|
|IDS-1500||There is a known issue where an error condition is caused if a user creates a password with 3 or more characters of their first or last name. Password verification does not permit this, and an error is raised.|
|IDS-1504||This known issue is a regression. When a user is invited to multiple roles, only one role appears in the invitation screen. This impacts both CustomerID Admin UI and user Self-Service.|
|IDS-1509||There is a known issue where a new user being invited to a virtual organisation the CustomerID administrator cannot approve the user; an internal server error occurs.|
|IDS-1555||There is a known issue where the mandate tab cannot be accessed on the CustomerID UI if the localisation information is incomplete. Workaround is to ensure that all localisation fields are completed.|
|IDS-1681||There is a known issue where the cursor focus remains in the mobile text field after a user has selected the email confirmation, when both email and mobile confirmations are required.|
|IDS-1706||There is a known issue with null values (DbAssignable.set and DbAssignable.isNull) which may result in NullPointer exceptions when using REST calls. This impacts Roles, Mandates and Invitations.|
|IDS-2033||Search response when using the CustomerID authoriser rule will return duplicate entries if capitalisation is present in the searched term or in the database field. In the future, no duplicates will be returned even if capitals are used or present in the naming field. Example: friendlyName and friendlyname.|
|IDS-2091||There is a known issue that the "New Organization" field in the "Open user applications" approval tab sometimes shows incorrect status|
|IDS-2093||There is a known issue that listing of users doesn't take into considerations users that are in locked status|
|IDS-2162||There is a known issue in CustomerID within Mandates, where no renotify email is sent to the administrator when an existing user requests a mandate for an existing additional organisation. No email is sent to Administrators for approval and no errors are logged. There is no workaround for this issue.|
|IDS-2201||There is a known issue in CustomerID where an email to a user with a single expiring or expired role will have all open roll invitations listed in the email, not just the expiring or expired role invitation.|
|IDS-2207||There is a known issue in CustomerID where interrupting the creation of a pending user will reset localisation of the browser session.|
|IDS-2231||There is a known issue when Administrator denies a role request for a user, that user gets two emails sent to them. One stating "Role invitation denied" and a second one stating "Role denied".|
|IDS-2233||There is a known issue in CustomerID API 1.2 REST call MOD025 "Create Role Invitation" related to email notification. If this REST call is used, the inviter mail address configured does not get a notification when the end-user approves the received role. The notification still works if role invitations are done through the GUI.|
|IDS-2234||There is a known issue where a user who has been invited to a role but not registered for that role within the defined time limit does not receive a reminder email that they have been invited to a role. See also: IDS-2235 below.|
|IDS-2235||There is a known issue where a user who has been invited to a role but not registered for that role within the defined time limit is not informed that the role invitation has expired. The user will have an email invitation with URL that does not function, they may become confused as they are not informed that the invitation has expired. See also: IDS-2234 above.|
|IDS-2290||There is an issue opening approval tab under main organization branch if there are around 10 000 sub-organizations. As a workaround, you can choose not to use recursive selection by adding "admin.approvals.recursive.selection.default = false" to you eidm2.properties file. See also: IDS-2310 below.|
|IDS-2310||There is an issue searching roles under main organization branch if there are around 10 000 sub-organizations. As a workaround, you can choose not to use recursive roles by adding "ui.organization.roles.recursive = false" to you eidm2.properties file. See also: IDS-2290 above.|
|IDS-2311||There is a known issue in approval view where changing main organization for a pending user in a sub-organization fails to create the new sub-organization in LDAP. This will need to manually be resolved by removing the invalid sub-organization in SQL|
|IDS-2312||There is a known issue in approval view where changing technical name of an organization to include Scandinavian letters doesn't work.|
|IDS-2420||There is a known issue in registration when pressing Enter without filling in all required fields causes registration to get cancelled instead of highlighting the required fields needed to complete the registration. Identified in CID 5.3.5|
|IDS-2588||There is a known issue in the Java EL expression available in SSO Authentication policy. Trying to access the CustomerID user attributes does not work and might return invalid information|
Considerations and limitations
SameSite cookie changes in Google Chrome
In Google Chrome version 80 and above, the default behaviour of cookies that are used in cross-domain use cases have changed. If your applications or services are communicating between different top-level domains you need to take the following actions as described in our SameSite cookies changes technical announcement to ensure that they continue to operate as before.
Long Certificates Require Manual Installation in Linux Version
When a certificate is set in suffix.pfx, whose base64 encoded string is longer than about 4000 characters, the installation of SSO ends in a failure. This is due to an issue with an OpenLDAP tool ldapmodify, which is unable to read lines longer than 4096 characters long and the installation script writes the base64 encoded certificate in one line in secrets.ldif. To address this issue, a tool ldiffold.sh was included with SSO 7.1.0 linux version, which wraps given ldif file so that it no longer contains lines that are too long. It can be run as follows:
Ubilogin Ticket Protocol Attribute Size Limits
The Ubilogin Ticket Protocol uses the HTTP GET method to send authentication and authorization information from UAS to Web Agents. The HTTP GET method has a size limit. The size limit affects the amount of information it is possible to successfully send from UAS to Web Agents. The SAML 2.0 protocol resolves this size limit by using the HTTP POST method to send information from UAS to Web Agents.
Ubilogin SAML Service Providers use SAML 2.0 protocol.
Ubisecure SSO, SAML 2.0 and High Availability
When installing Ubisecure SSO in High Availability mode, there are some restrictions due to some protocol requirements when using SAML 2.0. Please refer to the Ubisecure Clustering document for more information.
Backwards compatibility issues
Swedish BankID Authentication Adapter
As of Ubisecure SSO 8.4.1, the Swedish BankID Mobile authentication adapter has to be configured using the JWKS key id (kid) exposed in the SSO JWKS metadata. See Installing and configuring Swedish BankID - SSO for more details.