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:
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:
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:
|
custoFile |
Defines the customization file used for the application, and as well the server public key pins used for the certificate pinning mechanism |
<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 |
||
opMode |
Defines the device cryptographic operating mode:
|
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 |
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:
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 |
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.
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 |
|
otpLen |
OTP length to be generated |
6 |
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:
|
N/A |
|
keyValidityPeriod |
The number of days for which the credential is valid |
|
1825 |
keyLabel |
The label to identity the key on HID Approve The value must be a unique string |
|
N/A |
keyUsage | The key usage attached to this credential on HID Approve application |
|
OTP |
validityWindow |
The validity windows depending on the algorithm:
|
|
20 |
otpLen |
OTP length to be generated |
|
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:
|
OCRA only |
|
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:
|
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.
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.