5.4 Configuring Methods

A method is a way of authenticating the identity of an individual who attempts to access an endpoint. Advanced Authentication provides several such methods.

To configure an authentication method for Advanced Authentication, perform the following steps:

  1. Click Methods.

  2. Click the Edit icon next to the authentication method.

  3. Make the required changes.

  4. Click Save.

Customizing Method Names

You can translate the method name to a preferred language in the Custom names section. The translated method name will appear in the following portals, clients, and events:

  • Portals: Administration, Helpdesk, Self-Service, and Reporting

  • Clients: Windows, Linux PAM, and Mac OS X

  • Events: OSP, RADIUS, and custom events.

To customize and translate the method name to a specific language, perform the following steps:

  1. Open the method for which you want to localize the method name.

  2. Specify the method name in a specific language field in the Custom names section.

  3. Click Save.

Tenancy Settings

A top administrator can enforce the configurations of a method on secondary tenants. After configuring a method, you can lock the settings for that specific tenant. The tenant cannot edit the locked settings in the tenant administrator console.

To enforce the configurations for a specific tenant, perform the following steps:

  1. Click the Edit icon next to the authentication method for which you want to enforce the configurations.

  2. In Tenancy settings, click +.

  3. Move the tenant to whom you want to enforce the configurations from Available to Used list in the Force the configuration for the tenants section.

  4. After you add a tenant, the Hide forced settings option is displayed. You can turn this option to ON if you want to hide the settings that you have enforced on the tenant.

  5. Click Save.

After configuring the authentication methods, you must create an authentication chain and map the configured methods to the chain. You can also create a chain with a single method. For example, you can create different authentication chains for an organization that has two departments, IT and Finance. For the IT department, you can create a chain with Password and Smartphone methods. For the Finance department, a chain with only the Fingerprint method can be created. For more information about creating chains, see Creating a Chain.

The methods do not appear in the Self-Service portal until you include them in a chain, and link that chain to an event.

You can configure the following methods in Advanced Authentication:

5.4.1 BankID

Advanced Authentication provides the BankID method that facilitates users to authenticate with their personal identification number. Advanced Authentication supports both the desktop and the mobile versions of BankID. In this method, the user must configure the BankID app with the personal identification number, activation, and security code. The security code is mapped with the personal identification number.

NOTE:The user must ensure to set the security code with six digits in non-sequential format (for example: 221144) in the BankID app.

While enrolling the user, the specified identification number is saved as a template in the Advanced Authentication database. This method allows the users to get authenticated by specifying their secret code configured on the BankID app.

When a user wants to authenticate on an endpoint such as a laptop or a website with the BankID method. In this scenario, the authentication flow is as follows:

  1. When the authentication request is initiated, the endpoint contacts the Advanced Authentication server.

  2. The Advanced Authentication server validates the user’s credentials.

  3. After validating the credentials, the Advanced Authentication server sends a request to the BankID app.

  4. User opens the BankID app, specifies the Security Code.

    • Click Identify on the Mobile app.

    • Click Verify my identity on the Desktop app.

  5. The Security code is sent to the BankID server to validate.

  6. The BankID server validates the authentication and the endpoint gets authenticated.

To configure the BankID method, perform the following steps:

NOTE:Ensure that you have the BankID client SSL certificate as a pre-requisite.

  1. Click Browse then select the client SSL certificate from the local drive.

    The certificate must be in PKCS12 format.

  2. Specify Private key password.

  3. Set Enable Test Mode to ON, to allow the user to test the authenticator with valid test BankID.

    If you set this option to OFF, users must use valid production BankID to enroll the authenticator.

  4. Click Save.

5.4.2 Bluetooth

In the Bluetooth method, you can enroll your smartphone or a mobile device. For example, Bob wants to be authenticated through the Bluetooth method. He enrolls the Bluetooth method on the Advanced Authentication Self-Service portal. He can get authenticated with the Bluetooth method only when his smartphone is in the range.

By default, the Enable reaction on device removal option is enabled. When this option is enabled and a user tries to logs in to Windows using Bluetooth, Windows gets locked automatically in the following scenario:

  • When the Bluetooth device is disabled

  • When the Bluetooth device is out of range

NOTE:It is recommended to combine the Bluetooth method with another authentication method in a chain to enhance the security.

5.4.3 Card

The Card authentication happens when a user places a contactless card on a card reader.

Advanced Authentication supports the Microsoft policy Interactive logon: Smart card removal behavior that allows you to specify an action on the card event. You can configure the policy to perform a force log off or lock a user session when a user places a card on the reader. Only Microsoft Windows supports this policy.

By default, the Enable Tap&Go option is disabled. When this option is disabled, a card must be placed on the reader when a user logs in. When the user removes the card from the reader, the Windows Client runs an action that is specified in the Interactive logon: Smart card removal behavior policy. When you set this option to ON, users can tap a card to perform the following actions (depending on the Interactive logon: Smart card removal behavior policy) without keeping their cards on the reader:

  • To log in

  • To lock a session

  • To log off

NOTE:The policy is supported for Microsoft Windows only and it is not supported for the PKI authenticators.

When you enable Single-sign on (SSO) for Remote Desktop, the Interactive logon: Smart card removal behavior policy is ignored. You must disable SSO to make it working.

5.4.4 Email OTP

In the Email OTP authentication method, the server sends an email with a one-time password (OTP) to the user's e-mail address. The user must specify the OTP on the device where the user needs to get authenticated. It is a best practice to use the Email OTP authentication method with other methods such as Password or LDAP Password to achieve multi-factor authentication and to prohibit malicious users from sending SPAM mails to a user's email box with authentication requests.

To configure the Email OTP method, specify the following details:

Parameter

Description

OTP period

Lifetime of an OTP token in seconds. The default OTP period is 120 seconds. Maximum value for the OTP period is 86400 seconds.

OTP format

Length of an OTP token. The default value is 6 digits.

Subject

Subject of the mail.

Format

Format of an email message. The default format is Plain Text. The HTML format allows to use embedded images. You can specify an HTML format of the message in HTML.

Body

For the Plain Text format, you can specify the following variables:

  • {user}: Username.

  • {endpoint}: Device that a user authenticates to.

  • {event}: Name of the event where the user is trying to authenticate to.

  • {otp}: One-Time-Password to be sent to the user.

Allow to override email address

Option that allows to prevent users from providing an email address that is not registered in the LDAP repository. The option is set to ON by default. Set to OFF to prevent users to specify a different email address during the enrollment.

Allow user enrollment without e-mail

Option to configure settings for the user to enroll the Email OTP authenticator without an email in the repository.

Set this option to OFF to ensure that a user does not enroll the Email OTP authenticator without an email. The user gets an error message that you can specify in Error message.

Set this option to ON to allow the user to enroll the Email OTP authenticator without an email.

5.4.5 Emergency Password

The Emergency Password method facilitates the use of a temporary password for users if they lose a smartcard or forget their smartphone. Only a helpdesk administrator can enroll the Emergency Password method for users.

WARNING:An administrator can misuse this method by trying to access other user’s account. Full administrator must be vigilant to select the right helpdesk administrators.

To configure the Emergency Password method, specify the following details:

Parameter

Description

Minimum password length

The length of the password must be at least five characters long.

Password age (days)

The validity period of a password. The default value is 3 days.

Max logins

The maximum number of login attempts that a user can perform before the password gets expired. The default value is 10.

Complexity requirements

Set to ON to enforce users creating a complex password. Password must meet the following requirements:

  • Contains at least one uppercase character

  • Contains at least one lowercase character

  • Contains at least one digit

  • Contains at least one special character

Allow change options during enrollment

When set to ON, this option allows a helpdesk administrator to set Start date, End date, and Maximum logons manually in the Helpdesk portal. This manual configuration overrides the settings in the Emergency Password method.

5.4.6 Facial Recognition

Advanced Authentication provides advanced biometric authentication with the Facial Recognition method. This method allows users to get automatically authenticated by presenting their face. The image of the face is captured by an integrated or external camera and recorded by the Microsoft API server, when the user enrolls the method. When the user tries to authenticate on an application, the recorded image is compared with the actual image. If the images match, the user is authenticated.

IMPORTANT:It is recommended to combine the Facial recognition method with another method in a chain to enhance security.

You can configure the following settings for the Facial recognition method:

WARNING:To use the Facial recognition method for OAuth 2.0 and SAML 2.0 integrations, you must have the Advanced Authentication Device Service installed.

Generating Access Key and Endpoint URL

Before you configure the Facial Recognition method, you must generate the Access Key and Endpoint URL from the Microsoft Cognitive Services.

To generate the Access Key and Endpoint URL, perform the following steps:

  1. Click Get API against Face API.

  2. Agree to the license agreement.

  3. Login with the preferred credentials.

  4. Capture the Access Key and Endpoint URL for the Face API.

    While generating the access key for the Face API, two keys are displayed. You can use anyone of the two keys.

Configuring Facial Recognition Method

To configure the Facial Recognition method, perform the following steps:

  1. Click Methods > Facial Recognition.

  2. Specify the Access Key that you have generated in the Microsoft Cognitive Services. This key is used while authenticating the user.

    For information about how to generate the Access Key in the Microsoft Cognitive Services, see Generating Access Key and Endpoint URL.

  3. Specify the Endpoint URL. This URL is location based.

NOTE:

  • For a better quality of recognition, you must use cameras with a high definition of 720p and above.

  • During enrollment, the captured images are placed on Microsoft servers and Microsoft Cognitive Services returns only the Face ID to Advanced Authentication. The Advanced Authentication stores this Face ID as enrolled authenticator. Therefore, when you change to another Access Key, the related enrollments are lost.

  • This method is not supported for cache of Windows Client, Mac OS X Client, and Linux PAM Client.

5.4.7 FIDO 2.0

