FIDO2

FIDO2 in less than 15 minutes with ISAM 9.0.7

Share this post:

In this article I’m going to show you how to configure FIDO2 on ISAM and get simple WebAuthn registration and authentication flows working. The pre-requisite is that you have an ISAM 9.0.7 system with a web reverse proxy and advanced access control configured and working. From there our 15 minute goal to getting FIDO2/WebAuthn running is more than achievable.

If you don’t have an ISAM configured with a web reverse proxy and advanced access control, then here’s a very good starting point for an article (including a link to a lab guide) that can get you to that point using containerized ISAM on Docker:

Of course make sure you build with ISAM 9.0.7 when doing this otherwise FIDO2 capabilities will not be available. I went through the lab guide linked in the above article myself (using Docker running on my Mac rather than a separate CentOS image), and will use that as the starting point for the FIDO2 exercises in this blog post. You should check if the following files contain reference to the 9.0.7.0 ISAM_VERSION:

  • studentfiles/container-install/compose/iamlab/.env
  • studentfiles/container-install/common/env-config.sh

If not, chances are you have the wrong release from the github repo, so have a look for a v9.0.7.0 release.

Following the established conventions from the cookbook above, the following URL’s will be used for the remainder of these instructions, and it will be assumed you have them in a local hosts file that your browser will use:

  • ISAM LMI: https://isam.iamlab.ibm.com
  • Web Reverse Proxy: https://www.iamlab.ibm.com

 

Configuring FIDO2

To config FIDO2, follow these instructions. The diagram that follows should help.

  • In the LMI, navigate to Secure Access Control -> FIDO2 Configuration, then Add New Relying Party.
  • Enter www.iamlab.ibm.com for both the Display Name and Relying Party ID and press Next.
  • On the Summary page, press Save.
  • Deploy the Pending Changes, then also Publish the container configuration (Container Management -> Publish Configuration -> Submit).

Allow the runtime a few seconds to restart after obtaining the latest configuration snapshot. You can monitor this with (assuming the docker-compose setup from the lab):

$docker logs -f iamlab_isamruntime_1

Wait till you see:

CWWKF0011I: The server runtime is ready to run a smarter planet.

That’s it for a start. Pretty simply huh? Let’s try it out.

Using FIDO2 to register and test authenticator

ISAM comes with a built-in self-care management page (you can customize this or write your own) that you can use for FIDO2 registration management. Using a FIDO2-compatible browser such as Chrome, Edge or Firefox, visit it with:

  • https://www.iamlab.ibm.com/mga/sps/mga/user/mgmt/html/device/device_selection.html

Login as emily / Passw0rd (this is a username/password from the lab guide).

Hopefully you have a compatible FIDO2 authenticator – I’m going to show you the experience with Chrome on my Mac using the touchbar, but you can try any FIDO2 authenticator you might have.

  • Under the section titled “FIDO2/WebAuthn Registrations”, click on Register new authenticator.
  • On the registration pop-up, just press Next.
  • Chrome shows me a dialog asking what type of authenticator I’d like to register. As I’m going to use the Touchbar, I pick “Built-in sensor”.
  • At this point the prompt next to my touchbar changes to indicate that I should press it to register at the www.iamlab.ibm.com website. I do this and see the a Chrome dialog, on which I press Allow. This permits attestation information about the type of authenticator that I’m using to be sent to ISAM. I suggest you press Allow so that you can see what adding Metadata permits us to show in an upcoming blog post.
  • Finally, I give the registration a friendly name, and press Next. My authenticator is now registered!

 

The administrator can also see registrations via the management console:

Try the Test button – you should be prompted to use your authenticator, and see a success message:

 

Note that this test operation, whilst exercising all the FIDO2 authenticator flows, is not actually a login (or step-up login) to ISAM. To do that we need to utilize an AAC authentication policy.

 

Configuring a FIDO2 WebAuthn authentication policy

Follow these instructions to configure a FIDO2 authentication policy:

  • In the LMI, navigate to Secure Access Control -> Authentication
  • Create a new authentication policy, adding first the Username Password mechanism, then the FIDO2 WebAuthn Authenticator mechanism
  • Configure the properties for the Username Password mechanism, setting reauthenticate to false
  • Configure the properties for the FIDO2 WebAuthn Authenticator mechanism, setting relyingPartyConfigId to www.iamlab.ibm.com
  • Save the mechanism properties, then save the policy.

Don’t forget to Deploy pending changes, and publish the configuration.

 

Try out the authentication mechanism by visiting the kickoff URL:

https://www.iamlab.ibm.com/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:fido2

You should be prompted for Username Password authentication (if not already done this session), followed by FIDO2 authentication.

 

You have now successfully configured a FIDO2 / WebAuthn relying party, and exercised the basic Registration and Authentication capabilities. The authentication capability shown here was for step-up login only. There is LOTS more to explore though such as Metadata, Mediators, and Username-less login with Resident Keys. That’ll be the topic of my next article!

More FIDO2 stories

Protecting entire ISAM WebSEAL site with multi-factor authentication using stepup login

Today I’m going a bit old-school with information on a basic ISAM scenario that has been available for years. This has come up in field questions several times recently, I think mostly with people who are relatively new to ISAM but understand the need for multi-factor security as a standard part of the authentication workflow. […]

Continue reading

Cross-origin session detection

Consider a federated single sign-on environment where an Identity Provider (IDP) for applications may in turn be acting as a gateway – and be configured as a Service Provider (SP) to many different other IDPs. The role of this IDP is to provide a common federated SSO service to applications. It may also need to […]

Continue reading

Account Recovery is just another Authentication Method

This article is an opinion piece geared toward (re)evaluating your thinking about end-user workflows for account recovery in traditional web authentication systems. Leaving aside superior PKI-based authentication schemes such as FIDO for a moment, let’s take a look at how account recovery scenarios on a traditional website might be made less attractive to attackers attempting […]

Continue reading