Search form

Search this site

You are here: Home › News › Marrying strong authentication with user convenience

Marrying strong authentication with user convenience

October 7, 2014

The State of California government recognized the need for stronger user authentication, knowing that authentication strength requirements may change over time, and that user convenience and cost of ownership were very important from day one.

Employees, partners, and agents have unique IDs and strong authentication method to login to their government applications. TrustBuilder is used to link the authentication mechanisms to appropriate enterprise users, and deliver device fingerprinting to improve convenience and lower costs while maintaining security.

While the password is a common target and potentially a weak link in the authentication chain, companies are reluctant to choose “the next” authentication solution as they do not want user resistance or security failures. The effort of integrating a new solution can also be burdensome and costly. A better practice is to build an architecture that isolates the authentication, federation, and identity mapping services from the applications such that business leaders have the freedom to pick and choose appropriate mechanisms going forward, and the applications do not need to be touched. Instead, policy can be set to allow your security component to exploit the technology desired. The TrustBuilder solution is an open platform with reusable adapters that makes it easy to integrate one or more strong authentication or identity mapping methods.

While authentication is an important function of an application, it is often a side issue from the real business logic which needs to be performed. The less time a developer needs to spend on authentication issues, the more time they can spend on satisfying business needs. Identity mapping, prompting the user, delivering information to a user’s cell phone, etc. are also important steps, and must be done right to ensure security. Building these from scratch increases the chance of injecting a bug. A best practice is to reuse logic that has already been written and tested. Once an application is integrated with TrustBuilder, a whole menu of offerings is available to be exploited. For example, if you wish to require a one-time-passcode (OTP), in addition to an ID and password, you can configure TrustBuilder to prompt the user (rather than doing it from the application). Screens such as the following can be tailored and branded as desired:

TrustBuilder also provides an easy self-registration process so a user can link their device, (cell phone number this case), with their enterprise identity. Within seconds, a user can attempt to access a protected application and be prompted for additional security verification in the form of an OTP. The OTP can be sent over SMS, email, generated on the phone, etc. Again the choice is yours, TrustBuilder offers these capabilities, and you select them from the menu. Below is an example of an OTP being sent to a user’s phone over SMS.

Again, the content can be tailored however you like, but the point is that you did not have to investigate and integrate SMS services and OTP validation, these are provided as reusable components.

While almost anything is possible, often it is easier to read about a specific use case. A large US state government recently was grappling with this issue to integrate strong authentication with user convenience. They wanted to improve security, yet required an easy to use system, and needed compatibility with ANY cell phone, not just smartphones. To learn more about their requirements and how they choose to implement the solution, have a look at this reference story.