The FIDO 2.0 method facilitates users to use the devices that comply with FIDO standards for authenticating to any web-based environment. The devices can be built-into the platform or external devices connected through USB. The FIDO 2.0 method uses the Web Authentication (WebAuthn) API, and Client to Authenticator Protocol (CTAP). The WebAuthn enables strong authentication with public key cryptography and allows password-less authentication.

NOTE:Advanced Authentication FIDO 2.0 method supports the following:

  • Firefox and Google Chrome browsers with the U2F device

  • Microsoft Edge browser with Windows Hello authentication

While you use Google Chrome browser, it is required to set a valid domain name for your Advanced Authentication server rather than an IP address.

If users have enrolled the FIDO 2.0 method using the Windows Hello in Microsoft Edge 17 or earlier supported browser versions then they must authenticate using the same browser. After upgrading to the latest version of Edge that supports the FIDO 2.0 standards, users must re-enroll the FIDO 2.0 method.

For more information about the WebAuthn and FIDO 2.0 authenticators, see these articles: Web Authentication, Web API for FIDO 2.0, and Microsoft Web authentication.

An Example of Authenticating with the FIDO 2.0 Method

Thomas, an end user, has enrolled the FIDO 2.0 method in the Advanced Authentication Self-Service portal by using the FIDO compliant U2F token. He wants to authenticate to the mycompany.com website. When he opens the browser and follows the prompts to access the website. Then, he is required to touch the token when there is a flash. Thomas is validated with the device and gets authenticated to mycompany.com.

5.4.8 Fingerprint

The Fingerprint method is one of the strongest biometric authentication methods of Advanced Authentication. Users can authenticate with methods such as Password (something they know) and Fingerprint (something they are) for multi-factor authentication. Users need to place their finger on a fingerprint scanner to enroll and authenticate.

To configure the Fingerprint method, perform the following steps:

  1. Set the Similarity score threshold by moving the slider to the desired score.

    NOTE:Default and recommended value for Similarity score threshold is 50. Reducing the score may result in different fingerprints getting validated.

  2. Select the number of fingers that a user must enroll.

    It is recommended to specify a number that is more than 1 because if a finger is injured, the user can use the other enrolled finger.

    NOTE:If you want to allow the use of multi-finger reader for enrollment, ensure to select the number of fingers to be enrolled as 4, 6, 8, or 10.

  3. Select the number of scans required for enrollee's each finger.

    NOTE:To improve the quality of the fingerprint enrollment, it is recommended to have multiple captures. The total number of captures including all the enrolled fingers must not exceed 25.

  4. Set Enable multi-finger reader to enroll to ON, to allow users to enroll the Fingerprint method using the Green Bit DactyScan84c multi-finger reader. Users can set Use multi-finger reader for enrollment to ON and enroll with the multi-finger reader on the Self-Service portal. The Green Bit DactyScan84c device can scan one of the following fingers combination at a time:

    • Four fingers of the right hand

    • Four fingers of the left hand

    • Two thumbs

    To enforce the users to scan fingers using the Green Bit DactyScan84c reader, set Force to use multi-finger reader to ON.

  5. Set Specify fingers during enrollment to ON, if you want to enforce selected fingers for a user to enroll.

  6. Select the preferred fingers to enroll from the Selected fingers list.

  7. Set Enable Duress finger configuration to ON, to allow users to assign one of the enrolled fingers as duress. In case of emergency or under a threat, user can authenticate with the duress finger. Authentication with the duress finger triggers an alert notification to the configured email address and phone number.

    In the Alert Configuration section, specify the following details to configure the alert notification that is to be sent to the preferred email address and phone number:

    Table 5-1

    Parameter

    Description

    Email Alert Settings

     

    Email Recipient

    The email address of recipient to whom you want to send the email alert.

    Email Alert Subject

    Subject of the email alert.

    Format

    Format of email alert. Plain Text is the default format. Other available option is HTML.

    If you select HTML format, specify the message in HTML.

    Email Alert Body

    Body of email alert. You can specify the following variables:

    • {user}: Username.

    • {endpoint}: Device that a user authenticates to.

    • {event}: Name of the event where the user is trying to authenticate to.

    SMS Alert Settings

     

    SMS Recipient

    Phone number of recipient to whom you want to send the SMS alert.

    SMS Alert Body

    Text in the SMS that is sent to the recipient. You can specify the following variables:

    • {user}: Username.

    • {endpoint}: Device that a user authenticates to.

    • {event}: Name of the event where the user is trying to authenticate to.

  8. Click Save.

NOTE:Ensure that you configure the Mail Sender and SMS Sender policies with the sender details that are required to send an alert.

Example 1: Enrolling Multiple Fingers and Authenticating with One of the Enrolled Fingers

Consider Thomas, an administrator has performed the following steps to enforce users to enroll the Fingerprint method using the Greenbit DactyScan84c device. Users can authenticate to Linux workstation with the Fingerprint method.

  1. Set Force to use multi-finger reader to ON in the Fingerprint method.

  2. Created a chain with the Fingerprint method and added another preferred method such as LDAP password or Password.

  3. Mapped the chain to the Linux Logon event.

Paul, an end user, logs in to the Self Service portal and clicks on the Fingerprint icon. He selects the four fingers of Right hand and enrolls using the Green Bit DactyScan device. After enrollment, Paul authenticates to his Linux workstation with the Nitgen device using one of the enrolled fingers. He gets authenticated successfully.

Example 2: Authenticating with a Duress Finger During an Emergency Situation

Consider Thomas, an administrator has performed the following steps to assign an enrolled finger as duress:

  1. Set Enable Duress finger configuration to ON in the Fingerprint method.

  2. Configured Alert Configuration with the alert notification text, mail address and phone number of a network security officer to send email and SMS.

  3. Created a chain with the Fingerprint method along with preferred methods such as LDAP password and Password. Assigned the chain to Networks group.

  4. Mapped the chain to the Linux logon event. Mail server is hosted on the Linux workstation.

Paul, a network staff, logs in to the Self Service portal and clicks on the Fingerprint icon. He enrolls the middle, index, ring and little fingers of the left hand. Later, he selects Left index from Assign Duress Finger drop down.

Assume, on an unfortunate day, a miscreant forcibly enters the organization and threatens Paul to authenticate to the Linux workstation. In this situation, Paul can use the duress finger (Left index finger) for authentication which triggers an alert notification to configured security personnel, who will take the necessary action.

5.4.9 LDAP Password

In the LDAP Password method, the Advanced Authentication client retrieves password that is stored in the user repository from the Advanced Authentication server.

To configure LDAP Password method, perform the following steps:

  1. Set Save LDAP password to ON, the prompt for LDAP password synchronization is displayed only for the first time until the password is changed or reset.

    NOTE:You can bypass the password synchronization dialog after the password change or reset by configuring the Password Filter. For configuring the Password Filter, see Password Filter for Active Directory.

    If you set this option to OFF:

    • If the LDAP Password method is included in a chain, users will be prompted for synchronization each time.

    • If the LDAP Password method is not included in a chain, users will not be prompted for synchronization.

  2. Set Enable SSPR integration to ON if you want to enable the Self Service Password Reset integration for Advanced Authentication web portals.

    • Specify the SSPR link text. This link is displayed on the login page where user specifies the LDAP Password.

    • Specify the SSPR URL. This URL points to the Self Service Password Reset portal.

  3. Set Enable cached logon to ON to validate user specified password with password stored (cached) in the Advanced Authentication server during authentication.

    When the Enable cached logon option is set to OFF (default behavior), the Advanced Authentication server always contacts the LDAP server to validate the user password. It may cause performance issues.

    If the user password does not match with the stored password or password is not stored on the Advanced Authentication server, then cached value gets reset and Advanced Authentication server contacts the LDAP server to validate the user password.

    If the user specified password matches the cached password, the Advanced Authentication server validates user password with LDAP server in the background. If the validation failed, the password stored on Advanced Authentication Server gets reset, so next login will be without cache.

    NOTE:The Enable cached logon option works only if any one of the following setting is set to ON:

    • Save LDAP password in the LDAP Password method.

    • Enable local caching in the Cache Options policy.

  4. Click Save.

LDAP password is stored on the Advanced Authentication server at the following two places:

  1. User data: It is used for OS logon (Windows Client, Mac OS X Client, and Linux PAM Client) and is stored when Save LDAP password option in LDAP Password method is set to ON.

  2. LDAP password authenticator: It is used while using cached logon. The password is stored when the Enable local caching option is set to ON in the Cache Options Policy.

5.4.10 OATH OTP

OATH (Initiative for Open Authentication) is an industry-wide collaboration to develop an open reference architecture using open standards to promote the adoption of strong authentication using OTP.

Advanced Authentication supports the following two different types of OATH OTP:

You can configure the following settings for the OATH methods:

HOTP

HOTP is a counter based one time password. To configure the HOTP authenticator, you can specify the following parameters:

  • OTP format: The number of digits in the OTP token. The default value is 6 digits. The value must be the same as of the tokens you are using.

  • OTP window: The size of OTP window defines number of valid OTP for authentication. When the counters are out of sync, this parameter determines the difference between the counter on the token and the server. Based on the difference, the server can recalculate the next OTP value to validate with the OTP received from the token. The server stores the last counter value (C) for which the user has provided a valid password. While verifying a new OTP from the token, the server validates C+1, C+2... until one of the OTP is identical, or till C+w, where w represents the OTP window.

    You can use the HOTP token such as Yubikey token to access not only Advanced Authentication, but also some websites or third-party services. After each use or when users press the token button accidentally, the HOTP counter on the token is increased by 1. Therefore, the counter will be out of sync between the token and Advanced Authentication server.

    For example, if the OTP window is set to 10 (by default), and the current counter value of the server is 100, then any OTP generated from the token with a counter value from 100 to 110 are valid for authentication.

    WARNING:Do not increase the HOTP window value to more than 100 as it may decrease the security by causing false matches.

