Strong authentication deployments are increasing as enterprises struggle with the dynamics of their business, including the migration of applications to the cloud and greater user demand for device-independent access to corporate resources. This trend will continue into the future, though customers may select hosted solutions in lieu of the traditional on-premise solution.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Enterprises have two choices when it comes to hardware-based strong authenticators: one-time password tokens and smart cards. Both authenticators have benefits and challenges. Smart cards are the only native strong authenticator supported for Windows workstation authentication. OTP tokens are portable and clientless; they require no workstation software.
Application interoperability is the first barrier to a successful OTP deployment. Interoperability runs the gamut, from non-existent to easily-integrated. For example, OTPs are not compatible with Microsoft Active Directory; native Windows workstation authentication is not possible, and OTP authentication for AD-aware Web applications is difficult at best.
Still, OTP interoperability with applications is very good. RADIUS-based applications work very well with OTPs. Generally, OTP authentication to Web applications is "a mixed bag" and is application-specific.
Two technologies can greatly extend the interoperability of OTPs: federated identity management and Web access management. Both technologies can transition OTP authentication to the unmodified application, including bridging the gap with Web applications which require Active Directory authentication. For example, the federation product can authenticate the user via OTP, then issue the user a Security Assertion Markup Language (SAML) credential. SAML credentials are accepted by many applications.
The lack of good enterprise identity proofing processes is the best way to ensure the failure of an OTP deployment. Vetting processes are necessary when the user's OTP has not been distributed or is temporarily misplaced. Without it, the enterprise has no confidence that the user in possession of the one-time password token is the authorized user (and not a disgruntled employee or external hacker). Enterprises frequently overlook these processes, and then spend upwards of ten times the original cost to fix their mistakes.
Like many applications, OTP token deployments are moving to the cloud. Drivers include cost reduction and usability. But the "strong authentication as a service" market and associated technologies are still maturing. In many cases, enterprises cannot implement a truly outsourced solution due to integration issues with applications and on-premise identity stores like LDAP directory servers or Microsoft Active Directory.
Many enterprises will opt to go with an on-premise solution because it enables greater control over the authentication lifecycle and may provide greater control over confidential employee information.
Below are some tips that will help your clients secure their ever-accelerating OTP deployments.
Inventory customer applications
With authentication deployments, the surest way to lose credibility with a client is to recommend a solution that does not work with the necessary applications. Inventory your client's current (and future) list of applications to determine the best OTP option. One example of an incompatible application is Active Directory authentication at the workstation. Read past the vendor's data sheet; one vendor's implementation may not meet your client's needs. For example, the application integration may not support resetting the user's PIN.
Implement identity proofing processes
It's simple: Your client's time and money will be wasted unless adequate identity proofing processes are implemented. These vetting processes apply to one-time password token distribution, emergency access and OTP replacement. Vetting processes can be "in-person" for high assurance environments or remotely via self-service portals. Avoid using static knowledge-based authentication (KBA) when vetting users remotely, as it will certainly degrade the quality of OTP authentication. Examples of static KBA questions include: mom's maiden name and town of birth.
Test, test, test
Before the OTP solution is chosen, it is your job to test it to make sure it provides adequate functionality. This testing extends beyond checking application compatibility; it also includes testing both administrative and user self-service and password functionality. You may find that some customization is required to integrate this functionality into the client's existing infrastructure. For example, you may need to integrate the OTP solution into the client's existing self-service portal.
Go with the right architecture
Should the client's OTP deployment exist on premise or be hosted in the cloud? While "authentication as a service" deployments will continue to increase, it's not a slam-dunk choice. The choice will be impacted by the client's applications, and the location of those applications (i.e., on-premise or hosted). Additionally, the client may have specific employee privacy goals which may indicate that an on-premise solution is best. If the client opts for a hosted solution, you should proactively set expectations that some components (for example, a RADIUS proxy server) of the OTP solution may need to remain on-premise.
OTP token deployments are a great opportunity to prove value and expertise to your clients. By keeping these recommendations in mind, you can save your clients money and time as well as accelerate the deployment.
Mark Diodati is a senior analyst for Burton Group Identity and Privacy Strategies. He covers identity management, authentication, provisioning, cryptography, directories, Web access management and operating system security.
Send your feedback to Editor@searchsecuritychannel.com.
Join us on LinkedIn.