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.
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.
Requires Membership to View
To gain access to this and all member only content, please provide the following information:
By submitting your registration information to SearchSecurityChannel.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here
- Your use of SearchSecurityChannel.com is governed by our Terms of Use
- We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
- If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.
 |
||||
|
|
|||
|
||||
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.
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.
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.
This was first published in April 2010