During enrollment or HOTP counter synchronization in the Self-Service portal, Enrollment HOTP window that has a value of 100,000 is used. This is helps in the following:

  • HOTP tokens may be used for a long period before the enrollment in Advanced Authentication and the value is unknown and can be equal to some thousands.

  • Secure because users must provide 3 consequent HOTPs.

Configuring Yubikey for Advanced Authentication Server

  1. Download and install the Yubikey Personalization Tool from Yubico.

    To download the Yubikey Personalization Tool, see the Yubico website.

  2. Insert the Yubikey token.

    Ensure that the token is recognized. The recognition is indicated by a message Yubikey is inserted at the top-right corner of the Personalization tool.

  3. Select OATH-HOTP mode.

  4. Select Configuration Slot 1, generate the OATH Token Identifier and Secret Key.

  5. In Logging Settings, select Log configuration output.

  6. Select Traditional format or Yubico format.

  7. Click Write Configuration and save the CSV file.

For information about how to enroll the HOTP method, see HOTP in the Advanced Authentication- User guide.

TOTP

TOTP is a time based one time password. To configure the TOTP authenticator, you can specify the following parameters:

  • OTP period (sec): The value to specify how often a new OTP is generated. The default value is 30 seconds. The maximum value for the OTP period is 360 seconds.

  • OTP format: The number of digits in the OTP token. The default value is 6 digits. The value must be the same as the tokens you are using.

  • OTP window: The value to specify the periods used by Advanced Authentication server for TOTP generation. For example, if you have a period of 30 and a window of 4, then the token is valid for 2*30 seconds before current time and 2*30 seconds after current time, which is ±2 minutes. These configurations are used because time can be out-of-sync between the token and the server and may impact the authentication. The maximum value for the OTP window is 64 periods.

    IMPORTANT:It is not recommended to use an OTP window equal to 32 and higher for 4-digit OTP because it reduces security.

  • Google Authenticator format of QR code (Key URI): Option to display the QR code for the TOTP enrollment of the software token in a format that is compatible with the Google Authenticator, Microsoft Authenticator, or the NetIQ Auth apps. When you disable the option, the displayed QR code can be scanned only with the NetIQ Auth smartphone app. Enable the option to allow enrollment with the Google Authenticator or Microsoft Authenticator apps. The QR code of Google Authenticator format can also be scanned with the NetIQ Auth app (supported by the last iOS and Android apps).

    IMPORTANT:OTP format must be set to 6 digits when you use the Google Authenticator format of QR code.

  • Allow manual enrollment: When you enable the option, the Specify the TOTP secret manually section is displayed on the TOTP enrollment page of the Self-Service portal with the following parameters: Secret, Period, and Google Authenticator format of secret (Base32). By default, the option is disabled and the settings are hidden. Enabling the option may result in security risks.

You must perform the following tasks to allow the users to enroll TOTP method using the Desktop OTP tool:

Generating an Enrollment Link

Users can click the enrollment link to enroll the TOTP authenticator automatically on the Desktop OTP tool and following the further steps as described in Desktop OTP Tool. To generate an enrollment link, you can encode the server URL, tenant ID, and category name to the Base64 format using any online tool. The generated link is then sent to the users through the email to access the Desktop OTP tool and enroll the TOTP authenticator. The users can create an account on the tool to enroll the TOTP authenticator in the Self-Service portal.

