Release Notes for AdminX
1.10.18.01
May 12, 2025
New Features
Resetting Account Passwords through AdminX without OTP
Community administrators can now define how end users reset their forgotten passwords — through AdminX or the Mobile App — using the new Authentication > Reset Password menu in the AdminX interface.
On the Reset Password page, administrators can configure the following options:
- Enable users to reset passwords through AdminX
- Enable users to reset passwords through Mobile App
For more information, see Resetting Account Passwords.
Although mobile-based password resets are supported in the current implementation, this new feature requires that the Enable users to reset passwords through Mobile App setting be explicitly enabled in AdminX for mobile resets to function.
Ability to Terminate Users’ Active Sessions via AdminX
Community administrators with the user.revoke-sessions permission can now revoke active sessions - either their own or others' - to enhance security in cases such as password resets, user termination, or potential insider threats. For more information, see the Ability to Terminate Users’ Active Sessions section in Terminating User's Active Sessions.
Added New Authentication Journey to Login through Profile OTP
A new authentication method, Password + Profile OTP, has been added to the Adaptive Authentication Journey page. When a community administrator assigns this journey to a user, the user is first prompted to enter their password, followed by a verification code (Profile OTP). Upon successful authentication, the user is logged in to the AdminX interface.
- The Profile Passcode option appears on the Choose an authentication method screen only when multiple OTP options (e.g., email and SMS) are enabled for the user journey.
- Make sure that the Password + Profile OTP option has been set as the authentication journey.
Implemented Retry Mechanism for ID Proofing Sessions
Community administrators can now configure the number of retry attempts allowed when users fail to complete the verification process. This is managed in DVCID via a new parameter, maxRetries. In 1Kosmos, the status "Verification Not Performed" indicates that the captured image does not meet the required quality criteria, prompting users to retry document scanning.
By default, the maximum number of retry attempts is set to 2, but administrators can increase it up to 5. If the retry attempt count is set above 4, the UI prompts the administrator to correct the verification configuration before continuing.
If users are unable to complete verification within the allowed attempts, their status remains "Verification Not Performed." The UI also displays a number selector to show how many attempts the user has made. For more information, see the Viewing Session Results section in Verification Journey.
Bug Fixes
- User authentication via password or OTP fails when Kafka pods were down.
- An error message “allowed is not allowed” is displayed when the administrator creates or updates the transformation script.
- When a new broker is added to an existing Active Directory using the same licenseKey as the first broker, the license.json file on the new broker does not contain any licenseKey details. Instead, AdminX generates a new license for each broker/authproxy everytime it is downloaded.
- An error is displayed during document enrollment for IAL2 in the SAML/OIDC authentication flow.
- A typo appears in the message shown upon clicking the Download button for the Login Activity Report in the Reports > Login Activity Reports section of AdminX.
1.10.17
April 12, 2025
New Features
Restricting Access Based on Geo Location
This feature is applicable only when end users attempt to authenticate via QR codes or push notifications using their 1Kosmos mobile application.
1Kosmos now offers the ability to restrict user access if they are not within the allowed radius of their trusted locations. Community administrators can configure this new geo-based restriction rule using the Add New Adaptive Authentication Journey drop-down menu under Authentication > Adaptive Authentication. While configuring the rule, administrators can define the allowed distance between user's mobile location and their trusted location. During authentication, if the location of the user’s device is not within the allowed range of their trusted location, access is denied. For more information, see Restricting Access Based on Geolocation.
Community administrators must ensure that the users’ AD attribute which carries the trusted location is mapped to the BlockID attribute (trustedLocation).
Added Expired and Abandoned Statuses in ID Proofing
1Kosmos now introduces two new statuses in ID proofing: Expired and Abandoned. These statuses can be viewed in the Status drop-down menu of the Verification tab in the AdminX interface. Additionally, the following changes have been implemented as part of this enhancement:
- Two new timestamps have been added: expireSessionInMin (time to start) and abandonSessionInMin (time to complete after starting). These timestamps distinguish between Expired and Abandoned sessions. The default time for the expireSessionInMin parameter is set to 7 days, while the abandonSessionInMin is set to 1 hour.
- Two new events, E_IDV_SESSION_EXPIRED and E_IDV_SESSION_ABANDONED, are triggered when the session is marked as Expired or Abandoned, respectively. For more information, see ID Verification Events.
Ability to Configure Forced Re-Authentication for Service Provider (SP) Applications
1Kosmos now provides community administrators with the ability to force re-authentication when accessing specified SAML/OIDC Service Provider (SP) applications. You can enable re-authentication with the introduction of the new Force Re-authentication setting in the AdminX interface under the Applications tab. By default, this setting is disabled. This feature prompts users to re-enter any required credentials for the relevant authentication journey, regardless of whether they are already logged in with the same authentication factors. The purpose of re-authentication is to ensure continued security and verify the user's identity at specific intervals, preventing unauthorized access by adding an additional layer of protection. For more information, see SAML Application Integrations.
Bug Fixes
Fixed an issue where users received an 'Access Denied' message when attempting to access applications integrated with SAML SSO, despite the SAMLResponse being marked as Success.
1.10.16.01
March 15, 2025
New Features
Adding Affidavit on behalf of a User
1Kosmos enables community/helpdesk administrators to add an affidavit to a user’s web wallet allowing them to become IAL2 certified users without the need to physically scan their documents, but instead rely on notarized physical copies to assert their identity. Affidavit in 1Kosmos is a declaration made by the administrators certifying the authenticity of another user's passport (PPT), Driving License (DL), or SSN. The administrator who creates the affidavit assumes responsibility for verifying the accuracy of the document. However, only administrators with the following permissions are authorized to add the affidavit. For more information, see Bypassing Verification Using Notarized Documents.
New users will no longer be required to enter a PIN.
- user.affidavit.add
- users.view-user
- users.edit
- users.all-users
Bypassing Authentication for Specific Applications
1Kosmos now allows community administrators to configure an adaptive authentication flow that bypasses authentication for specific applications when users are within the designated network range.
As part of this enhancement, a new Grant access action has now been added under the Decision section when creating a new adaptive authentication journey. If the community administrator selects this action, it is mandatory to choose an application for which the journey will apply. This option is recommended for use with low-risk applications where the user does not need to be prompted for authentication within a corporate network. For more information, see Adaptive Authentication.
Authentication cannot be bypassed for AdminX.
Filter Verification Results by Journey Name and UID
Two new filters, Journey Name(DVCID) and uid filter have been added to the Verification > Verification page allowing you to filter sessions and download more granular results. For more information, see Verification Journey.
Display of Appropriate Error Message for Missing Email on User Profile
When a user attempts to download a report from the Verification > Verification page without an email address on their profile, the UI will validate the user's email. If no email is found, an error message will be displayed, notifying the user about the missing email address.
Introduced Standardized Error Responses for User Access
User enumeration is a security vulnerability that arises when an attacker can identify whether a specific username or account exists in a system based on its responses. To prevent user enumeration, the AdminX interface has now been enhanced to display the appropriate error codes and responses in the following scenarios.
The table below outlines the old and new error codes that will be displayed in the AdminX interface:
Scenario | Old Error Message | New Error Message and Error Code |
---|---|---|
User is disabled | Your account has been disabled. Please contact your administrator | You are not authorized to access. Error code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here, XXXX indicates the privately encrypted ECDSA error code. |
User not found | User not Found. | You are not authorized to access. Error code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here, XXXX indicates the privately encrypted ECDSA error code. |
User locked | Your account has been locked by an administrator. Please contact your administrator. | You are not authorized to access. Error code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here, XXXX indicates the privately encrypted ECDSA error code. |
User not authorized | You are not authorized to access this page. | You are not authorized to access. Error code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here, XXXX indicates the privately encrypted ECDSA error code. |
User locked by a particular time | Your account has been temporarily locked for security reasons. Please try again in ${minutes} minutes. | You are not authorized to access. Error code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here, XXXX indicates the privately encrypted ECDSA error code. |
1.10.15
February 21, 2025
New Features
Configuring Authentication Journeys for Windows Workstation MFA Agent in AdminX UI
Windows Workstation MFA Agent can now support the creation adaptive authentication journey from AdminX. The adaptive authentication journey functionality has been enhanced allowing administrators to configure (create, edit, or delete) authentication journeys through the AdminX interface under Authentication > Adaptive Authentication. For more information, see Windows Workstation MFA Agent.
The administrator can configure the following types of login journeys for workstation users:
- Password only
- Push
- QR
- FIDO
- Any OTP
- Password + Push
- Password + Any OTP
- Password + FIDO
- FIDO + Shared Account
The following events are captured in the Event Logs page:
- E_ADAPTIVEAUTH_MODIFIED: This event is triggered when the adaptive auth journey for Windows Workstation is modified.
- E_ADAPTIVEAUTH_CREATED: This event is triggered when the adaptive auth journey for Windows Workstation is created.
- E_ADAPTIVEAUTH_DELETED: This event is triggered when the adaptive auth journey for Windows Workstation is deleted.
Customizing QR Code Design
The Branding page in the AdminX interface has been enhanced allowing administrators to customize the QR code design. You can upload a png or jpg file of size less than 10KB. The recommended size is 35px x 35px. For more information, see Branding.
Ability to Download Verification Results
The community administrator or users with the following permissions can download the report from the AdminX interface under Verification > Verification page.
- idproofing.reports.verification-sessions-download
- idproofing.session-management
Download reports by filtering records based on document type, verification status, and the user who completed the verification process. If the report exceeds 2 million records, users will be prompted to refine their search. For more information, see Downloading Verification Reports.
Bug Fixes
- An invalid Orion authenticator icon is displayed on the other user's profile.
1.10.14.01
January 16, 2025
New Features
Ability to Authenticate with Kerberos
Community administrators can now specify which users within a community are permitted to authenticate using Kerberos, granting them access to the AdminX interface. This can be configured through the Kerberos Single Sign On setting located under Directory > Directory Integrations > <Your AD> Advanced Configuration to enable the Kerberos configuration. Additionally, the following new options have been introduced to configure the authentication journey.
- Kerberos
- Kerberos + Push
- Kerberos + Any OTP
For more information, see Kerberos Authentication.
1.10.14
January 10, 2025
New Features
Ability to Login to a Tenant Using Passcodes from Other Channels
When initiating an authentication journey with a Password & any OTP as the authentication methods, a new Already have a passcode? link will appear on the Sign In – Choose an authentication method page. This feature allows users to bypass generating a new OTP each time they authenticate using their profile OTP.
Make sure that the username for which the Already have a passcode? link should appear has been configured in your adaptive authentication journey.
IAL2 Device Removal Warning
When an end user attempts to remove a IAL2 authenticated device from the Devices tab under My Profile, a warning message is displayed to the user alerting them of the impact of removing the device. This warning is crucial as it ensures uninterrupted access to applications that require higher levels of identity verification.
1.10.13.01
December 14, 2024
New Features
Enabling End Users to Manage Phone Numbers
1Kosmos now enables end-users to add or remove their phone numbers directly through the AdminX interface. This functionality enables end users to make updates to phone numbers on demand and enables them to receive passcodes to new numbers. To allow end-users to link their mobile numbers, community administrators must enable the new Allow users to enroll mobile / landline number setting under Authentication > Multi-factor Authentication > Enroll Phone Number. After enabling this setting, a new Add Phone Number button is displayed under the My Profile tab using which endusers can associate their phone numbers. For more information, see the Viewing My Profile section in Managing My Profile.
Ability to Onboard First Time Login Users through BlockID App
Upon first-time login with a password, users will be prompted to enroll for passwordless access through the BlockID app, allowing them to go passwordless from day one.
Prerequisite: Community administrators must have enabled the new Passwordless Access on BlockID App setting in Initial Sign in MFA Enrollment policy section under the Authentication > Enrollment Preferences tab.
For more information, see Enrollment Preferences Policy.
Generating Onboarding Invite on Behalf of Another User
Community administrators or helpdesk administrators with the user.generate.qr permission can generate a QR code on behalf of another user, enabling them to onboard devices in the user's presence. In addition to the user.generate.qr permission, helpdesk administrators will also need the following permissions to generate the QR code. This option is recommended for scenarios where user onboarding needs to be controlled, requiring users to enroll in the presence of an administrator.
- users.all-users
- users.view-user
- users.edit
For more information, see the Generating Onboarding Invites on Behalf of Another User section in User Management.
Introduced Skip MFA for LDAP Service Accounts in Auth Proxy
With the introduction of the Skip MFA for Service Accounts section in Auth Proxy, community administrators can now specify which service accounts for LDAP can bypass MFA. By specifying the accounts that must skip MFA, community administrators can directly grant access to such accounts with just a username and password. For more information, see Auth Proxy for LDAP Server.