Implementing Knowledge Based Authentication in OpenAM

Introduction

Knowledge-based authentication, commonly referred to as KBA, is a method of authentication which seeks to prove the identity of someone accessing a service, such as a financial institution or website. As the name suggests, KBA requires the knowledge of private information of the individual to prove that the person providing the identity information is the owner of the identity. There are two types of KBA: “static KBA”, which is based on a pre-agreed set of “shared secrets”; and “dynamic KBA”, which is based on questions generated from a wider base of personal information. Source: Wikipedia.

In this demonstration of KBA to step-up authentication with OpenAM, we use a predefined question the response to which has already been collected from the user during registration. This response is stored either SHA1 hashed or in clear text on the user profile (by OpenIDM, for example).

Deployment

A high level overview of the steps involved is presented here:

Copy openam-auth-challengeresponse-module.jar to /webapps/openam/WEB-INF/lib
Copy crblocked.jsp and ChallengeResponseModule.xml in /webapps/openam/config/auth/default
Copy amAuthChallengeResponseModule.properties to /webapps/openam/WEB-INF/classes
Copy amAuthChallengeResponseModule.xml to /tmp
 ./ssoadm create-svc –adminid amadmin –password-file pwdfile –xmlfile /tmp/amAuthChallengeResponseModule.xml
 ./ssoadm register-auth-module –adminid amadmin –password-file pwdfile –authmodule org.forgerock.openam.authentication.modules.challengeresponse.ChallengeResponseModule

Configuration

The custom authentication module compares the stored response with the user input at the time of step-up prompt. The name of the attribute that OpenAM must read to determine the hashed or clear text response is configured using the Module Instances menu item under Realm->Authentication.

Register the module

Setup the Challenge Response Module

And then proceed to configure the attribute name and default question to be asked of the user:

You are also able to check or uncheck Hashed Response which would indicate whether the previously captured user response is stored using SHA1 or not.

Chain it to DataStore

Chain the module to the DataStore module to ensure that the user is prompted for their username and password prior to invoking the Challenge Response module.

Ensure the attribute being used to store the hashed or un-hashed response on the user profile is included in the list of Data Store LDAP user attributes:

Now we are ready to test.

Demo

User logs in to the realm under which the module chain described above is configured:

Immediately after password validation, the following screen is presented:

The user enters the response, which is then hashed if the Hash Enabled setting is left untouched, i.e., responses are stored hashed by default, and then compared to the attribute value stored on the user profile in OpenDJ. The user profile is retrieved by the AMIdentity API. If the response is incorrect, then the following error page is presented to the user:

Otherwise, if the correct response was entered, the user is taken to their profile page, or other target requested.

Code

Pick it up at GitHub

 

This article was first published in the OpenAM Wiki Confluence site: KBA in OpenAM