To generate the enrollment link in the Base64 format, perform the following steps:

  1. To encode use the details such as server URL, tenant ID and category name in the following format:

    {"server_url":"<domain-name>","tenant_name":"<tenant-name>","category_name": "HOME"}

    For example, {"server_url": "aafserver.company.com", "tenant_name":"netiq”, "category_name": "HOME"}

    You can specify the preferred category name for category_name parameter if you have added categories in the Event Categories policy. You can remove the parameter category_name, if you have not added any category.

    You can specify TOP for the tenant_name parameter, if the Multitenancy mode is disabled.

  2. Encode the value including {} to Base64 (charset: UTF-8) format.

    For example, the encoded link is displayed as:

    eyJzZXJ2ZXJfdXJsIjogImFhZnNlcnZlci5jb21wYW55LmNvbSIsICJ0ZW5hbnRfbmFtZSI6Im5ldGlx4oCdLCAiY2F0ZWdvcnlfbmFtZSI6ICJIT01FIn0=

  3. Copy the encoded link for further use.

Sending an Enrollment Link Through Email

  1. Compose an email with the subject and body.

    For example, specify TOTP Enrollment Link in the Subject and body as follows:

    Hi Users, Click here to enroll for the TOTP authenticator using the Desktop OTP tool.

  2. Right click on the preferred text and select Hyperlink.

  3. Specify the encoded link and prefix aaf-otp in Address.

    For example, aaf-otp:eyJzZXJ2ZXJfdXJsIjogImFhZnNlcnZlci5jb21wYW55LmNvbSIsICJ0ZW5hbnRfbmFtZSI6Im5ldGlx4oCdLCAiY2F0ZWdvcnlfbmFtZSI6ICJIT01FIn0=

  4. Specify the email address of the preferred users in To then click Send.

    User can click the hyperlink to open the Desktop OTP automatically.

Importing PSKC or CSV Files

You can import the PSKC or CSV files. These token files contain token information. To import these files, perform the following steps:

  1. Click the OATH Token tab.

  2. Click Add.

  3. Click Browse and select a PSKC or CSV file.

  4. Choose a File type. The options are:

    • OATH compliant PSKC: This file type must be compliant with OAuth. For example, HID OATH TOTP compliant tokens.

    • OATH csv: This file type must contain the format as described in CSV File Format To Import OATH Compliant Tokens. You cannot use the YubiKey CSV files.

    • Yubico csv: In this file type, you must use one of the supported Log configuration output (see YubiKey Personalization Tool > Settings tab > Logging Settings) formats with comma as a delimiter.

      • Traditional format: In this file type, OATH Token Identifier must be enabled.

      • Yubico format: This file type is supported only for HOTP Length set to 6 Digits and OATH Token Identifier set to All numeric.

      IMPORTANT:Moving Factor Seed must not exceed 100000.

  5. Add the encrypted PSKC files. For this, select Password or Pre-shared key in PSKC file encryption type and provide the information.You can select Not encrypted, if the PSKC file is not encrypted with either the password or key.

  6. Click Upload to import tokens from the file.

NOTE:Advanced Authentication receives an OTP format from the imported tokens file and stores the information in the enrolled authenticator. Therefore, you need not change the default value of OTP format on the Edit Method tab.

When the tokens are imported, you can see the list and you must assign the tokens to users. This can be done in the following two ways:

  • Click Edit next to the token and select Owner and click Save.

  • A user can self-enroll a token in the Self-Service portal. Administrator must let the user know an appropriate value from the Serial column for the self-enrollment.

NOTE:Tenancy settings are not supported for the OATH tokens. Therefore, the configurations in the OATH Tokens tab cannot be enforced on tenant administrators.

CSV File Format To Import OATH Compliant Tokens

A CSV file, which is imported as OATH csv file in the Administration portal > > Methods > OATH OTP > OATH Tokens tab, must contain fields with the following parameters:

  • Token’s serial number

  • Token’s seed

  • (Optional) Type of the token: TOTP or HOTP (by default HOTP)

  • (Optional) OTP length (default value is 6 digits)

  • (Optional) Time step (default value is 30 seconds)

Comma is a delimiter.

The following is an example of a CSV file:

Token001, 15d2fa517d3c6b791bd4cc2044c241429307001f
Token002, 8c557fc050721037fd31e1d3345b5d3263263e0f, totp, 8
Token003, 658208efea5ac49d5331ba781e66f2c808cccc8e, hotp, 6
Token004, 89f0dfe1c90379da6a11aaca2fc1070f606efe36, totp, 6, 60

IMPORTANT:For the YubiKey tokens, you must use the traditional format of the CSV (check YubiKey Personalization Tool > Settings tab > Logging Settings) with comma as a delimiter. Use Yubico csv file type (Advanced Authentication Administration portal > Methods > OATH OTP > OATH Tokens).

5.4.11 Password

In the Password authentication method, you can configure security options for passwords that are stored in the appliance. For example, the local/admin user who does not have an LDAP Password can use this option.

NOTE:Do not use the Password method in chains that contain only one factor. You must always combine the Password method with other factors.

You can configure the following options for the Password method:

  • Minimum password length: The maximum length of the password.

  • Maximum password age: The validity period of the password. The default value is 42 days. If you set the value to 0, the password never expires.

  • Complexity requirements: Option to enable users to create a complex and not easily detectable password.Set to ON to enable this option. Password must meet the following requirements:

    • Contains at least one uppercase character

    • Contains at least one lowercase character

    • Contains at least one digit

    • Contains at least one special character

IMPORTANT:Advanced Authentication does not generate notifications about the password expiry. After the password expires, the local administrator cannot sign-in to the Administration portal and users using this method cannot get authenticated.

However, an administrator and a user can change their passwords in the Self-Service portal.

5.4.12 PKI

The Public Key Infrastructure (PKI) creates, stores, and distributes digital certificates. These certificates are used to verify whether a particular public key belongs to a specific entity.

Advanced Authentication supports the following two forms of PKI authentication:

PKI Device

PKI device stores the digital certificates and private keys securely. It uses the PKI infrastructure to store personal details of user such as private key, PIN, and digital certificate.

You can configure the following settings for the PKI method:

Adding the Trusted Root Certificates

You must upload the trusted root certificates for the PKI method. These certificates must meet the following requirements:

  • Root CA certificate is in the .pem format.

  • All certificates in the certification path (except Root CA) contain AIA and CDP http link to check revocation status.

  • The certificate for PKI device contains a key pair: public and private key in the x509 format. The certificates that do not comply with the requirements are ignored and hidden during enrollment.

For more information, see Single Tier PKI Hierarchy Deployment and Two Tier PKI Hierarchy Deployment.

To upload a new trusted root certificate, perform the following steps:

  1. Click Add in the Edit Method page of PKI.

  2. Click Browse.

  3. Choose a .pem certificate file and click Upload.

  4. Click Save.

NOTE:You must upload only the Root CA on appliance.

You can configure the PKI method (with certificates) in one of the following ways:

NOTE:Advanced Authentication supports the p7b format of parent certificates. These p7b format files can contain certificates and chain certificates, but not the private key. They are Base64 encoded ASCII files with extensions .p7b or.p7c.

Configuring the Environment for a Standalone Root CA

  1. Install Web Server (IIS) Role.

  2. Create the CertEnroll Folder and grant Share & NTFS permissions to the Cert Publishers group.

  3. Create CertEnroll Virtual Directory in IIS.

  4. Enable Double Escaping on IIS Server.

  5. Install Enterprise Root CA using Server Manager.

  6. Enable Object Access Auditing on CA.

  7. Configure the AIA and CDP.

  8. Publish the Root CA Certificate to AIA.

  9. Export Root CA in .der format and convert the format to .pem.

  10. Export personal certificate (that was signed by Root CA) with private key and place it on a PKI device.

Configuring the Environment for a Subordinate CA

  1. Install Web Server (IIS) Role.

  2. Create the CertEnroll Folder and grant Share & NTFS permissions to Cert Publishers group.

  3. Create CertEnroll Virtual Directory in IIS.

  4. Enable Double Escaping on IIS Server.

  5. Install the Standalone Offline Root CA.

  6. Create a CAPolicy.inf for the standalone offline root CA.

  7. Installing the Standalone Offline Root CA.

  8. Enable Auditing on the Root CA.

  9. Configure the AIA and CDP.

  10. Install Enterprise Issuing CA.

  11. Create CAPolicy.inf for Enterprise Root CA.

  12. Publish the Root CA Certificate and CRL.

  13. Install Subordinate Issuing CA.

  14. Submit the Request and Issue subordinate Issuing CA Certificate.

  15. Install the subordinate Issuing CA Certificate.

  16. Configure Certificate Revocation and CA Certificate Validity Periods.

  17. Enable Auditing on the Issuing CA.

  18. Configure the AIA and CDP.

  19. Install and configure the Online Responder Role Service.

  20. Add the OCSP URL to the subordinate Issuing CA.

  21. Configure and publish the OCSP Response Signing Certificate on the subordinate Issuing CA.

  22. Configure Revocation Configuration on the Online Responder.

  23. Configure Group Policy to provide the OCSP URL for the subordinate Issuing CA.

  24. Export Root CA in .der format and convert the format to .pem.

  25. Export personal certificate (that was signed by subordinate CA) with private key and place it on a PKI device.

Disabling the Key-Pair Option

The Allow key-pair option is enabled by default. This indicates that the enrollment of the PKI method can be done with either the CA certificates or through the key-pair generation. However, you can disable the key-pair based enrollment of the PKI device and enforce PKI enrollment only using a user certificate issued by the CA. To disable this option, set Allow key-pair to OFF.

Virtual Smartcard

Virtual Smartcard is an extension of PKI method. Advanced Authentication allows users to enroll the PKI method using a virtual smartcard that is imported to the browser on the user’s system and used for authentication. Virtual smartcard is a certificate that contains information such as digital signature, expiration date, name of user, name of CA (Certificate Authority), and can be used in client SSL certificate. Typically, the certificate is available in .pfx format. The information available in the virtual smartcard is used to authenticate the user to any web environment.

NOTE:The virtual smartcard supports authentication to the OAuth 2.0 and SAML 2.0 events. The virtual smartcard does not support authentication to Advanced Authentication portals, such as Administration, Helpdesk, Self-Service, and Reporting.

To configure the virtual smartcard, perform the following steps:

NOTE:Before you configure the virtual smartcard support for the SAML 2.0 events, ensure to specify the Identity Provider’s URL in format https://webauth.domain_name in the Web Authentication policy. Later, save the settings before downloading the SAML 2.0 metadata file.

NOTE:Before you configure virtual smartcard support for the PKI method, ensure to perform the following tasks:

  • Resolve the IP address of Advanced Authentication server with the following host names on the DNS server:

    • <aaserver_ip_address> <aaserver_hostname>

    • <aaserver_ip_address> <webauth.aaserver_hostname>

  • Define the following attributes in the third-party application that you want to integrate with Advanced Authentication server:

    • authorization_endpoint = https://webauth.aaserver_hostname/osp/a/TOP/auth/oauth2/grant

    • token_endpoint = https://webauth.aaserver_hostname/osp/a/TOP/auth/oauth2/getattributes

  1. Configure the following settings in the HTTPS Options policy:

    • Set Enable Client SSL for Webauth Service to ON and upload Root CA certificate in the .pem format that is used by the Web server.

    • Set Enable auto enrollment based on certificate to ON. This enables you to allow users to auto-enroll the PKI method using virtual smartcard for the OAuth 2.0 and SAML 2.0 events.

      NOTE:The manual enrollment of the PKI method using the virtual smartcard is not supported. Therefore, it is required to set Enable auto enrollment based on certificate to ON in the HTTPS Options. With this configuration, the users can auto-enroll PKI method using virtual smartcard when they access OAuth 2.0 event for the first time and select a valid certificate. This auto-enrollment happens irrespective of enrollment status of other method(s) that are available with the PKI method in the same authentication chain.

      To allow a user to login to the OAuth 2.0 and SAML 2.0 events before auto-enrolling the PKI method, ensure to add at least one more chain to the event (for example, a chain with only the LDAP Password method) below the PKI chain. The user must enroll all method(s) of new chain. During the first login attempt, the PKI method using the virtual smartcard gets enrolled automatically. For the sub-sequent log ins, the top chain in the list (which is PKI) is selected and user is authenticated automatically.

  2. Upload Root CA certificate in the Trusted root certificates section of PKI method.

  3. Import the client SSL certificate to the users browser.

    NOTE:The procedure to import the client SSL certificate varies on each browser.

    For more information about how to import the client SSL certificate to the Chrome browser, see Importing Client SSL Certificate to a Certificate Store.

An Example of Auto-enrolling PKI Method with the Virtual Smartcard

Consider the administrator has performed the following steps to allow auto-enrollment of the PKI method using the virtual smartcard:

  • Created a chain with the PKI method and another chain with preferred methods such as LDAP password and Password.

  • Mapped the chain to the OAuth 2 event.

  • Configure the following settings in the HTTPS options policy:

    • Set Enable SSL Client Certificate to ON and uploaded a valid CA certificate.

    • Set Enable Auto Enrollment based on certificate to ON.

  • Imported the client certificate to the user’s browser in the .pfx format containing details, such as digital signature, expiration date, name of user, name of CA and so on.

Mark, an end user, wants to auto-enroll the PKI method using the virtual smartcard. When he tries to access the somecompany.com website, the user name stored in the certificate gets filled in the user name field in the login form automatically. Mark is required to select the preferred certificate to validate his identity in the User Identification Request dialog box. Then, Mark must specify LDAP details for additional validation. If the specified details are valid, Mark gets auto-enrolled to the PKI method using the virtual smartcard without physical PKI token.

During subsequent logins, Mark may experience one of the following scenario:

  • If there is a chain with only PKI method associated to the web authentication event, then Mark gets authenticated automatically.

  • If there are more than one chain associated to the web authentication event, then Mark is prompted with the list of chains that contains PKI in addition to other available chains. In this case, he can select the chain with only PKI method to authenticate automatically or select preferred chain and provide corresponding details to authenticate successfully.

Importing Client SSL Certificate to a Certificate Store

To enable and achieve the virtual smartcard authentication to the web environment, it is required to import the Client SSL certificate to the browser.

NOTE:The procedure to import the client SSL certificate varies on each browser.

To import the client SSL certificate to Google Chrome browser, perform the following steps:

  1. Navigate to Settings > Manage Settings.

    The Certificates wizard is displayed.

  2. Click Import and select the client SSL certificate.

    Ensure that the certificate is in .pfx format.

  3. Click Next and Finish.

    A message Certificate has been imported successfully is displayed.

5.4.13 RADIUS Client

In the RADIUS Client method, Advanced Authentication forwards the authentication request to a third-party RADIUS server. This can be any RADIUS server. For example, you can use RADIUS Client as an authentication method when you have a token solution such as RSA or Vasco. You want to migrate users to Advanced Authentication with the flexibility that users can use the old tokens while the new users can use any of the other supported authentication methods.

You can configure the following options for the RADIUS Client method:

  • Send the repository name: Option for a repository name to be used automatically with a username. For example, company\pjones. Set to ON to enable the option.

  • NAS Identifier: An attribute that contains a string identifying the NAS originating the Access-Request. It is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier must be present in an Access-Request packet.

  • Timeout: Specify the number of seconds till when the RADIUS client waits for the RADIUS server to reply before prompting an error Connection time out. The default value is 5 seconds.

  • Retries count: Specify the number of times, the RADIUS client tries to connect to the RADIUS server. If a connection is not established during the retry attempts, a message Failed to connect to the server is displayed. The default value is set to 3. If set to 0, the RADIUS client does not try to connect after the first unsuccessful attempt.

  • Specify servers per site: Option to configure the third-party RADIUS servers that are specific to a site. When set to ON, the sites available in the cluster are populated and you can add more than one servers to the preferred site.

    When this option is set to OFF, you can add single third-party RADIUS server details that are applicable for all sites in the cluster by specifying the following details:

    • Server: The Hostname or IP address of the third-party RADIUS server.

    • Secret: The shared secret between the RADIUS server and Advanced Authentication.

    • Port: The port to where the RADIUS authentication request is sent. The default port is 1812.

5.4.14 Security Questions

In Security Questions authentication method, an administrator can set up a series of predefined questions. A user must answer these questions to get authenticated. Security Questions are used when users forget their passwords.

Security questions are often easy to guess and can often bypass passwords. Therefore, Security Questions do not prove to be secure.

You must follow few guidelines to use this method. You must use Good security questions that meet five criteria. Ensure that the answers to a good security question are:

  1. Safe: Cannot be guessed or researched.

  2. Stable: Does not change over time.

  3. Memorable: Can be remembered.

  4. Simple: Precise, easy, and consistent.

  5. Many: Has many possible answers.

Some examples of good, fair, and poor security questions according to goodsecurityquestions.com are as follows. For a full list of examples, see the website

GOOD

  • What is the first name of the person you first kissed?

  • What is the last name of the teacher who gave you your first failing grade?

  • What is the name of the place your wedding reception was held?

  • In what city or town did you meet your spouse/partner?

  • What was the make and model of your first car?

FAIR

  • What was the name of your elementary / primary school?

  • In what city or town does your nearest sibling live?

  • What was the name of your first stuffed animal, doll, or action figure?

  • What time of the day were you born? (hh:mm)

  • What was your favorite place to visit as a child?

POOR

  • What is your pet's name?

  • In what year was your father born?

  • In what county where you born?

  • What is the color of your eyes?

  • What is your favorite _____?

Configure the following options for the Security Questions method:

  • Minimum answer length: The minimum number of characters an answer must contain.

  • Correct answers for logon: The number of answers a user must answer correctly to get access.

  • Total questions for logon: The number of questions that are presented to the user while authenticating.

For example, if the Correct answers for logon is set to 3 and the Total questions for logon is set to 5, the user needs to specify only 3 correct answers out of a set of 5 questions.

Adding Questions

You can add questions based on your requirement. These questions can be translated in languages that are supported by the Advanced Authentication portals. For example, you set a security questions as What is your pet name?. While enrolling and authenticating, this question will be displayed in the language that the user selects in the portal.

To add questions, perform the following:

  1. Click Add to add a question in the Question window.

  2. Specify the question in Question.

  3. You can specify the question to be translated in the required language.

    This translated question is displayed in the portals and Clients based on the selected language.

  4. Click the save icon to save the question related settings.

You can add more questions depending on the requirement.

Click Save to save the configuration settings for the Security questions method.

5.4.15 Smartphone

Advanced Authentication provides the Smartphone method that facilitates users to authenticate through their Smartphone. The authentication happens through the NetIQ smartphone app to perform the out-of-band authentication. The out-of-band authentication is typically a two-factor authentication that requires a secondary verification through a separate communication channel along with the ID and password.

The authentication flow for the Smartphone method in Advanced Authentication is described in the following image.

A user wants to authenticate on an endpoint such as a laptop or a website with the Smartphone method. The following steps describe the authentication flow:

  1. When the authentication request is initiated, the endpoint contacts the Advanced Authentication server.

  2. The Advanced Authentication server validates the user’s credentials.

  3. After validating the credentials, the Advanced Authentication server sends a push message to proxy.authasas.com.

  4. Depending on the platform of the Smartphone, the server selects an appropriate push service and then forwards the push message to the Smartphone.

  5. The push message is then delivered to the user’s Smartphone to inform that an authentication request has been initiated.

  6. When the user opens the Smartphone app, the app reaches the Advanced Authentication server to validate if there is an authentication needed. The authentication is indicated by the Accept and Reject options. The user’s selection is then sent to the server.

  7. Finally, the server validates the authentication and the endpoint gets authenticated.

HTTPS protocol is used for the communication.

This authentication method is recommended to use in combination with another method such as Password or LDAP Password to achieve multi-factor authentication and protect a user from getting SPAM push messages.

Access Configurations

The following are the configurations required for the Smartphone method.

  • Advanced Authentication server must be accessible by the specified Server URL address from smartphones (HTTPS, outbound).

  • Advanced Authentication server must have a permitted outbound connection to proxy.authasas.com (HTTPS).

Scenario for Authenticating with the Smartphone Method

Bob wants to authenticate on the myexample.com website. When he logs in to the website, the Smartphone authentication method sends a push message to Bob’s mobile phone. When he opens the Smartphone app installed on his phone, he sees Accept and Reject options. If he selects the Accept option, the authentication request is sent over the mobile network (secure) back to the Authentication framework. Without specifying an OTP code, Bob has been authenticated to myexample.com.

When your smartphone does not have a network connection, you can use a backup OTP as offline authentication.

Configuring Enrollment Link

Users can enroll the Smartphone method either by a QR code or through a link sent to their email or SMS. You as an administrator must configure the link and send it to all the users whom you want to enroll the authenticator. You can use one of the following links as per the requirement:

https://<public_external_url>/smartphone/enroll

https://<public_external_url>/smartphone/enroll?category=cat1

https://<public_external_url>/smartphone/enroll?tenant=t1

https://<public_external_url>/smartphone/enroll?category=cat2&tenant=t1

Default category is default. Default tenant is TOP.

For more information about how to set the public external URLs, see Public External URLs (Load Balancers).

Configuring Smartphone Method

To configure the Smartphone method, specify the following details:

Parameter

Description

Push salt TTL

The lifetime of an authentication request sent to the smartphone.

Learn timeout

The time that is valid for the user to scan the QR code for enrollment.

Authentication salt TTL

The lifetime in which the out-of-band authentication needs to be accepted before authentication fails.

TOTP Length

The length of OTP token used for backup authentication.

TOTP step

The time a TOTP is displayed on a screen before the next OTP is generated. The default time is 30 seconds.

TOTP time window

The time in seconds in which the TOTP entered is accepted. The default time is 300 seconds.

Server URL

The URL of Advanced Authentication server to where the smartphone app connects for authentication.This URL points to the Public External URLs (Load Balancers) policy. For example, http://<AAServerAddress>/smartphone (/smartphone cannot be changed). Use http only for testing and https in a production environment. You need a valid certificate when using https.

Require PIN

Set to ON to enforce the Enable PIN setting for the Smartphone application. A user will not be able to edit the settings on the Smartphone

NOTE:If the PIN is not set, then the user is prompted to set the PIN during authentication.

Minimum PIN length if the PIN is required

The minimum length of the PIN. The available options are 4,5, and 6.

Require biometrics

Set to ON to enforce the fingerprint setting for the Smartphone application. A user will not be able to edit the settings on the Smartphone.

Enroll TOTP method when enrolling Smartphone

Set to ON to enable enrolling the TOTP method automatically during the Smartphone method enrollment. The TOTP method is used in the offline mode authentication.

Prevent login from a rooted device

Set to ON to enable a root check for mobile devices.

The smartphone app must detect whether the device is rooted and prevent login from that device. Rooted devices can provide administrative privileges to third-party software that is not secured and mostly not allowed by device vendors.

Use image on mobile devices

Select the option to use a customized image on your Smartphone app.

Browse the image. This image is displayed in the About screen of your Smartphone app. The resolution of the image must be 2732×637 pixels.

NOTE:The Require PIN, Require biometrics, and Use image on mobile devices policies are automatically applied on the smartphone if a user has an enrolled authenticator in the smartphone app and the app is open on one of the screens: Authentication Requests, Enrolled Authenticators, or Requests History. It takes 2 to 30 seconds to display the authentication request.

  • If a user has configured a 4-digit PIN but a 6-digit PIN has been enforced by the administrator, then the user will be able to use the 4-digit PIN until the user decides to change the PIN.

  • If Require biometrics is set in the policies, but a user’s device does not support fingerprint, the policy will not be applied for the device.

  • If a user has authenticators enrolled for two different Advanced Authentication servers with different policies, then the policies are combined for the device and the most secure policies are applied for the app.

Disable offline authentication

Select this option to disable users from authenticating using the Smartphone TOTP. By default this option is disabled and users can login using Smartphone even when Smartphone is not connected to a network. Enabling this option will disallow users to use the One-Time Password of the Smartphone method to login to the offline mode.

Advanced Settings

  • Vendor

  • Google project ID

These settings are optional.

If you have an approved vendor whose certificate is uploaded to proxy.authasas.com, you can specify the Vendor ID of your iOS app or specify the Google Project ID for your Android app. The push notifications will be sent only to the app whose Vendor name or Google Project ID matches with the app.By default Advanced Authentication works with the NetIQ Auth apps.

Geo Zones

You can configure Geo-fencing with the Smartphone method. Geo-fencing allows you to authenticate with the Smartphone method with one more factor, which is the geographical location. When you enable geo-fencing, users will be able to authenticate with Smartphone from only allowed geographical locations. You must enable the policy Geo Fencing Options to use geo-fencing.

To configure geo-fencing, you need to draw a boundary of the location to be authenticated with a polygon. To configure geo-fencing, perform the following steps:

  1. Click Add.

  2. Specify the name of the zone.

  3. Click the Search icon and specify the address to locate the required geographical location.

    You can click the full-screen icon to view the map in the full screen.

  4. Click the polygon icon in the menu bar of the map.

  5. Click the starting point on the map and draw the boundary of the specific location to be authenticated.

  6. Click to mark the end point of the boundary after you have finished drawing the geo zone.

    You can also edit the marked polygon by clicking the edit icon.

  7. Click Save.

NOTE:To use geo-fencing, ensure that access to the location is enabled for the NetIQ Advanced Authentication app on the smartphone.

NOTE:You can customize the authentication request message that is displayed on the NetIQ Auth app using the Custom Messages policy.

For more information about customizing the authentication request message, see Customizing Authentication Request Message For Smartphone Method.

5.4.16 SMS OTP

In the SMS OTP authentication method, a one time password (OTP) is sent with the SMS text to the user’s phone. The user receives the OTP and enters it on the device where the authentication is happening. The OTP must be used within a specific time frame. The OTPs delivered through text messages prevent phishing and malicious attacks. SMS OTP is recommended to be used with other methods, such as Password or LDAP Password.

NOTE:In the User’s settings of a repository, ensure that a phone number without extension is used. An SMS is not sent to the user’s mobile where the phone number contains an extension.

To configure the SMS OTP method, specify the following details:

  • OTP Period: The lifetime of an OTP in seconds. The default value is 120 seconds.The maximum value for the OTP period is 360 seconds.

  • OTP format: The number of digits in the OTP. The default value is 6.

  • Body: The text in the SMS that is sent to the user. The following structure describes the text in the OTP:

    • {user}: Name of the user.

    • {endpoint}: Device the user is authenticating to.

    • {event}: Name of the event where the user is trying to authenticate to.

    • {otp}: One-Time Password.

  • User cell phone attribute: The cell phone number of a user on which the OTP is sent through SMS. You can use custom attributes such as mobile, homePhone, ipPhone, and other attributes of a repository. You must define the attribute in User Cell Phone Attributes of the Repositories section.

    NOTE:If you do not configure the attribute in the method settings, then the first attribute defined in the User Cell Phone Attributes section of Repository configuration is used when the user tries to authenticate. For example, if you define mobile as the first attribute in User cell phone attribute and do not configure the attribute in method settings of SMS OTP, then while authenticating, the first attribute, which is the mobile attribute, is used for the SMS OTP method authentication.

  • Allow overriding phone number: Option that allows to prevent users from providing a phone number that is not registered in the LDAP repository. The option is set to ON by default. Set to OFF to prevent users to specify a different phone number during the enrollment.

  • Allow user enrollment without a phone: Option to configure settings for the user to enroll the SMS OTP authenticator without a phone number in the repository.

    Set this option to OFF to ensure that a user does not enroll the SMS OTP authenticator without a phone. The user gets an error message that you can specify in Error message.

    Set this option to ON to allow the user to enroll the SMS OTP authenticator without a phone.

5.4.17 Swisscom Mobile ID

In the Swisscom Mobile ID authentication method, a PKI- based mobile signature secure encryption technology is stored on a user’s SIM card. When the user tries to authenticate, the Swisscom Mobile ID is validated against the user’s mobile phone attribute in the repository. If the number is validated, the user gets authenticated.

To configure the Swisscom Mobile ID method, specify the following details:

  • Application Provider ID: Identifier of the application provider.

  • Application Provider password: Password of the application provider.

  • Swisscom Mobile ID service URL: Interface of the Swisscom Mobile ID.

  • Notification message prefix: Message that is displayed on the user’s mobile as a notification.

In addition, you can upload the Swisscom client certificates as follows:

  1. Browse Client SSL certificate. The required certificate must be in a .pem format and self-signed with a private key.

  2. Specify Private key password for the certificate.

  3. Click Save.

NOTE:Users must activate the Mobile ID service for the Swisscom SIM card.

For more information about the Swisscom Mobile ID method, see the Mobile ID Reference guide.

5.4.18 FIDO U2F

With the FIDO U2F authentication method, users can authenticate with the touch of a finger on the U2F device.

Advanced Authentication supports the Microsoft policy Interactive logon: Smart card removal behavior that allows you to specify an action on the U2F. You can configure the policy to perform a force log off or lock a session when a user removes the U2F device from a computer. This policy is supported for Windows only. When the user removes the U2F device from the computer, the Windows Client runs an action that is specified in the Interactive logon: Smart card removal behavior policy.

IMPORTANT:To use the FIDO U2F authentication for Access Manager in the OAuth 2.0 event, you must configure an external web service to perform enrollment and authentication for one domain name. For more information, see Configuring a Web Server to Use the FIDO U2F Authentication.

The YubiKey tokens may flash with a delay when the token is initialized in a combination mode. For example, when authentication uses OTP and U2F methods. This may cause the users to wait for the token to flash before enrollment or authentication. Therefore, it is recommended to flash the tokens only in the U2F mode if the other modes are not needed.

You can configure the following settings for this method:

Configuring the Certificate Settings

You can configure certificate settings for the FIDO U2F authentication method. By default, Advanced Authentication does not require the attestation certificate for authentication by the FIDO U2F compliant token. Ensure that you have a valid attestation certificate added for your FIDO U2F compliant token, when you configure this method. The Yubico and Feitian attestation certificates are pre-configured in the Advanced Authentication appliance.

To validate the attestation certificate for the FIDO U2F authentication, perform the following steps:

  1. Set Require attestation certificate to ON to enable validation of attestation certificate.

  2. Select the attestation certificate:

    1. To use a default certificate, click Add Default.

    2. To use a custom certificate instead of predefined device manufacturer certificate, perform the following steps:

      1. Click next to the default attestation certificate to remove the certificate.

      2. Click Add to add a custom certificate.

      3. Click Browse then select the custom certificate and click Upload.

        The certificate must be in the PEM format.

    To restore the deleted attestation certificate, click Add Default.

Configuring Facets

You can add a list of facets for the FIDO U2F tokens to work on multiple sub-domains of a single domain.

Previously, the U2F RFC standards allowed authentication only on the domain name on which the enrollment was done. But with the FIDO U2F standards update , the FIDO alliance introduces facets that allows users to authenticate even on domains on which the enrollment is not done.

For example, if a user enrolls a token on https://mytest.com and wants to get authenticated on https://u2f.mytest.com, you as an administrator can do this by adding https://u2f.mytest.com as a facet of the primary domain https://mytest.com.

WARNING:Even if you are not using the facets, ensure to configure Facets to enable users to authenticate with the FIDO U2F method. If the Facets is not configured, then while authenticating with FIDO U2F, the user is prompted with a message The visited URL doesn't match the application ID or it is not in use.

To add facets, perform the following steps:

  1. Expand Facets settings.

  2. Specify the facet in Facets. For example, you can specify https://u2f.mytest.com.

  3. Click Add to add more facets.

  4. Specify the main URL in App ID. This ID is used to identify applications. For example, https://mytest.com.

    If the App ID is left blank, the first facet is used as the App ID.

    From the above example, if a user logs in to https://u2f.mytest.com with the U2F token enrolled on https://mytest.com, the browser sends a plain GET request to the https://URL/<tenant-ID/app-id.json URL and waits for the list of allowed facets (sub-domains). If the list is returned, browser allows the user to use token on the URLs specified in the Facets list.

    To ensure that FIDO U2F works on Chrome on the URL that is specified as the App ID, you must add this URL to Facets.

  5. Click Save.

NOTE:Facets are supported only on Google Chrome. The support for sub-domains is not stabilized in Chrome, therefore you might get an error message The visited URL doesn't match the application ID or it is not in use during enrollment and authentication.

Configuring Yubikey for Advanced Authentication Server

  1. Download and install the Yubikey Personalization Tool from Yubico.

    To download the Yubikey Personalization Tool, see the Yubico website.

  2. Insert the Yubikey token.

    Ensure that the token is recognized. The recognition is indicated by a message Yubikey is inserted at the top-right corner of the Personalization tool.

  3. Select Yubico OTP mode.

  4. Select Configuration Slot 1, generate the Public Identity, Private Identity, and Secret Key.

  5. Click Write Configuration and specify the configurations.

  6. Open the Advanced Authentication Self-Service portal and select U2F method.

  7. Click Save to complete the enrollment.

Configuring a Web Server to Use the FIDO U2F Authentication

This section is applicable for Debian 8 Jessie. The procedure may differ for other distributives.

This sections explains how to configure web server to use the FIDO U2F authentication in NetIQ Access Manager for the OAuth 2.0 event.

According to the FIDO U2F specification, both enrollment and authentication must be performed for one domain name. As NetIQ Access Manager and Advanced Authentication appliance are located on different servers, you must configure web server to enable performing the following actions:

  • Port forwarding to Advanced Authentication appliance for the FIDO U2F method enrollment

  • Port forwarding to NetIQ Access Manager for further authentication using FIDO U2F tokens

Perform the following actions to configure a web server to use the FIDO U2F authentication.

Installing Nginx Web Server

You must install the Nginx web server for URL forwarding.To install Nginx, add the following two lines to the /etc/apt/sources.list file:

deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all

Preparing SSL Certificate

Run the following commands:

mkdir –p /etc/nginx/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/proxy.key -out /etc/nginx/ssl/proxy.crt

Preparing Nginx Proxy Configuration

Add the following to the /etc/nginx/sites-available/proxy file:

server {
listen 443 ssl;
error_log /var/log/nginx/proxy.error.log info;
server_name nam.company.local;
ssl_certificate /etc/nginx/ssl/proxy.crt;
ssl_certificate_key /etc/nginx/ssl/proxy.key;
location ~ ^/account {

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass https://<appliance_IP>$uri?$args;
}
location ~ ^/static {

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass https://<appliance_IP>$uri?$args;
}
location ~ ^/admin {

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass https://<appliance_IP>$uri?$args;
}
location / {

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_read_timeout 300;
proxy_pass https://<NAM_IP>;
}
}

Create a link and restart the nginx service running the following commands:

ln -s /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy
service nginx reload

Adding DNS Entries

Ensure that the NetIQ Access Manager name server corresponds to the IP address of web server.

Enrolling U2F FIDO

To enroll U2F, open the link https://<NAM_FQDN>/account. The Self-Service portal of Advanced Authentication server appliance is displayed.

Enroll the U2F method in the Self-Service portal. For information about enrolling, see Enrolling the Authentication Methods.

5.4.19 Voice

In the Voice authentication method, a user receives a call with a PIN request, after which the user must specify the PIN on his or her phone.

The following workflow describes the Voice authentication method in Advanced Authentication:

  1. A user tries to authenticate with the Voice method.

  2. The user receives a call on the phone with a PIN request.

  3. User must specify the PIN that has been enrolled in the Self-Service portal during the enrollment.

  4. After the user specifies the PIN followed by a hash (#) symbol, user is authenticated with the Voice method.

IMPORTANT:Phone number with extensions are supported for this method.

Special characters , and x are used to indicate wait time and can be used as separators between phone number and extension.

For example, if +123456789 is the phone number and 123 is the extension, then it can be specified as +123456789,,,,123.

In the above example, , is specified 4 times and this multiplied by 0.5 (default value in Twilio) indicates the wait time, which is 2 (4*0.5) seconds. First, call is sent to the number 123456789 and after a wait period of 2 seconds, the extension 123 is dialed.

To configure the Voice method, specify the following details:

  • Minimum PIN length: The length of the PIN must be at least three characters long.

  • Maximum PIN age: The validity period of a PIN. The default value is 42 days. If you set the age to 0, the PIN will not expire.

  • User cell phone attribute: The cell phone number of a user that is used to call the user for voice authentication. You can use custom attributes such as mobile, homePhone, ipPhone, and other attributes of a repository. You must define the attribute in User Cell Phone Attributes of the Repositories section.

    NOTE:If you do not configure the attribute in the method settings, then the first attribute defined in the User Cell Phone Attributes section of Repository configuration is used when the user tries to authenticate. For example, if you define mobile as the first attribute in User cell phone attribute and do not configure the attribute in method settings of Voice, then while authenticating, the first attribute, which is the mobile attribute, is used for the Voice method authentication.

  • Allow overriding phone number: Option that allows to prevent users from providing a phone number that is not registered in the LDAP repository. The option is set to ON by default. Set to OFF to prevent users to specify a different phone number during the enrollment.

  • Allow user enrollment without a phone: Option to configure settings for the user to enroll the Voice authenticator without a phone number in the repository.

    Set this option to OFF to ensure that a user does not enroll the Voice authenticator without a phone. The user gets an error message that you can specify in Error message.

    Set this option to ON to allow the user to enroll the Voice authenticator without a phone.

IMPORTANT:Advanced Authentication does not notify a user about the expiry of a PIN.

5.4.20 Voice OTP

In the Voice OTP authentication method, a user receives an OTP over a call. The user must specify this OTP on the device where the authentication is happening. The OTP must be used within a specific time frame. Voice OTP is recommended to use with other methods, such as Password or LDAP Password.

To configure the Voice OTP method, specify the following details:

  • OTP period: The time period for which the Voice OTP is valid. Default time is 120 seconds. The maximum value for the Voice OTP period is 360 seconds.

  • OTP format: The length of the Voice OTP token. Default length is 4.

  • Body: The text or number in the Voice OTP that is sent to the user. Here, you can specify the {otp} variable, which is the actual one-time password. To repeat the one-time password during the call you can specify: Use the OTP for authentication: {otp}. OTP: {otp}.

  • User cell phone attribute: Cell phone number of a user that is used to send the OTP through a call. You can use custom attributes such as mobile, homePhone, ipPhone, and other attributes of a repository. You must define the attribute in User Cell Phone Attributes of the Repositories section.

    NOTE:If you do not configure the attribute in the method settings, then the first attribute defined in the User Cell Phone Attributes section of Repository configuration is used when the user tries to authenticate. For example, if you define mobile as the first attribute in User cell phone attribute and do not configure the attribute in method settings of Voice OTP, then while authenticating, the first attribute, which is the mobile attribute, is used for the Voice OTP method authentication.

  • Allow overriding phone number: Option that allows to prevent users from providing a phone number that is not registered in the LDAP repository. The option is set to ON by default. Set to OFF to prevent users to specify a different phone number during the enrollment.

  • Allow user enrollment without a phone: Option to configure settings for the user to enroll the Voice OTP authenticator without a phone number in the repository.

    Set this option to OFF to ensure that a user does not enroll the Voice OTP authenticator without a phone. The user gets an error message that you can specify in Error message.

    Set this option to ON to allow the user to enroll the Voice OTP authenticator without a phone.

5.4.21 Web Authentication Method

Advanced Authentication facilitates you to authenticate with different Identity Providers such as OAuth 2.0, OpenID Connect, and SAML 2.0 with the Web Authentication method. The Web Authentication method uses browser and http based authentication protocols and can be used in web environment or hybrid applications.

Before you configure the Web Authentication method, ensure that you set the correct Public external URLs (load balancers) that provisions Advanced Authentication to the users.

NOTE:Ensure that you use a valid certificate for the Advanced Authentication server. Users may face enrollment issues on the Internet Explorer and Microsoft Edge browsers, if the certificates are not valid.

To configure the Web Authentication method for Advanced Authentication, perform the following steps:

  1. Click Methods > Web Authentication.

  2. Click Add in Identity providers.

  3. Select the Authentication type.

  4. Click the arrow icon.

You can configure the Web Authentication method to use the following Identity Providers:

SAML for Advanced Authentication

To add the SAML Identity Provider, perform the following steps:

  1. Specify the identity provider name in Identity Provider.

  2. Select the Available presets for Name ID Format.

    The Name ID Format is automatically populated.

    or

    Specify manually in Name ID Format.

  3. Click Browse to upload the Identity Provider Metadata file.

    WARNING:Ensure that you choose the Identity Provider Metadata file that is exported from a used Identity Provider. Do not use the metadata file exported from the Administrative Portal > Policies > Web Authentication.

  4. Click the save icon.

  5. In the Upload SAML Service Provider signature certificate section, you must upload a certificate file in the PEM format with a private key. This certificate is used by the Web Authentication method to sign a SAML AuthnRequest token.

    If the private key is protected by a password, specify the password in Private key password.

  6. Click Save.

An Example Configuration with ADFS

Perform the following steps to add ADFS as an Identity Provider for the Web Authentication method.

  1. Specify myexample-adfs as the IdP provider name.

  2. Select urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName from Available presets for Name ID Format.

    The selected Name ID Format will be extracted from the SAML AuthnResponse token and saved as an authentication data (unique data which will be associated with the user).

  3. Click Browse to upload the IdP Metadata file from the ADFS server.

  4. Click the save icon.

  5. In the Upload SAML Service Provider signature certificate section, upload a certificate file in the PEM format with a private key.

    If the private key is protected by a password, specify the password in Private key password.

  6. Click Save.

Configuring the ADFS Identity Provider

  1. Save the Service Provider metadata from Advanced Authentication to a file. Use the URL mentioned below to obtain the Service Provider metadata:

    https://AAF_SERVER/webauth/TENANT/metadata

    NOTE:The default TENANT is TOP. Use TOP as TENANT if you are not using multi-tenancy.

    A sample Service Provider metadata is mentioned below:

    <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_7a8608ad1cfbc149" entityID="https://www.d18r14.tk/webauth">
    <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
    <md:KeyDescriptor>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:KeyName>https://www.d18r14.tk/webauth</ds:KeyName>
    <ds:X509Data>
    <ds:X509Certificate>
    MIIEOzCCAyOgAwIBAgIJAJcsrIQZzcT0MA0GCSqGSIb3DQEBCwUAMIGyMQswCQYD
    VQQGEwJDSDEcMBoGA1UECAwTR3JlYXRlciBadXJpY2ggQXJlYTEPMA0GA1UEBwwG
    WnVyaWNoMRcwFQYDVQQKDA5NaWNybyBGb2N1cyBBRzERMA8GA1UECwwIQXV0aGFz
    YXMxFzAVBgNVBAMMDm1pY3JvZm9jdXMuY29tMS8wLQYJKoZIhvcNAQkBFiBhbGV4
    YW5kZXIuZ2FsaWxvdkBtaWNyb2ZvY3VzLmNvbTAgFw0xNjA1MjAwOTMyMzlaGA8y
    MTE2MDQyNjA5MzIzOVowgbIxCzAJBgNVBAYTAkNIMRwwGgYDVQQIDBNHcmVhdGVy
    IFp1cmljaCBBcmVhMQ8wDQYDVQQHDAZadXJpY2gxFzAVBgNVBAoMDk1pY3JvIEZv
    Y3VzIEFHMREwDwYDVQQLDAhBdXRoYXNhczEXMBUGA1UEAwwObWljcm9mb2N1cy5j
    b20xLzAtBgkqhkiG9w0BCQEWIGFsZXhhbmRlci5nYWxpbG92QG1pY3JvZm9jdXMu
    Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5ZjKCY2x2ruYkW8e
    /IgOa5y9xqSx4bUogYuZnAwLgZH2EIEx54T1YzKKc6a58t9tFU0Xb1Z47ay57g/B
    A1oOOV4HOsl6SRG4lJojiOKSpLb1zZMqj3s1dd9hLE9KuScchApcJ5F8GxPf6YHO
    VpY4d6e6Z+fS071lK3UHpjbLQ71yoDV+s+wJ+pmgsLxiyV/7A+CurxixibyXKx2x
    jHvynZBPWf1P/goi54gbCZ1PjQnRPKfxUzRvWipH8T2xvfT0UAZL3HO8C6JJGZxQ
    t82lw/za9tADH0CxPolL/JJyHeEGJAj07uw1wks6mEv8wZY5KkhuDpVv6BUl146+
    tL5LSQIDAQABo1AwTjAdBgNVHQ4EFgQUoeHvvSDZn/GIul8Q6T0yleN9q48wHwYD
    VR0jBBgwFoAUoeHvvSDZn/GIul8Q6T0yleN9q48wDAYDVR0TBAUwAwEB/zANBgkq
    hkiG9w0BAQsFAAOCAQEAQ+T4XForCi/FFSpNLVxb7x/yO1eBi7JujH7CfNTKXUC3
    STlTZiJaTLVXzNd9dvxSjzAoDy4NVV/T4KiA4ss7JCTPwGrD3S8k/a+GpogRzRcE
    R1i/Z/bx2I4PmQk1g1z4lpuqnic0aIg/OVAE0+kwDBK3E0/pgpoSixAAvxEqM5tw
    X9vdt3W/QCoAO3rFABRDboaLkslGbk80Q37tEASKFYm4/0fyB3PEv2uL0S6rP/+E
    Fp1Xhlk/5MVRHNb0hLqpZmJxne96dnXpo+ZDeCCn87B3257eRFI1eUeAnxuw79vv
    uterPobGSjjPm+y7sY2U3hLKsoVymRvqAohrd9kXSQ==
    </ds:X509Certificate>
    </ds:X509Data>
    </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.d18r14.tk/webauth/callback" index="0"/>
    </md:SPSSODescriptor>
    </md:EntityDescriptor>
  2. In the ADFS Management console, click Relying Party Trusts > Add relying party trust.

  3. In the Add Relying Party Trust wizard, click Start.

  4. Select Import data about the relying party from a file.

  5. Click Browse to upload the Advanced Authentication’s metadata file that you created in Step 1.

  6. Click Next.

  7. Specify the Display name.

  8. Click Next.

  9. Ensure that Open the Edit Claim Rules dialog for this relying party trust when the wizard closes is selected.

  10. Click Close.

    The Edit Claim Rules wizard is displayed.

  11. Click Add Rule.

  12. Select Transform an Incoming Claim from Claim rule template.

  13. Click Next.

  14. Specify the Claim rule name.

  15. Set Incoming claim type to Windows account name.

  16. Set Outgoing claim type to Name ID and Outgoing name ID format to Windows Qualified Domain Name.

  17. Ensure that Pass through all claim values is selected.

  18. Click Finish.

  19. Click OK.

  20. In the ADFS Management console, click Relying Party Trusts and select the relying party trust you added.

  21. Right-click on the relying party trust and select Properties from the menu.

  22. In Properties, click the Encryption tab and remove the certificate by clicking Remove.

  23. Click OK.

    NOTE:Web authentication method does not support the encrypted tokens.

OpenID Connect for Advanced Authentication

To add the Open ID Connect Identity Provider, perform the following steps:

  1. Specify the name of the provider in Provider name.

  2. Select the Available presets.

    The Issuer, Scope, and Key field are automatically populated.

  3. Specify the Client ID and Client secret.

    The Client ID and Client secret can be obtained by registering with the respective Identity Provider that you select, for more information see Integrating Third Party Applications with Advanced Authentication Using OpenID Connect.

    NOTE:Set the Callback URL at the respective Identity Provider. For example, https://<aahostname>/webauth/callback.

  4. Turn Send Client secret as an URL parameter to ON to send the Client secret as a URL. By default, the option is set to OFF.

  5. Click the save icon.

  6. Click Save to save the method configuration.

Integrating Third Party Applications with Advanced Authentication Using OpenID Connect

The following sample configurations explains how to configure third party applications with Advanced Authentication using OpenID Connect.

Integrating Advanced Authentication with Facebook

Perform the following steps to integrate Advanced Authentication with Facebook using OpenID Connect:

  1. Login to facebook for developers.

  2. Click My Apps.

  3. In the left pane, click Settings > Basic.

  4. Make a note of App ID and App Secret. These are the Client ID and Client Secret for Advanced Authentication.

  5. In Display Name, specify Advanced Authentication. This is the name for this OpenID Connect configuration.

  6. In App Domains, specify the domain name of the Advanced Authentication Server. For example aafapp.demo.live.

  7. In Privacy Policy URL, specify the URL of the Advanced Authentication Server. For example aafapp.demo.live.

  8. Scroll through the page until you find the Website section. If you cannot find the Website section, click Add Platform > Website.

  9. In the Website section, specify the web address of the Advanced Authentication Server. For example aafapp.demo.live.

  10. Click Save Changes.

  11. In the left pane, click Settings > Advanced.

  12. Scroll through the page until you find the Domain Manager tab.

  13. Click Add a Domain.

  14. In the Add a Domain window, specify the URL of the Advanced Authentication Server in Site URL. For example aafapp.demo.live.

  15. Click Apply.

  16. Click Save Changes.

  17. In the left pane, click App Review.

  18. Make your application public by clicking the toggle switch in the Make Advanced Authentication public? section.

  19. In the left pane, below the Products tab, click Settings.

  20. In Valid OAuth Redirect URIs, specify https://<Advanced Authentication Server>/webauth/callback.

  21. Click Save Changes.

  22. Specify the Client ID and Client Secret generated in Step 4 in the Client ID and Client Secret fields of Advanced Authentication Administrative Portal.

Integrating Advanced Authentication with Google

Perform the following steps to integrate Advanced Authentication with Google using OpenID connect:

  1. Login to Google APIs.

  2. Click Credentials > Create.

  3. Specify a Project Name and a Location.

  4. Click Create.

  5. Click Create credentials > OAuth client ID.

  6. Click Configure a consent screen.

  7. Specify a name in the Application name field. For example Advanced Authentication.

  8. In Authorised domains, specify the domain name of the Advanced Authentication Server. For example aafapp.demo.live.

  9. In Application Homepage link, specify the web address of the Advanced Authentication Server. For example https://aafapp.demo.live.

  10. In Application Privacy Policy link, specify the web address of the Advanced Authentication Server. For example https://aafapp.demo.live.

  11. In Application type, select Web application.

  12. In Application Terms of Service link, specify the web address of the Advanced Authentication Server. For example https://aafapp.demo.live.

  13. In Name, specify a name for the OpenID Connect configuration.

  14. In Authorized JavaScript origins, specify the Advanced Authentication server address. Ensure that you specify the complete server address including https. For example https://aafapp.demo.live.

  15. In Authorized redirect URIs, specify https://<Advanced Authentication Server>/webauth/callback. Ensure that you specify the valid Advanced Authentication server name inside <>.

  16. Click Save.

  17. Make a note of the client ID and client secret specified in the OAuth client window. Click OK.

  18. Specify the Client ID and Client Secret generated in Step 17 in the Client ID and Client Secret fields of Advanced Authentication Administrative Portal.

Integrating Advanced Authentication with Yahoo

Perform the following steps to integrate Advanced Authentication with Yahoo using OpenID connect:

  1. Login to Yahoo Developer Network.

  2. Click Create an app.

  3. In Application Name, specify a name for the OpenID Connect configuration.

  4. In Application Type, select Web Application.

  5. In Callback Domain, specify the domain name of the Advanced Authentication Server. For example aafapp.demo.live.

  6. Click Create.

  7. Make a note of the client ID and client secret. Click Update.

  8. Specify the Client ID and Client Secret generated in Step 7 in the Client ID and Client Secret fields of Advanced Authentication Administrative Portal.

Integrating Advanced Authentication with Microsoft Azure

Perform the following steps to integrate Advanced Authentication with Microsoft Azure using OpenID connect:

  1. Login to Microsoft Azure.

  2. In the left pane, click Azure Active Directory.

  3. In the Manage section, click App registrations.

  4. Click New application registration.

  5. In Name, specify a name for the OpenID Connect configuration.

  6. In Application Type, select Web app / API.

  7. In Sign-on URL, specify https://<Advanced Authentication Server>/webauth/callback. Ensure that you specify the correct Advanced Authentication server address inside <>.

  8. Click Create.

  9. Make a note of Application ID. It is the Client ID for Advanced Authentication.

  10. Click Settings > Keys.

  11. In the Passwords section, specify key description and key duration.

  12. Click Save.

  13. Make a note of the text generated in the VALUE field. It is the Client Secret for Advanced Authentication.

  14. In the left pane, click Azure Active Directory.

  15. Click Properties.

  16. Make a note of the text specified in the Directory ID field.

  17. Specify the text generated in Step 16 in the Issuer field of Advanced Authentication Administrative Portal.

  18. Specify the Client ID generated in Step 9 and Client Secret generated in Step 13 in the Client ID and Client Secret fields of Advanced Authentication Administrative Portal.

OAuth 2.0 for Advanced Authentication

To add the OAuth 2.0 Identity Provider, perform the following steps:

  1. Specify the name of the provider in Provider name.

  2. Select the Available presets.

    The Authorization endpoint, Token endpoint, Attributes endpoint, Scope, and Key field are automatically populated.

  3. Specify the Client ID and Client secret.

    The Client ID and Client secret can be obtained by registering with the respective Identity Provider that you select.

    NOTE:Set the Callback URL at the respective Identity Provider. For example, https://<aahostname>/webauth/callback.

  4. Turn Send Client secret as an URL parameter to ON to send the Client secret as a URL. By default, the option is set to OFF.

  5. Select the format of the access token from Access token is returned in body encoded as.

  6. Set Send access token in "Authorization: Bearer" header to ON to send the access token as a header. By default, the option is set to OFF.

  7. Click the save icon.

  8. Click Save to save the method configuration.

5.4.22 Windows Hello

Windows Hello authentication allows the users to use the Windows Hello Fingerprint and Facial Recognition authentication to log in to Windows 10. Advanced Authentication supports the Windows Hello fingerprint and facial recognition authentication.

To configure Windows Hello method in Advanced Authentication, perform the following steps:

  1. Click Methods > Windows Hello.

  2. (Optional) Set Allow to specify Username (for AD Users only) to ON if you want the Active Directory users to specify their account name while enrolling. By default, the option is disabled.

    This is applicable for Active Directory users only. This option does not affect local and other repository users and they must specify their account name while enrolling.

  3. Click Save.