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).
A high level overview of the steps involved is presented here:
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.
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.