The Okta Sign-In Widget supports customization of default text strings displayed across various views. Most default strings are provided by Okta. For guidance on prerequisites and the configuration process for achieving this customization, refer to How to Create Custom Labels in the Sign-in Widget.
However, admins using the Custom Remediation for Device Assurance feature write their own end-user remediation strings that render in the widget. This article discusses how admins can define customizations for these strings in multiple locales.
- Sign-in Widget
- Customization
- Okta Identity Engine (OIE)
- Device Assurance Policies
- Custom Remediation for Device Assurance
Custom Remediation for Device Assurance is a text customization feature, but it does not natively support text localization.
Custom remediation messages are authored in a single primary locale and are displayed in that language for all end users, regardless of their individual locale settings. This presents challenges for organizations with a multilingual user base that require localized messaging across different regions.
As outlined in the developer documentation, Updates to widget i18n properties, and the aforementioned How to Create Custom Labels in the Sign-in Widget article, organizations using a Sign-In Widget hosted on a custom domain can override default strings through the `i18n` configuration object in the custom code editor
To access the custom code editor from the Admin Console:
- Go to Customizations > Brand
- Select the brand associated with a custom domain
- Go to Pages > Configure (within the Sign-in page section)
- Click the Edit button in the Code editor
In most cases, text overrides are specified for properties listed in the login.properties file, which includes Okta-defined keys (for example, `primaryauth.title`). However, strings used for Custom Remediation for Device Assurance are not included in this file, as they are dynamically defined by administrators.
Despite not appearing in login.properties, custom remediation strings have their own unique i18n property keys.
If the device assurance condition has a default remediation message (for example, Minimum Android version), admins should:
- Search through the `login.properties` file for the key used by the default remediation message displayed for a failing device assurance condition and then append `device.assurance.custom.remediation`.
- For example, `device.assurance.custom.remediation.idx.error.code.access_denied.device_assurance.remediation.android.upgrade_os_version` for the idx.error.code.access_denied.device_assurance.remediation.android.upgrade_os_version key
If the device assurance condition does not have a default remediation message (for example, Rooting, or any condition created using the osquery Advanced Posture Checks feature), admins should:
- Append `device.assurance.custom.remediation` to the condition’s Variable name, which can be found in the Remediation instructions configuration page when customizing remediation messages
- For example,
`device.assurance.custom.remediation.ANDROID.Okta:DeviceAssurance.Jailbreak` for the Rooting condition
- For example,
After following these steps, a custom widget configuration object may look something like this:
var config = {
...
i18n: {
es: {
'idx.error.code.access_denied.device_assurance.remediation.android.upgrade_os_version': 'Es política de nuestra empresa actualizar su dispositivo a la última versión de Android.',
'device.assurance.custom.remediation.ANDROID.Okta:DeviceAssurance.Jailbreak': 'Es política de nuestra empresa garantizar que su dispositivo Android no esté jailbreakeado.'
}
}
...
};
