I’ve been coming to the RSA conference on and off (mostly on) for more than 15 years, and each year there seems to be more strong authentication vendors demonstrating new and interesting approaches to authenticating end users.
At RSA, we track and test these different approaches to find the best ones for integration into our RSA Via Access offering so that we can roll them out to our customers when they become ‘ready for primetime’. A great example of this is support for Eyeprint ID™, a biometric offering now offered in our latest release.
We don’t add authentication methods to our platform simply for the sake of adding another method. Rather, we focus on offering the appropriate set of authentication options for a given request that both (1) satisfy the assurance requirements for the request, and (2) are available to the end user. Let’s look at each of these options more closely.
Satisfying the security requirements of a given request
Traditional access management systems make decisions about whether to allow a user to access a resource based on who the requester is and what they requested. These controls made sense in the days of client-server computing when people were using company-issued devices to access applications from company controlled networks. In today’s computing paradigm where people are using web and mobile applications to access enterprise resources, we need to include many additional factors into our access decisions – simply because we have less control over the client device (often it belongs to the user) and the network (we want people to be able to access resources over the internet).
If a user is using their corporate issued laptop to access a SaaS application from within their corporate network, then a Windows password-based authentication may provide the level of assurance that is required for that application. But if the same user is accessing the same resource from a device they’ve never used to access enterprise resources, and they are in a country they have never accessed resources from before, a stronger form of authentication is likely required to establish the level of assurance that good security practice requires. Here, the context of the request becomes important in determining the appropriate way for the user to authenticate. One size does not fit all.
What authentication options are available to the end user?
Not all users have the same devices—which means all users won’t be capable of using the same methods of authentication. A significant number of people do not use smart phones, rendering them unable to authenticate using most of the biometric approaches increasingly available in mobile devices. In other cases, their smart phone’s capabilities may not be advanced enough to perform the authentication—perhaps the camera isn’t advanced enough. On the other hand, some users may have devices that are capable of performing very accurate authentication that the enterprise could leverage. The emergence of the FIDO standard has led to a nascent market for such devices. Again, one size does not fit all.
Enterprises need a flexible Identity solution that is capable of assessing the security posture of the request, and then providing the user with an appropriate choice of authentication options, so they can use the method that is most convenient to them—while achieving the greatest degree of required security.
Further, organizations have been working diligently at removing ‘friction’ from the interactions they have with their employees, customers, and partners. They want to make it as convenient as possible for users to access their applications, while maintaining the appropriate level of assurance that users are who they claim to be. The proliferation of authentication methods has made it difficult for any one enterprise to integrate all of these authentication types on their own, because the list of methods is always growing and the amount we can trust any given method changes over time.
Organizations should look to their Identity vendors to support a variety of different authentication methods and provide a flexible way of defining the policies that dictate the authentication methods that are acceptable for a given interaction. They should also demand that these vendors present these authentication options to the end user in a way that is intuitive and convenient.
If an organization’s primary concern was the risk that an end user isn’t who they claim to be, theoretically that organization would authenticate users all of the time during a given session. If we were to use the most common approaches to authentication to achieve this, the user would have a horrible experience, constantly needing to input their login credentials. The goal needs to be achieving the appropriate balance between security and convenience for a given interaction. That’s why it’s important to take a lot of factors into account when you decide the authentication options to present for a given request – including device, location, and previous behavior.
It is only through this type of context-aware authentication that we can provide to the end user the best possible combination of security and convenience.