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.
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:
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:
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.
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 184.108.40.206, 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
Configure Username/Password mechanism.
This article will use the internal LDAP server in ISVA Appliances without SSL encryption.
LDAP Bind DN
<root LDAP bind dn>
LDAP Bind password
<root LDAP password>
<LDAP service address>
389 or 636
SSL Trust Store
<set if using SSL>
Use Federated Directories Configuration
User Search Filter
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.
- Configure an InfoMap mechanism to use the uploaded rule.
- On later versions of the appliance you may also have to update the policy kickoff method advanced configuration parameter
Deploy pending changes (required for next step).
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.
- 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.
- 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.
- 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
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.