It is with regret that I inform you of the sad passing of the password. There have long been rumours of passwords death, and thanks to IBM Security Cloud Identity (CI), they were right! If you want to know how to make login experiences simpler, faster and stronger, then read on.
The suite of authentication factors offered by CI has received a significant boost with the addition of support for FIDO2 and WebAuthn standards. FIDO2 can be used for second factor authentication (2FA), or primary first factor. FIDO2 consumption is also available for pure API consumers via CI’s extensive web API’s.
This blog is for security architects, solution designers and deployers, and anyone interested to learn about the FIDO2 and passwordless features of CI. The focus of this blog and the remainder is the use of FIDO within CI where your CI tenant is the relying party.
The following use cases are available to regular CI end users:
- Registration of FIDO2 authenticators using CI’s user self-care Profile and Settings.
- Respond to a 2FA challenge using a registered FIDO2 authenticator.
- Passwordless login to CI consoles using a registered FIDO2 authenticator.
For CI tenant administrators, the following configuration functions are available from the CI administration console:
- Configure a FIDO2 Relying Party. Relying Parties are the primary configuration artefact within CI.
- Upload FIDO2 authenticator vendor metadata files. This is optional but might be needed if there is a requirement to restrict registrations or enforce authenticators based on specific vendor or technical specifications.
- Enable FIDO based passwordless login to CI consoles.
Background
WebAuthn was designated an official W3C standard in March 2019. WebAuthn is a Javascript API available in browsers. It allows relying party web sites to register cryptographically based credentials for their users, and to subsequently use those registered credentials for strong user authentication. Registered credentials and cryptographic operations are performed by a separate authenticator, typically hardware based, which the user owns or otherwise possesses. WebAuthn allows browser based Javascript to interact with an authenticator.
WebAuth is supported in Windows 10, Android platforms, Google Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari (preview) web browsers. Registration and authentication using roaming or platform-based authenticators is possible. Roaming authenticators are those that are accessible from WebAuthn enabled browsers via a remote connection transport such as NFC, BLE or USB. Platform authenticators are those where the authenticator and cryptographic material are hosted on the same physical device as the WebAuthn enabled browser. Windows Hello and Google Chrome with Mac Touchbar are examples of platform authenticators.
Configuring your Cloud Identity Tenant
My colleague, Shane Weeden, has published a blog covering how to consume the FIDO2 features of CI via API. His blog covers some aspects of FIDO2 configuration for relying party implementations which are external to your CI tenant. The focus of this blog and the remainder is the use of FIDO within CI where your CI tenant is the relying party.
FIDO2 relying party and metadata configuration
For new and existing CI tenants, a default FIDO2 relying party configuration is created for each CI tenant. This means you won’t need to create the FIDO2 relying party configuration if you wish to enable FIDO2 features for your tenant. You can manage all relying parties from the CI administration UI. Access the FIDO2 configuration panel from the Security hamburger menu:
In my case, the CI tenant relying party is indicated by the row with the Identifier myidp.ice.ibmcloud.com.
By default, there are no FIDO metadata files installed for your tenant. If you wish to enforce a restricted set of allowed FIDO authenticators, or offer an enhanced end-user experience with vendor-provided icons and descriptions in user self-care, then you will need to obtain the metadata files from your FIDO vendor and upload these to your CI tenant using the Device Metadata feature shown on the screen above. Additionally, you should add a reference to the uploaded metadata from the Devices filter within the relying party configuration. To enforce that only metadata-linked authenticators may be registered, enable the Check device authenticity option.
Some noteworthy aspects of the relying party configuration include:
- Relying party identifier – For now this should match the fully qualified domain name of the CI tenant*. In accordance with the WebAuthn standard, this identifies your CI tenant as the relying party that will perform the registration and authentication ceremonies. Your users will not be able to use the same registration at other web sites. They will, however, be able to register their FIDO authenticator at multiple other relying party web sites.
- Allowed origins – This specifies the allowed web addresses that can represent the relying party. The full CI tenant https URL is set as an allowed origin. Origins are enforced by the browser.
* Note the matching rules for origin and RPID are a little more elaborate than just the fully qualified hostname. The details for those interested can be found in the WebAuthn standard: https://www.w3.org/TR/webauthn.
Enabling CI console login using FIDO2
CI enables users to authenticate to its administration and end user consoles without a password. One of the passwordless methods available is with a registered FIDO2 authenticator. Passwordless login to CI consoles is not enabled by default and must first be enabled if you want to offer it to your CI console users.
Passwordless login is enabled on per console, per Identity Source basis. Passwordless login using FIDO will be shown on the main CI console login screen if there is at least one Identity Source enabled with the associated FIDO option enabled. See below.
You can manage passwordless login options from the CI administration UI. Access the Sign-in options configuration panel from the Security hamburger menu:
Click the Edit sign in option menu option as shown in the diagram above to enable passwordless login to CI:
The configuration options shown in the diagram above will enable FIDO2 passwordless login for both the CI administration and end user consoles. It should be noted however, the enablement has been applied to the Cloud Directory Identity Source only. This means successful runtime authentication will be restricted to those users who have previously registered a FIDO2 authenticator while authenticated via the Cloud Directory realm Identity Source.
I'll cover the QR code options in another blog.
Registering your FIDO authenticator using CI User Self Care
Users can register* their FIDO authenticators using CI’s user self-care. Once registered, the authenticator will be available as a selectable factor during a 2FA policy flow. A 2FA policy might be triggered during a single sign-in application launch from CI. A registered FIDO2 authenticator, as opposed to a FIDO U2F authenticator, is a pre-requisite for FIDO2 based passwordless login to CI consoles.
* Technically, registration is where a FIDO authenticator generates a new cryptographic credential, scoped to the relying party, and shares the credentials public attributes with that relying party. It is possible to register multiple credentials from a single authenticator with a given relying party.
The default or preferred registration flow offered by CI user self-care executes with a set of options that are compatible with FIDO2 authenticators only. This is because the registrations options used leverage the resident key credential and user verification features of FIDO2 authenticators. However, the CI user self-care flow does offer an alternative for FIDO U2F authenticators. This distinction is important, because the CI passwordless login capability via FIDO2 requires authenticators that have at least one registered credential that was created using options supporting resident key credential and authenticator enforcement of user verification.
CI end users should login to CI and then navigate to Security tab of their Profile and Settings (it may be necessary to complete a 2FA challenge as part of this). An example registration flow sequence is shown below.
Click Add new method to begin the registration of a new authentication factor.
The following screen sequence is the result of clicking Add device associated with the FIDO2 Device option above. In this sequence, I will register my Macbook Touchbar which is supported as a platform authenticator with the latest Chrome browser.
Click next and select the Built-in sensor option as shown below.
Note, if you have a FIDO U2F authenticator you should click the Having trouble adding your device? option. This will register your authenticator using options that are supported by FIDO U2F. However, the resulting registration will not be valid or result in successful authentication if used during the CI passwordless login.
At this point your Mac Touchbar will light up. You should touch the Touchbar with your enrolled fingerprint. The screen prompt is shown below.
Allow access if prompted by your browser. Enter a Friendly name to complete the registration.
After completing an initial first time validation flow, your FIDO registration will be complete as shown below. Included in the screen shot below are the additional lifecycle management menu options which are available for a registered FIDO authenticator.
FIDO 2FA Challenge
Now that your end users have registered their FIDO authenticators, those registrations can be offered as a selectable 2FA challenge option when a 2FA policy is triggered. An example of the runtime selection screen is shown below.
Selecting Verify from the FIDO2 authenticator option results in your FIDO authenticator prompting for user interaction. In the case of a Mac Touchbar authenticator, the Touchbar lights up and the user can complete the 2FA verification with their enrolled fingerprint.
Passwordless authentication using FIDO2
If your tenant administrator has enabled FIDO2 based passwordless login, then you will be presented with a CI login screen that looks something like the one shown below:
If you have previously registered your FIDO2 authenticator, then you’re able to attempt to use it as way to login to CI. Click the FIDO icon image to begin the login flow.
At this point, the browser will prompt you to connect your authenticator and complete its user verification. In my case, I simply verify my authentication by touching my Macbook Touchbar which I registered previously.
The browser then prompts me to select which set of registered FIDO2 credentials I wish to use. In my case there is only one set of credentials. This selection will be used by CI to determine which FIDO registration was used and then further determine with which CI account you’re wishing to authenticate.
Congratulations! You’ve just authenticated to CI simply by interacting with your FIDO2 authenticator and all without the need to remember or type a password!
Summary
IBM Security Cloud Identity now has support for FIDO2. This is the state of the art in security authentication for your external and internal applications. FIDO2 provides a compelling balance between end user convenience, privacy and strong security. After reading this, I hope you’ll agree that CI has enabled FIDO2 authenticator registration, authentication and relying party configuration in a highly consumable offering. Using CI, you have the power to make end user login experiences as simple as the touch of a button!