How corporations are enabling access to high-security apps
By Mark Diodati, research vice president, Gartner
The surge in the use of adaptive authentication has many ramifications for general authentication, but perhaps the most interesting is its impact on elevated authentication. This is where elevated will see its second act.
Adaptive authentication leverages behind-the-scenes techniques to raise the assurance level of primary authentication mechanisms without any user interaction, for example checking an IP address, the geo-location on a user’s phone, and so on. But what if the inevitable happens: adaptive authentication becomes so good that it announces itself as the primary authentication mechanism? That’s where elevated authentication enters its second act by enabling enterprises to put in place other authentication mechanisms for access to higher-security information and applications.
The first act
When it comes to authentication, enterprises have always lived on the painful edge of the “security vs. usability” debate. Authentication methods must deliver enough identity assurance to match the application’s requirements. But when enterprises make draconian authentication choices, users will revolt or find a way to bypass the authentication system.
Elevated authentication was born from the security vs. usability debate. Rather than treat every application as the same, elevated authentication introduced tougher methods only when they’re needed – when applications with higher assurance levels are accessed.
Before it could see broad deployment, elevated authentication required the arrival of Web Access Management systems – think Netegrity Siteminder, now owned by CA Technologies. A Web Access Management policy engine supports multiple authentication methods, and can rank them in order of assurance. The administrator also assigns assurance levels to applications, which enables a scaled approach for authentication in general, particularly elevated authentication. If a user attempts to access a higher-assurance application without the right method, the Web Access Management system prompts for re-authentication.
Traditional elevated authentication example
There are many examples of elevated authentication and it remains a part of the enterprise authentication strategy. Suppose you have an environment where users authenticate with a password to Active Directory at their domain-joined workstation. Active Directory returns Kerberos credentials, which will be used for access to applications.
When the user attempts to access a Web Access Management-protected application, the Kerberos credential is presented as proof of authentication. The system issues an HTTP cookie that will provide access to other protected applications. The user can access subsequent lower-assurance applications without re-authentication. But when the user attempts access to a Web Access Management-protected application that requires higher-assurance authentication – such as human resources or financial applications – the user is prompted to authenticate with a higher-assurance authentication method, for example a one-time password from a mobile device.
After the first elevated authentication, the user can access other higher-assurance applications without re-authentication. If the user’s first authentication to the Web Access Management system is via OTP, then the user may access both high and low assurance applications without re-authentication.
In the pursuit of minimizing usability concerns, the elevated authentication method is used only when required. If users access only lower-assurance applications, there is no need to use the elevated – and less usable – authentication method.
Elevated authentication can also be tied to specific situations or users. For example, many organizations will force an elevated authentication based upon network awareness, such as if the user is remote. Similarly, elevated authentication may hinge around user privilege, with highly-privileged users forced to elevate.