I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

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.

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.

Be aware that many stumbling blocks exist which can torpedo OTP deployments. We'll focus on how you can make clients successful with their one-time password implementations. Our discussion is specific to hardware OTPs, but many similarities exist with software OTP deployments.

Interoperability considerations

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.

Need-to-know mobile device authentication methods

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.

Identity proofing

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.

The cloud

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.

Recommendations

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.

Conclusion

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.

About the author: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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy