Advanced Configuration for Push Authentication

The following sections detail the advanced parameters of the push-based validation solution.

These parameters can be edited using the corresponding SCIM API endpoints:

Important: The parameters highlighted in gray should not be modified.

Customizable Device Type Parameters

For the full schema syntax, see urn:hid:scim:api:idp:2.0:device:type:Push.

Device Type Provisioning

Defines the parameters to set during the device provisioning.

Parameter Description Default Value

maximumDevicePerUser

The maximum number of this type of device that can be assigned to a user.

The limit is only verified when the user attempts to activate a new device of this type and an error message is displayed if they have already reached the maximum.

If you set a maximum, it will not affect users who already have more devices than the limit (that is, it will not block authentication nor delete or modify existing devices). However, these users will only be able to activate a new device if they discard existing devices to meet the new limit. For example, if you set the limit to 2 devices, a user with 3 existing devices will need to discard 2 to activate a new device.

The default value is -1 (unlimited).

serverTLSCertificate

Server TLS certificate complete value used by the device and HID Authentication Service to compute the session key

It corresponds to the body of the HID Authentication Service TLS certificate.

This parameter supports configuration of multiple certificates (in PEM format) if your deployment includes multiple access points for HID Approve. Append the certificates such as:

-----BEGIN CERTIFICATE-----
MIIDSzCCAjOgAwIBAgIEco0o3jANBgkqhkiG9w0BAQsFADBWMRYwFAYDVQQLEw1B
...
ax0oW532uDwEQKUpTOIhRjEbP6p8uhyPG4dyV46tPA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDfDCCAmSgAwIBAgIJAKHzwx0jDzrsMA0GCSqGSIb3DQEBCwUAMCcxJTAjBgNV
...
5F6PlD4k5Q9hBUKFdbO5wxc6R9cENfoEoZVnvtwCmbo=
-----END CERTIFICATE-----

Retrieve the SSL certificate of the authentication server (connecting with a browser) and save it as PEM BASE 64 encoded (for example, as myserverSSLcertificate.crt).

Then edit this file with a text editor such as Notepad and copy the content, including the -----BEGIN CERTIFICATE----- & -----END CERTIFICATE----- mentions.

Important: If a reverse proxy is used to access the HID Authentication Service, make sure that you have configured the proxy server TLS certificate (NOT the HID Authentication Service SSL certificate value).

containerProfile

Defines the list of credentials and authenticators to generate during registration, as well as the mapping between each authentication policy and its channel, separated by |

Each item uses the format:

type:credential_type:authentication_policy:channel

Each key definition is an array containing:

  • keyType - the type of the key (SMK, OTP or RSA)

  • keyId - the key identifier for the HID Approve application

  • credId - the code of the credential type to associate with this key

  • authPolicyCode - the code of the authentication policy to create for this key and used by HID Approve when performing the transaction signature

  • channelCode - the code of the channel to be used by HID Approve when performing the transaction signature

Important: The first key in the list must always be an SMK key.
Note: To use Event-based credentials for Secure Code versus Time-based credentials, make sure that you update the OTP credential accordingly.

The default values are:

  • Key 1: Credential (AES Key) used for Mobile Service communications
    One CT_SMKV4 credential (SMK) associated with a:

    • AT_SMK authenticator

    • CH_SMK channel

  • Key 2: OATH Time-based credential (secret key) used to generate Secure Codes
    One CT_TDSOT credential (OTP) associated with a:

    • AT_CUSTOTP authenticator

    • CH_PASA channel

  • Key 3: Single-parameter Challenge/Response authentication
    One CT_TDSOATCR credential (OTP) associated with a:

    • AT_CUSTOTP authenticator

    • CH_PASA channel

  • Key 4: Multi-parameter Challenge/Response authentication
    One CT_TDSOATSIGN credential (OTP) associated with a:

    • AT_CUSTOTP authenticator

    • CH_PASA channel

  • Key 5: Credential (RSA key) used during the Logon validation process
    One CT_PASAV4 credential (RSA) associated with a:

    • AT_PASA authenticator

    • CH_PASA channel

  • Key 6: Credential (RSA key) used during Action validation process
    One CT_TDSV4 credential (RSA) associated with a:

    • AT_TDS authenticator

    • CH_TDS channel

custoFile

Defines the customization file used for the application, and as well the server public key pins used for the certificate pinning mechanism

See Customize the HID Approve application

<empty>

policyRules

Rules that define mobile device characteristics (such as OS, OS version, key store mode or rooted state), allowing to excluded matching devices from Service Registration

Note: The refreshinterval parameter is not supported by HID Approve.
"rules": {
	"refreshinterval": 1440,
	"version": 1,
	"provisioning": [{
		"ruleid": 1,
		"phonestates": [{ 
			"isRooted": "true"
		}],
	"outcome": "deny",
	"message": "Not allowed to provision for rooted or jailbroken devices"
	}]
}						

keysProtectionPolicy

See Key Protection Policy

opMode

Defines the device cryptographic operating mode:

  • fips_strict – mobile operates in FIPS mode strictly as recommended by the NIST guidelines
  • fips_devbinding – mobile operates using FIPS-approved algorithms and continues to use Secure Element in device for binding (when it exists, even if the FIPS-certified status is unknown)
  • default – mobile operates using best cryptographic practices recommended by HID Global

default

Important: DO NOT CHANGE THIS VALUE when integrating with the HID Approve SDK (keep the default value).

Only modify this setting for deployments with the HID Approve application.

kdfLen

Defines the length used to compute pss (pre-shared secret)

10

kdfCharset

Defines the char set used to compute pss (pre-shared secret)

Possible values are:

  • ALPHA – Only uppercase or numeric characters
  • ASCII – the ASCII "94" char set (ASCII printable characters from 0 to 126)

ALPHA

Note: The device validity is computed automatically and corresponds to the duration of the minimum value of keyValidityPeriod of the credential type keys (CT_SMKV4, CT_PASAV4 and CT_TDSV4).

Device Type Notifications

Parameter Description Default Value

appId

Identifier of the push mobile application (can be HID Approve or a custom application) allowed to use this delivery gateway. Can be used if there are multiple delivery gateways for the same OS as adding the appId parameter allows to matching to a specific device type (where the parameter is also defined)

None

pushNotif

Indicates if push-based notifications should be sent to the mobile device (in the context of push-based action or logon operation validation)

Possible values are:

  • Y – push notifications are sent
  • N – push notifications will not be pushed to the mobile device

Setting the parameter to N allows using the push-based solution without configuring delivery gateways. Instead, “getPending requests” on the mobile device allows retrieving the operations to be validated.

Y

forceInstallation

(API only)

Indicates if the PushID of the mobile device should be registered in Microsoft Azure when sending an HID Approve notification (for example, to create installations in a new hub)

Possible values are:

  • false - the installation will only be created during registration and update with a new PushID but not when sending the notification

  • true - the installation will also be created before sending the notification

false

OATH Offline

Parameter Description Default Value

challengeLength

To generate a challenge for challenge/response (asynchronous) authentication

In OATH mode, this value must be compatible with the OCRA suite defined for the Challenge/Response Credential Types

8

Key Protection Policy

The following table lists details about key protection policy parameters.

The policy string is a semicolon separated list of PARAM=VALUE pairs as defined in the following table.

Parameter Description Possible Values

type

Protection type

Available for Device Type (and Credential Type also if using HID Approve SDK):

  • device – protected by mobile device protection, (that is, no extra protection implementation)
  • password – password protection
  • devicelockorpassword – protected by mobile screenlock security method if it exists at time of registration, else protected by a password
  • biometricorpassword – protected by biometric credential (fingerprint/face) if it is enabled/available, else protected by a password

Note: When the Protection type is password, devicelockorpassword or biometricorpassword, the list of parameters must also be defined.

For the other types, these parameters are not required.

Available for Credential Type:

  • container – ensures that the credential will use the protection policy defined in the Device Type Container keys protection policy
Important: To ensure a user-friendly integration, HID Approve application only supports this default value.

Lock policy (lockPolicy)

type

Password lock policy

  • Delay – an exponential delay is inserted between each failed authentication attempt

    This means the user must wait a short period before they can try again.

    This waiting time increases for each failed attempt until number of attempts reaches the COUNTER parameter value.

  • Nolock – password never locks
  • Lock – password locks when number of attempts reaches COUNTER parameter value
  • SILENT – password validation is delegated to server-side controls and eventually blocking access on many consecutive failures by augmenting the failed authentication counter

    To use this type, you need to create an additional Mobile Operation Protection Key Credential Type.

    Note: Password expiration (HISTMAXAGE) and password caching (CACHE_ENABLED) are automatically disabled when the SILENT LockType is configured for use.

initialDelay

The parameter value corresponds to the initial delay in seconds

When type is set to Delay, defines the number of times the waiting time is multiplied after an incorrect authentication attempt

The resulting wait is calculated by doubling the initial delay for each failed attempt - wait = initial delay x 2^(attempts-1)

By default, after the fourth failed attempt, the delay will be 16 seconds (where 2 x 2^3).

If you increase the value to 4, this delay will be 32 seconds (where 4 x 2^3).

Numeric value – default is 2 times

maxCounterValue

Defines the maximum number of incorrect authentication attempts allowed before the credential locks

Numeric value – default is 6 attempts

The counter is reset to 0 on the next successful authentication

Password policy (passwordPolicy)

minLength

Minimum password length

Numeric value – default is 6

maxLength

Maximum password length

Numeric value – default is 8

minUpperCase

Minimum number of upper case characters

Numeric value – default is 1

minLowerCase

Minimum number of lower case characters

Numeric value – default is 0

minNumeric

Minimum number of numeric characters

Numeric value – default is 0

minAlpha

Minimum number of alpha characters

Numeric value – default is 1

minNonAlpha

Minimum number of special characters

Numeric value – default is 1

maxUpperCase

Maximum number of upper case characters

Numeric value – default is 8

maxLowerCase

Maximum number of lower case characters

Numeric value – default is 8

maxNumeric

Maximum number of numeric characters

Numeric value – default is 8

maxAlpha

Maximum number of alpha characters

Numeric value – default is 8

maxNonAlpha

Maximum number of special characters

Numeric value – default is 8

History policy (historyPolicy)

maxHistory

History Maximum Password

This security setting determines the number of unique new passwords that have to be associated with the key before an old password can be reused.

0 authorizes users to reuse current password when password is changed

Default is 1

minAge

History Minimum age

This security setting determines the period of time (in days) that a password must be used before the user can change it. It must be less than the maximum password age.

0 allows changes immediately

Default is 1 day

maxAge

History Maximum age

This determines how long users can keep a password before they have to change it.

0 means the password never expires.

Default is 180 days.

Caching policy (cachingPolicy)

enabled

Password caching mode

When password caching is enabled, password is prompted before displaying the push transaction content and it is cached during a set time to allow the user to approve/decline the transaction without re-entering the password

  • False – 0
  • True – 1 (default value)

timeout

Duration in seconds during which the password is kept in cache

Numeric value – default is 30

Maximum allowed is 300 seconds

Note: About Password Policies

When defining the rules of the password policy, make sure that there are no logical conflicts. For example, do not specify that the minimum number of numeric characters is 8, in combination a maximum password length of 6 characters.

It is possible to define an exclusive numeric policy which is more user-friendly in mobile authentication deployments.

It is also visually effective when displayed as the HID Approve application tooltip during the password setup process.

In addition, it is recommended that you test the password policy on the HID Approve application before deploying it to your user population.

Customizable Credential Type Parameters

For the full schema syntax, see urn:hid:scim:api:idp:2.0:credential:Type.

Mobile-Based Credential Types

For:

  • Mobile Logon credentials (push key: CT_PASAV4)

  • Mobile Action credentials (signkey: CT_TDSV4)

  • Mobile Transport Key credentials (sessionkey: CT_SMKV4)

Parameter Description Default Value

keyValidityPeriod

The number of days for which the credential is valid

1825

approvalStatus

The approval status to be sent to the device

Any string items are separated by |

Used as default if the Bank Application does not specify a value when the transaction is created (calling API indirectDeliverChallenge)

Important: DO NOT CHANGE THIS VALUE for deployments with the HID Approve application.

accept|deny|report (do not modify)

keyUsage

The key usage attached to this credential on HID Approve application

  • CT_PASAV4 - authentication

  • CT_TDSV4 - signature

otpLen

OTP length to be generated

6

Note: The Mobile Transport Key credentials (sessionkey: CT_SMKV4) only contain the keyValidityPeriod parameter.

OATH Credential Types

For:

  • Mobile OATH credentials (CT_TDSOE and CT_TDSOT)

  • Mobile OATH OCRA for Challenge/Response mode credentials (CT_TDSOAECR and CT_TDSOATCR)

  • Mobile OATH OCRA for Signature mode credentials (CT_TDSOAESIGN and CT_TDSOATSIGN)

Parameter Description Supported algorithm Default Value

algo

The algorithm for this credential

Possible values are:

  • hotp - OATH event-based credentials

  • totp - OATH time-based credentials

  • ocra - OATH challenge-response credentials (see also OCRA suite)

N/A
  • CT_TDSOE - hotp

  • CT_TDSOT - totp

  • CT_TDSOAECR - ocra

  • CT_TDSOATCR - ocra

  • CT_TDSOAESIGN - ocra

  • CT_TDSOATSIGN - ocra

keyValidityPeriod

The number of days for which the credential is valid

  • HOTP

  • TOTP

  • OCRA

1825

keyLabel

The label to identity the key on HID Approve

The value must be a unique string

  • HOTP

  • TOTP

  • OCRA

N/A

keyUsage The key usage attached to this credential on HID Approve application
  • HOTP

  • TOTP

  • OCRA

OTP

validityWindow

The validity windows depending on the algorithm:

  • HOTP - counter values relative to the server counter

  • TOTP - number of timesteps relative to the current server clock

  • HOTP

  • TOTP

20

otpLen

OTP length to be generated

  • HOTP

  • TOTP

8

timestep

OATH time step parameter in seconds

TOTP only

30

ocraSuite

OCRA algorithm server suite used during the exchanges between the server and the HID Approve application:

  • Challenge/Response

  • Signature

OCRA only

  • CT_TDSOAECR -

    OCRA-1:HOTP-SHA1-8:C-QN08

  • CT_TDSOATCR -

    OCRA-1:HOTP-SHA1-8:C-QN08-T30S

  • CT_TDSOAESIGN -

    OCRA-1:HOTP-SHA1-8:C-QA48 for Event mode

  • CT_TDSOATSIGN -

    OCRA-1:HOTP-SHA1-8:C-QA48-T30S

modes

OCRA mode allowing to define the required credential type to support in the approval flow

The possible values can be one or both of the following:

  • CHALLENGE_RESPONSE

  • SIGNATURE

OCRA only

[ "CHALLENGE_RESPONSE", "SIGNATURE" ]

Request Expiration Parameters

Below are the parameters to configure the validity/timeout periods for the provisioning and transaction requests.

Provisioning Request

Edit the Validity period of password setting of the CT_TDSOOB Credential Type (default value is 1800 seconds).

This means that, by default, a service can be registered on HID Approve app using the QR code scan or the manual invitation code up to 30 minutes (1800 seconds) after the Service has been requested.

This duration can be extended, but it is recommended to keep it as short as possible.

At the end of the timeout, the Service Registration will fail.

Note: By default, a registration request (QR code) cannot be reused so if registration fails, a new registration request (QR code) must be generated.

However, this default policy can be updated by defining the number of QR code retries in the Default expiry threshold parameter of the Mobile Registration Authentication Policy (AT_TDSOOB):

This value sets the number of times that a user can try to scan a QR code (for example, if device registration fails due to network connection failure).

Transaction Request

Edit the Challenge timeout period(s) of the AT_TDS (Action Validation) or the AT_PASA (Logon Validation) Authentication Policies setting (default value is 3600 seconds).

This means that, by default, a transaction (Logon or Action) can be retrieved, then approved or denied on HID Approve app up to 1 hour after the transaction operation has been initiated.

This duration can be extended, but it is recommended to keep it as short as possible.

After timeout, the transaction will no longer be retrieved by the app, or if it has already been retrieved, the approval/decline operation will fail.