Authentication types

Warning

Mideye Server 4 is no longer updated, and new installations are not supported. Only existing Mideye Server 4 installations and upgrades to latest release are supported. Please use Mideye Server 6 for new installations and continued support.

The Mideye server is a general-purpose RADIUS server with eight different supported authentication types:

1. Password: The user is authenticated with a static password.
2. Mobile: The user is authenticated with a static password, in combination with a one-time password that is sent to the user’s mobile phone in real-time via the mobile network. This authentication type relies on a two-step challenge-response dialogue. Users that have activated Mideye+ get OTPs primarily via data push (mobile data or wifi), with Plus (auth type 5) as a fallback in case the phone is not reachable. Users without Mideye+ log in with SMS-OTP.
3. Token: The user is authenticated with a static password, in combination with a one-time password that is obtained from the user’s token card (YubiKey or HID Mini Token). The static password and the one-time password are provided in two separate steps. This authentication type relies on a two-step challenge-response dialogue.
4. Concatenated: Only supported with HID Mini Token. The user is authenticated with a static password, in combination with a one-time password that is obtained from the user’s token card. The one-time password is concatenated with the static password in one single step, which means that this authentication type does not require support for a two-step challenge-response dialogue. Example: If the static password is Sd43Erg7 and the one-time password is 28592434, this is entered as Sd43Erg728592434.
5. Plus: The user is authenticated with a static password in combination with a one-time password which is obtained by manually signing an access challenge in the Mideye+ app. This authentication type is mainly intended as a fallback from other authentication types in case the phone is not reachable. It relies on a two-step challenge-response dialogue.
6. Touch: The user is authenticated with a static password, followed by an ‘Accept’ option presented directly in the Mideye+ app. This authentication type requires that the Mideye+ app is reachable via data push (mobile data or wifi). It does not require support for a two-step challenge-response dialogue.
7. Touch-Plus: The user is authenticated primarily using Touch (auth type 6), but with a fallback to Plus (auth type 5) in case the phone is not reachable via data push.
8. Touch-Mobile: The user is authenticated primarily using Touch (auth type 6), but if the phone is not reachable via data push, the system reverts to Mobile (auth type 2) by sending an encrypted SMS to the Mideye+ app. If the phone is not reachable at all via the network, the server reverts to Plus (auth type 5).

Auth Type Requirements

• Authentication types 2,5,6,7,8 require that a valid mobile phone number is registered in the user repository.

• Authentication type 3 (Token) requires that the user has a token card (YubiKey or HID Mini Token) and that the corresponding serial number is registered in the user repository.

• Authentication type 4 (Concatenated) only works with HID Mini Tokens.

• Authentication type 5 (Plus) only works if the user has activated Mideye+.

• Authentication types 6, 7 and 8 require Mideye+ for the Touch functionality. Users that haven't activated Mideye+ are automatically assigned authentication type 2 (SMS-OTP).

Authentication

Default authentication type: Mideye Server comes predefined with authentication type 2 (Mobile). This can be customised to any of the authentication types 1-8.

Default OTP Presentation: Default value is Popup, but can be changed to Inbox SMS. Default Network: This field should never be changed from the value “Default”

Read optional attribute: If a group of users should have a different authentication type than the one specified as default, read optional attribute can be used. When this option is enabled an LDAP-attribute can be configured in the field “Authentication type attribute” Once enabled, that field in LDAP will control what authentication should be in use. For example, if attribute “pager” is set in the “Authentication type attribute” and the number 3 is set for the user, authentication type “Token” will be used based on the list above. See example below:

Configuration of authentication types

Example of read optional attribute.

OTP Presentation Attribute: OTP presentation can be customised using an LDAP-attribute.The number in that attribute will decide with OTP that should be used.

0 (Zero): Popup SMS 1: Inbox SMS

Department attribute: If the department of the user should be visible in accounting, the default value should be attribute “Department”

Password override: See document “Password Comparison” for detailed information and configuration example.

Activate LDAP user blocking: If enabled, the user will be temporarily locked out after defined failed attempts for x number of minutes. 0 is equal to permanently blocked. Users can be unblocked from Mideye Web Admin.

Active Directory

The following options will only function for LDAP users and will not work with database users.

Check remote flag: If checked, access is only granted if the “Dial in” properties is set to “Allow remote access”. Allow password reset (PAP): If checked, access is granted if the password is correct but needs to be reset. This option is only used for PAP authentication when allowing a secondary authentication using LDAP. Allow password expired (PAP): If checked, access is granted if the password is correct, but has expired. This option is only used for PAP authentication when allowing a secondary authentication using LDAP. Search nested groups: If checked, Mideye Server will search for users in groups that are nested in the group specified. Use Framed IP Addresses: If checked, Mideye Server will read the “Assign static IP Addresses” from LDAP and pass the IP address along as attribute 8 with a successful login.

Active Directory settings