Recommended login sequence
Hitachi ID Identity and Access Management Suite supports multi-factor authentication for all users. This includes both an open integration framework with support for all major MFA technologies on the market and an out-of-the-box mobile app that provides a second factor for users who have not yet been provisioned one.
The recommended sequence for authenticating users into the Hitachi ID Suite web portal (and where it acts as a federated IdP, through into integrated SP applications) is as follows:
- If the user connects from outside the private/secure corporate network, start with a CAPTCHA.
- Next, prompt for the user's login ID.
- Fingerprint the user's browser -- if the indicated user has signed on successfully from the same browser before, this fact can act as an unobtrusive authentication factor.
- If the user connects from a browser or location not seen before,
prompt for another factor, which may be any of the following:
- If the user has been activated to use a third party MFA technology, such as a one time password token (e.g., RSA SecurID or YubiKey) or a third party app (e.g., Duo Security, Google Authenticator, Okta Verify, etc.), use that.
- If the user had previously installed Hitachi ID Mobile Access on their phone, either use push notification to display a PIN on their phone or display a cryptographic challenge in the login screen as a QR code, which the user scans with the app.
- If the user had previously enrolled their mobile phone number,
send a PIN to the user's phone, via SMS and prompt the user to
Note: an SMS broker is required to do this, which may cost as much as a few cents per message.
- If the user had previously enrolled their personal e-mail address, send a PIN to that address, on the assumption that the user has e-mail access on their phone.
- Users may be prompted to select one of several MFA options or one of several alternatives for the same option (e.g., send a PIN via SMS to one of multiple mobile numbers or e-mail addresses).
- Finally, depending on whether the user remembers his password, prompt the user to enter it or answer a series of security questions. Using a second, "knowledge" factor reduces the risk of compromised authentication due to lost or stolen phones or hardware tokens.
Mobile Access is included and provides a second factor
Hitachi ID Systems ships mobile apps for Android and iOS, where the communication path between an on-premises (non-Internet-reachable) Identity and access management (IAM) system and a smart phone attached to the public Internet is brokered by a cloud-hosted proxy. The main purpose of these mobile apps is to address the connectivity problem, where the phone is outside the "corporate" network but the IAM system is inside and no connection originating at the phone can terminate at the IAM system, because of NAT, firewalls, absence of a VPN and absence of a reverse web proxy.
The Mobile Access mobile app also supports a MFA feature, which works as follows:
- The user's phone has a locally installed, unique-to-that-device encryption key, deployed at phone/app activation time.
- The user attempts to sign into the IAM system from his PC (VPN, on-premises).
- The login screen renders a cryptographic challenge, displayed as a QR code.
- The user activates the app, which uses the phone's camera to scan the QR code and compute a response.
- The response code is sent via a cloud-hosted proxy to the IAM system, to complete the login step.
- If the user has no data connection on his phone, he is able to read the response code from the screen of his phone and type it into a text entry box in the IAM system's HTML login page.
This is intended as a zero-added-cost feature for all users at all Hitachi ID customers, so that all users gain the benefit of a second authentication factor (something they have - their phone).
Hitachi ID recommends combining this with either a password or security questions, rather than using this as the sole authentication factor.
Supported credentials more generally
- On the web portal:
- By typing their current password to a trusted system (e.g., Windows/AD, LDAP, RAC/F, etc).
- By answering security questions.
- By offering up a biometric sample, which is validated by a trusted service or API.
- Using the Mobile Access smart phone app to scan a cryptographic challenge displayed on the user's PC screen as a QR code.
- Using third party smart phone apps, such as Duo Security or Google Authenticator.
- Using a hardware or software security token (e.g., RSA SecurID).
- Using a smart card with a PKI certificate.
- Using Windows-integrated authentication.
- Using a Security Assertions Markup Language (SAML) or OAuth assertion issued by another server.
- By typing a PIN that was sent to their mobile phone via SMS.
- Using a device/browser fingerprint and/or cookie, for example to compare current login to previous events.
- Using a telephone, calling an automated IVR system:
- By keying in numeric answers to a series of security questions (e.g., employee number, date of hire, driver's license number).
- By speaking one or more phrases, where the Hitachi ID Suite server compares the new speech sample to one on record (biometric voice print verification)
- Using a telephone, calling an IT support technician:
- By answering a series of security questions, where the technician must type the answers into a web portal to authenticate the caller.