Customizing FIDO2 as an accessible Multi-Factor Authentication solution in IBM Security Verify Access.

Politely encouraging (forcing) users to enroll in multi-factor authentication is always challenging. However with the increasing prevalence of “smart” personal devices this is largely due to entrenched user behavior, rather than lack of capability. Authenticator applications on smart devices which implement OTP algorithms are increasingly accessible, but are only suitable for second factor authentication. This article will look at an emerging Public Key Infrastructure (PKI) technology called Fast identity Online (FIDO2) which can be implemented on the same smart devices, but used as a first factor of authentication (replaces username/password). Due to a patchwork of support across browser vendors I would only recommended it as second factor at this time; however it does represent a promising pathway to a simple and accessible protocol for strong authentication.

Assumed knowledge:

• Able to create AAC policies/mechanisms/author InfoMap rules

• Able to create AAC Access Control policies

• Configure a WebSEAL reverse proxy

• Configure FIDO2 (see FIDO in 15mins)

Before you start:

• Set up a User Registry

• Configure a WebSEAL Reverse Proxy

• Create a junctioned resource which will we are going to protect with MFA

Estimated time: 15-20 mins

This article focuses on the next iteration of the U2F open standard called FIDO2. This standard is a protocol for sharing and validating PKI. One of the primary objectives of the standard is to reduce the cost of creating and managing unique and complex passwords for all accounts. By encouraging users to use a FIDO device as either a primary or secondary authentication factor; their account is significantly less likely to be phished and compromise multiple identities from a data breach.

Personally, the most exciting aspect of FIDO is offering consumers an alternative to passwords using devices which they already own and often never without. Whilst at the time of writing this article this scenario is still being developed, there are demo applications which have demonstrated an authentication request which begins over https but is completed using Bluetooth. This ensures that the device which is authenticating the request is within a Bluetooth signal distance from the device requesting the authentication. This type of credential is being called a Passkey, which is a FIDO2 registration which can be used on multiple devices without the need to enroll each individual device.

Local FIDO Client:

One of the new features added in ISVA 10.0.0.0 is the Local FIDO Client. This capability allows administrators to enroll and authenticate user’s FIDO2 and U2F tokens from an InfoMap using customizable JavaScript based rules. This allows for easy integration with the most commonly used authentication mechanism’s in deployment. Detailed information about about the capabilities of the Local FIDO Client can be found at the IBM Knowledge Center.

The scenario this article will focus on is enrolling or validating a FIDO2 Passkey enrollment when a user attempts to access a protected resource. This scenario could be adapted to only enroll/validate the first time a user accesses the resource or extended to allow all second factor authentication mechanisms which have been configured.

Demo Scenario:

You have an existing user base: either LDAP/Active Directory based who primarily authenticate by username/password. You are trying to provide an easier and more secure way to login for these users. Ideally this would be achievable with devices that the user base already posses, and with UX that they are familiar with.

Whilst this scenario could be implemented using a number of different authentication factors, I am going to spruik the new AAC FIDO2 authentication capabilities, available in ISAM 9.0.7.0, and ISVA 10 onwards. If you are new to FIDO you should check out FIDO2 in 15 minutes for an excellent guide to get started.

Implementation using Advanced Access Control:

ISVA Advanced Access Control (AAC) gives us the tools to implement this solution. We are going to create a policy which first checks if the user is logged in, then checks if they have a (cross-platform)[LINK] FIDO2 authenticator enrolled. If either check returns false; the user is prompted to remedy the situation, ie. login and/or register a FIDO2 authenticator.

We will enforce this policy using the Access Control capabilities of AAC. This will allow us to “attach” the authentication policy previously described to the junction/resource we are going to enforce FIDO enrollment/authentication for.

This scenario will also make use of the new decision mechanism available to Authentication Policy authors. Decision rules are evaluated before one or more mechanisms, which together form a branch of a policy. Decision rules can be used to allow users to select from a number of mechanisms (or this can be done on behalf of a user). In this scenario we will use a decision rule after the user has logged in to determine if they already have a FIDO2 Registration or not. This way we do not require user input to determine the most appropriate path to authenticate the user.

