A group of us were talking about key takeaways for the 2013 Cloud Identity Summit last week in Napa. CIS 2012 focused on getting rid of passwords; but the conversation centered on infrastructure and identity standards such as OAuth, OpenID Connect, and SAML, which provide tool to authenticate users to cloud services. 2013 was still about minimizing usage of passwords, but focused on the client side where the “rubber meets the road” with mobile client apps.

Our discussion highlighted different opinions regarding the two principal models presented at the conference for solving single sign-on (SSO) issues for mobile devices. One model, the Authorization Agent (AZA) is an app that handles authentication and authorization services for other apps. KNOX is a Samsung-specific container that provides SSO to apps in the container. It’s heartening to hear developers stress that unless they get the end user experience right, the solution will not be adopted. No disagreement on that but buyers have other issues of equal importance, and I think we are going to see mobile clients embrace these approaches over the next couple years so it is worth discussing the issues in an open public forum. So I am throwing out the first pitch in this debate.

Statement

I believe the KNOX “walled garden” mobile app authentication model offers a serious challenge to Authorization Agents (AZA) – not because KNOX is technically superior but because it provides a marginally better user experience while offering IT better management, stronger security, and a familiar approach to mobile apps and data security. I expect enterprises to be much more comfortable with the KNOX approach given the way they prefer to to manage mobile devices.

I am not endorsing a product or a company here – just saying I believe the subtle difference in approach is very important to the buyers.

Problem

User authentication on mobile devices must address a variety of different goals: a good user experience, not passing user IDs and passwords around, single sign-on, support for flexible security tokens, Two-Factor Authentication (2FA) or equivalent, and data security controls – just to name a few. But the priority is to provide single sign-on for corporate applications on mobile devices. Unfortunately the security model in most mobile operating systems is primarily intended to protect apps for other apps, so SSO (which must manage authentication for multiple other apps) is a difficult problem. Today you need to supply credentials for every app you use, and some apps require re-authentication whenever you switch between apps. It gets even worse if you use lengthy passwords and a password manager – the process looks something like this: You start the app you need to run, bounce over to the password manager, log into the password manager, grab credentials, bounce back to the original application, and finally supply credentials (hopefully pasting them in so you don’t forget or make an invisible typo). At best case it’s a pain in the ass.

Contrasting Approaches

Two approaches were discussed during CIS 2013. I will simplify their descriptions, probably at the expense of precision, so please comment if you believe I mischaracterized either solution. First, let’s look at the AZA workflow for user authentication:

The AZA ‘agent’ based solution is essentially an app that acts as a gateway to all other (corporate) apps. It works a bit like a directory listing, available once the user authenticates to the AZA agent. The workflow is roughly:

a. The app validates the user name and password (1.).
b. The app presents a list of apps which have been integrated with it.
c. The user selects the desired app, which requests authentication tokens from an authorization server (2.).
d. The tokens enable the mobile application to communicate with the cloud service (Box, Evernote, Twitter, etc). If the service requires two-factor authentication the user may be provided with a browser-based token (3.) to supplement their username and password.
e. The user can now use the app (4.).

For this to work, each app needs to be modified slightly to cooperate with the AZA.

KNOX is also an agent but not a peer to other apps – instead it is a container that manages apps. The KNOX (master) app collects credentials similarly to AZA, and once the container app is opened it also displays all the apps KNOX knows about. The user-visible difference is that you cannot go directly to a corporate app without first validating access to the container. But the more important difference for data security is that the container provides additional protection to its apps and stored data. The container can verify stack integrity, where direct application logins do not. KNOX also requires apps be slightly modified to work within in the container, but it does not require a different authentication workflow.

User authentication for KNOX looks like this – but not on iOS:

Rationale

Both approaches improvement on standalone password managers, and each offers SSO, but AZA is slightly awkward because most users instinctively go directly to the desired app – not the AZA service. This is a minor annoyance from a usability standpoint but a major management issue – IT wants to control app usage and data. Users will forget and log directly into productivity apps rather than through the AZA if they can. To keep this from happening AZA providers need the app vendor to alter their apps to a) check for the presence of an AZA, b) force users through the AZA if present, and c) pass user credentials to the AZA.

The more important issue is data security and compliance as drivers for mobile technologies. The vast majority of enterprises use Virtual Desktop Infrastructure (VDI) to manage mobile data and security policy, and the KNOX model mirrors the VDI model. It’s a secure controlled container, rather than a loosely-coupled federation of apps linked to an authorization agent. A container provides a clear control model which security organizations are comfortable with today. A loose confederation of applications cannot guarantee data security or policy enforcement the way containers can.

One final point on buying centers: buyers do not look for the ‘best’ technology – they want the product that most closely addresses their particular problems. They tend to perceive a problem in a specific way, which drives their preference for how to solve it. For mobile user authentication, buyers also need to ensure that security and compliance policies are enforced. Without that a better user experience, or provisioning apps on the mobile endpoint, is irrelevant. No compliance, no dice.

Clearly there are serious issues in the Samsung ecosystem: Support for non-Samsung devices, app provisioning into the KNOX container, app vendors willing to subjugate identity to the device, and so on. But both sides have hurdles.

That’s my take. Bring on the comments – and expect a counterpoint from one of our other analysts!