Configuring the Identity Provider

The new HID Authentication Service Identity Provider (IdP) provides a reactive interface and authentication flow designed to optimize the user experience from enrollment to advanced authentication.

You can also fully localize and rebrand the interface to meet your organization's requirements.

An IdP is a service to create and manage users' digital identities and credentials. This authentication service is trusted by service providers (SP) to facilitate user access to their resources.

When a user requests access to the protected resources of an SP, the IdP verifies the user's identity to check that they have the required permissions.

The IdP verification process can use one or multiple authentication factors previously 'enrolled' by the user. These factors can include username/password combinations, FIDO passkeys, authenticator apps, push-based notifications and OTPs generated by hardware devices. This allows users to authenticate with existing factors instead of requiring them to create yet another credential.

Once the IdP has verified the user's identity and permissions, it communicates the successful authentication to the SP which then allows the user access to the requested resource.

A typical use case would be a bank (the SP) that requires their customers to authenticate using both their password and a security key. The bank trusts HID Authentication Service (the IdP) with the enrollment and management of the users' passwords and security keys as authenticator factors.

HID Authentication Service verifies a customer's identity based on the enrolled password and passkey, and then communicates the result to the bank.

  1. The user enters their User ID (username, email address, etc).

  2. The User ID is sent to the HID Authentication Service and gets the valid authentication flows for the user.

    The authentication flows include the authentication methods and actions available for the user.

  3. The user is prompted to select which method they want to use for first factor authentication.

    The list is defined by the methods available to the user for first factor authentication.

  4. The user enters their credentials for the first factor authentication.

  5. If required by the authentication flow, the user is prompted to select which method they want to use for second factor authentication.

    The list is defined by the method used for first factor authentication as well as the user's available methods for second factor authentication.

  6. The user enters their credentials for the second factor authentication.

  7. On successful authentication, the user consent page is displayed with details of the information shared with the application.

  8. The user accepts or denies the consent.

Note: The authentication flows are compliant with Open Banking and Australian Open Banking regulations.

You can drive the user enrollment process by adding the required enrollment definitions to the IdP configuration.

  1. The user enters their User ID (username, email address, etc).

  2. The User ID is sent to the HID Authentication Service and gets the valid authentication flows for the user.

    The authentication flows include the authentication methods and actions available for the user.

  3. If the user has an existing authenticator defined as the trigger for the enrollment flow, the corresponding action link is added to the interface.

  4. The user clicks the link to enroll their new authenticator (for example, a FIDO passkey).

  5. If enrollment protection is enabled, the user authenticates using one of their existing authenticators and then proceeds to the enrollment process.

  6. On successful enrollment, the user can authenticate with the new authenticator and the consent page is displayed with details of the information shared with the application.

  7. The user accepts or denies the consent.

For HID Authentication Service deployments using the legacy IdP portal, a specific fallback process is designed to ensure a smooth migration to the new IdP.

When an OpenID client is used for authentication and the HID Authentication Service detects that it does not have a workflow configuration (Authentication JourneyAuthentication Journey) for the new IdP, it automatically generates a workflow based on the client's legacy IdP configuration.

This workflow configuration is mapped to the authentication flows in the legacy configuration. During the mapping process, the authentication factors are defined according to the existing authentication policy and template combinations where the:

  • Authentication policy determines if it is a first or second authenticator factor

  • Template determines the factor type

The new workflow configuration is then added to the application's configuration and is displayed the next time it is used for authentication.

Important: It is strongly recommended that you review and tune the generated Authentication Journey.

For example - an authentication flow using static password with push-based authentication for step-up:

Legacy IdP Configuration New IdP Workflow

Static password:

  • Authentication policy - Standard Password Policy (AT_STDPWD)

  • Authentication template - Username/Password

Static password is available as a first factor (LOGIN type) with supported actions (change/reset password):

Copy 
{
    "factorId": "factor.first_AT_STDPWD",
    "code": "AT_STDPWD",
    "stepUp": "automatic",
    "type": "LOGIN",
    "actions": [
        "action.change_password",
        "action.forgot_password"
    ],
    "accessCriteriaId": "access_criteria.common_to_all",
    "retry": 3
}

Push:

  • Authentication policy - Push Authentication (AT_PASASTD)

  • Authentication template - Push-Based Authentication

Push authentication is available as second factor (PUSH type) after validation of the static password:

Copy 
{
    "factorId": "factor.second_AT_PASASTD",
    "code": "AT_PASASTD",
    "type": "PUSH",
    "upon": [
        "factor.first_AT_STDPWD"
    ],
    "accessCriteriaId": "access_criteria.common_to_all",
    "retry": 3
}

The supported authentication flows are:

  • LDAP Password + OOB (auto-enrollment)

  • LDAP Password + Push

  • Static Password

  • OTP

  • OTP + Static Password

  • Static Password + Push

  • Static Password + OOB (SMS and email)

  • Activation code + OTP

  • Static Password management (change and reset)

Note:

  • Authentication policies with type SEEDED and SEED_ANY are ignored

  • All existing authenticators remain valid so your end users will not be required to re-enroll their credentials

Topics in this section:

 

See also:

Configuring Support for Microsoft Entra ID

User Authentication with FIDO