Verify Access Configuration:

Demo login scenario: Force FIDO registration after login

1. Configure Username/Password mechanism.
   This article will use the internal LDAP server in ISVA Appliances without SSL encryption.
   
   

   Name	Value
   LDAP Bind DN	<root LDAP bind dn>
   LDAP Bind password	<root LDAP password>
   LDAP Hostname	<LDAP service address>
   LDAP Port	389 or 636
   SSL Enabled	False
   SSL Trust Store	<set if using SSL>
   Use Federated Directories Configuration	False
   User Search Filter	(|(objectclass=ePerson)(objectclass=Person))

    

   

2. Upload branching rule, fido client and fido helper  InfoMap JavaScript rules.
   The fido2_common.js helper rule will need to be updated with the Relying Party ID that you intend to use. This value will depend on the domain name of the WebSEAL Reverse Proxy that will be used. You cannot use an IPv4 address for this scenario. For this demonstration I am using the DNS name "www.myidp.ibm.com" as a hosts file entry on my personal computer.
   
   

   

   
   
   

3. Configure an InfoMap mechanism to use the uploaded rule.
   
   
   
   
   
   
4. On later versions of the appliance you may also have to update the policy kickoff method advanced configuration parameter
   
   
5. Configure the FIDO2 Relying Party. You will need to know the DNS you will be using for testing (you cannot use an IPv4 address). For this demo you can use the simplified configuration option. Feel free to take a look a the advanced configuration options to learn how you can customize FIDO2 authentication with Metadata or use a JavaScript Mediator to enforce additional Authentication requirements.
   
   
   

6. Deploy pending changes (required for next step).

7. Create Authentication policy. You will need to create a branching policy with a Username Password step followed by a decision with a single branch. Set the decision mapping rule as the branching rule uploaded in step 2; add a single step with the InfoMap mechanism created in step 3.
   
   

   

   
   
   

8. Modify the username/password policy to not enforce re-authentication. This means that if you are already logged in you won’t have to again.
   
   

   
   
   

9. Create a WebSEAL instance. This demo will create a new Reverse Proxy which listens on port 443 for HTTPS requests. We will also run the AAC configuration wizard so that WebSEAL can use identity information supplied by AAC. You will need to know the authentication information for the LDAP Security User (sec_master) as well as the AAC user (I use easuser, other users can be added to the AAC User Registry).
   
   When running the AAC Configuration wizard, if your version of ISVA contains tabs for FIDO2 PAIR scenario's, they can be ignored for this demo.
   
   
   
   
   
   
   
   
   
10. Update the WebSEAL configuration file to use the policy you just created as the default login page. When a user attempts to access a page from an unauthenticated state, they will be redirected to the AAC policy we just created. Because the WebSEAL configuration file is quite large, it is easier to use the "find" option to locate the required configuration entries.
    The path for the policy we just created is 

    /mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:fido_demo

    Once the WebSEAL configuration is set, deploy then changes and restart the instance, and you are ready to test it out!
    
    

Testing it out from the user’s perspective:

To test out the policy we can request the root junction of the reverse proxy; in this case that is just the domain https://www.myidp.ibm.com (remember the host file entry if you haven't already set it!).

If everything is configured correctly you should be prompted for a username and password. This article assumes that you have already created a user in your WebSEAL's user registry, so go ahead and login

Next you should be prompted for FIDO authentication. Since this is the first time you are using this policy, you should be prompted to register a FIDO2 authenticator. The exact steps to complete this registration will depend on both the browser you are using and the type of FIDO authenticator you are using. This demonstration shows the UX for registering a USB authenticator in a Firefox browser.

Once you have successfully enrolled your authenticator you will be redirected to the WebSEAL default junction page, congratulations!

Subsequent requests which trigger this policy will prompt the user to use their registered authenticator instead of enrolling a new authenticator