Authentication
INFORMATION
- Kony Identity Provider (“Kony IDP”) is deprecated since release 21.04 and is not being further enhanced or developed.
- Kony IDP software is provided as sample code for internal evaluation and demonstration purposes only, to assist clients with internal development and testing. This is provided on an ‘as-is’ basis only. Temenos does not represent compliance with any customer authentication standards or regulatory requirements. It is not warranted or supported for production use and any use is at client’s own risk.
The Authentication Micro App (AuthenticationMA) is used to authenticate and allow all valid users with active user credentials to sign in to the banking application. The eligibility to sign in to the application depends on the based on the access permissions assigned to the user.
Prerequisites and Dependencies
Prerequisite/Dependency | Details |
---|---|
Required Visualizer Micro App |
|
Required Fabric Micro App |
|
Front Office Enterprise | Not applicable |
Back Office Enterprise |
|
Fabric Engine |
Entitlements |
Authentication Visualizer App
The Visualizer app contains the required forms and associated artifacts bundled together in the Micro App architecture. The Visualizer App contains the following features:
- Authentication
- Sign in
- Forgot user name and password
- Device registration
- Face authentication
- PIN based login
- Fingerprint authentication
- Prelogin Actions
- Locale
- Enroll/Activate personal banking
- Enroll for business banking
- Prelogin accounts preview
This feature is applicable to Web Channel and Mobile Native channels of the digital banking application.
Authentication Fabric App
The Fabric app contains the object services and APIs related to the following functionality:
- Sign in settings (Native)
- Login
- The Fabric app can be deployed on its own.
-
The functionality of the Fabric app is verified using the request/response payloads to ensure that the Fabric app supports standalone in a headless architecture.
RTL Support
The application provides RTL (Right to Left) alignment support for Arabic language for Web Channel and Mobile Native. RTL is a locale-based property which indicates that the text is from Right to Left. The UX elements in the application are designed to enable the formatting of the Arabic content in an RTL layout. Refer to ISO language codes for more information on the most common ISO language codes.
The application framework supports RTL for the Arabic language, which includes:
- Displaying content with the right to left layout.
- Supporting Arabic localizations.
- Displaying data configured in i18n file (static data, master data and more) and dynamic content with some limitations in Arabic.

Constant data based on the information defined in the i18n configuration of the Visualizer application supports RTL layout and displays the data in a right-to-left layout and Arabic. The following data are configured in the i18n file: Static data, Master data, Client side error messages, Fabric side error messages, and Back-end error messages.
-
Static data
Static data includes the data used to populate different labels and buttons or displayed as constant information to the user. This data is displayed as configured in the i18n file and does not depend on any other configurations. The application displays the data in a right-to-left layout and in Arabic.
- Welcome messages (for example - Good morning user)
- User prompts (for example - Please enter username and password)
- Informative text (for example - Incorrect username or password)
- Acknowledgment messages (for example - User has successfully enrolled)
-
Master data
Master data includes the information used to set options in menu lists or drop-downs. The master data is in the DBX DB, and the corresponding configuration is maintained in the i18n file. The application displays the data in a right-to-left layout and in Arabic. The master data includes, but is not limited to,
- Accounts module - Account type (for example - Savings, Checking)
- Transfers module - Recipient list (for example - name and contact details for different recipients)
- Generic (common across modules) - Country names (for example - India, China)
-
Client side error messages
Client side error messages: The application displays the error messages bound with the client-side in a right-to-left layout and Arabic. Examples of client-side error messages:
- Dashboard module
- Cannot read property null of undefined.
- Container is not defined.
- Payments module
- Presentation controller is not defined.
- Payment amount cannot be greater than the total outstanding amount.
- Dashboard module
-
Middleware (Fabric side) error message
The application displays the equivalent client-side mapped messages of every Fabric layer error message to the user in a right-to-left layout and in Arabic. All exceptions or error messages displayed as-is from the middleware and do not have corresponding client-side mappings will not be translated into Arabic. Examples of middleware error messages:
- Dashboard module
- Invalid Token: Token expired
- Session has been timed out.
- Payments module
- "dbpErrCode": 12403
- "dbpErrMsg": "SECURITY EXCEPTION - UNAUTHORIZED ACCESS"
- Dashboard module
-
Back-end error messages
The application displays the equivalent client-side mapped messages of every backend-related error message to the user in a right-to-left layout and Arabic. All exceptions or error messages displayed as-is from the backend/Microservices and do not have corresponding client-side mappings will not be translated into Arabic. Examples of backend error messages:
- Dashboard module
- errCode 12504: Transaction is denied due to max transaction limit
- Incorrect username or password.
- Payments module
- "dbpErrCode": "15001"
- "dbpErrMsg": "Backend Integration Failed"
- Dashboard module
Dynamic data includes data directly retrieved from Microservice or Transact and has no corresponding mapping in the i18n file. The information is subject to change based on specific configurations. Any data entered by the user on the screen also count as dynamic data. The dynamic content includes, but is not limited to,
- Terms and conditions
- Alerts and notifications
- Campaign and marketing data
- The application displays the dynamic data keyed in by the user in the app as-is. For example, the application displays the information entered in English as in English itself and does not apply any format or language changes to the keyed-in data.
- The characters and digits across the application will not undergo any formatting or language conversions. All the dates, times, and amounts displayed will remain without conversion.
- In the current release, the application supports only Arabic (U.A.E) ar- ae as the browser supports this language by default.
- Before packaging the code, the RTL Support is enabled at the composite app level by default. However, for reference purposes, the following section provides instructions on enabling the RTL support for a new project.
Enable RTL Support for a New Project
- Configure Internationalization (i18n) in the Quantum Visualizer app project to enable the RTL support in the application. Follow the steps mentioned in Internationalization and Supporting RTL Languages documentation for details on i18n settings, configuring locales, and completing other configurations to enable RTL support in Quantum Visualizer.
- After configuring the locale, go to Project Explorer and select Responsive web/ Desktop> frmLogin.
- On the Properties panel, go to the Action tab.
- Under General, beside init, click Edit. The Action Editor window appears.
- On the left pane, navigate to Function > Add snippet.
- Add the following code and click Save.
kony.application.setApplicationBehaviors({"rtlMirroringInWidgetPropertySetter": true}); - On the main menu, click Build > Build and Publish Web.
- Modify the language in Web browser settings to Arabic. The RTL alignment is enabled in the application.
In this topic