Who goes there?

A common theme that runs through successful books and movies is misdirection. Are the good guys really good and the bad guys really bad? Identity is everything. In the real world, you do not want to be the good guy who finds out at the end that your colleague or business partner was actually an imposter. The same holds true for companies storing their data in the cloud. Separating reality from fantasy and security from insecurity are fast becoming the daily fare of CISOs and their cloud security strategies.

Public cloud service providers tout cost savings and flexibility over on-premises data centers, but there is another oft-quoted benefit they pitch enthusiastically: security. Marketers will tell you that cloud services can protect your data and keep you compliant far better than you can do so yourself because it is a core competency for them. But is it? Ultimately, the service provider is responsible for protecting its investment — the infrastructure. In the vast majority of cases, the owner of the data is responsible for security of that data in the cloud, according to the fine print of the terms of service.

the fine print of the terms of service. As a result, a company must go to great efforts to authenticate the users who access its assets properly or risk handing over data to an imposter.

While cloud authentication is a key component of the cloud computing narrative, it is also notoriously difficult to implement, says Paul Simmonds, CEO of the UK-based Global Identity Foundation. He helped create the Jericho Forum in 2004, a global thought leadership group for CISOs, before becoming the global CISO for AstraZeneca and Imperial Chemical Industries Plc in the UK.

The Jericho Forum, now part of The Open Group’s Security Forum, explored how security professionals should react to the erosion of traditional network and organizational boundaries.

One of the biggest problems that the Jericho Forum identified was the “locus of control,” determining if the forces that impact security were internal or external to the organization. Identity and access management (IAM) works well when everyone in the same organization is working on the same systems, says Simmonds.

“If you can all play in the same locus of control – in other words, you play with my identity system in this instance – then you can make it work,” he says. “The instant you step outside this, it all goes to hell in a hand basket.”

That makes cloud authentication difficult because cloud-based services live in their own domains, separate to the customer’s and outside of their control. The customer must send the appropriate authentication information between its own domain and to each of the cloud providers it employs.

There are a few ways to do this, says Simmonds. One approach is to bolt together an on-premises program of your own that manages authentication for many cloud-based services at once.

based services at once. Steve Biswanger, director of information security at Alberta, Canada-based oil and gas company EnCana, began the company’s cloud authentication 15 years ago exploring applications such as health benefits and stock options. “We had different user names and passwords for each one. The users really disliked that,” recalls Biswanger, who is also president of the CISO division at the CIO Association of Canada.

EnCana procured an on-premises single sign-on (SSO) product that kept user credentials in a local database. It authenticated users for multiple applications at once by “credential stuffing” login details into multiple web applications’ login forms. It was a low-tech approach, he recalls.

Providing locally-hosted SSO options seems to be a first step for many organizations. Kim Tracy, now a visiting instructor of computer science at Illinois Wesleyan University, helped put together the cloud authentication system at Northeastern Illinois University (NEIU) where he was CIO until 2015. Like many of his industry colleagues, he was coping with legacy, on-premises applications alongside newer cloud options.

“We had a mix. Some of them were cloud-based, and they were with different providers. That’s one of the things that makes it tough,” he says.

Another complication was the range of users that he had to serve. He had some 12,000 students and approximately 2,000 employees, but there were also prospective students to handle.

“We hosted most of the basic credentials in our own local directories,” says Tracy, adding that his infrastructure supported both Active Directory and LDAP directories to support the different providers’ authentication mechanisms. The directory systems integrated with a locally hosted SSO tool connected to an access portal. The SSO system interacted with each application, cloud or on-prem, using custom integrations. “That’s a real pain to host locally, and it’s a real pain to get enough staff that really understood this stuff. We were always behind; as we lost staff it became even harder to maintain,” he says.

Consolidating in the cloud

Some have taken a different approach to cloud authentication by shifting some of their credential management and authentication capabilities into a single cloud service, enabling it to access other applications inside that cloud service provider’s domain.

Steve Vu, who manages leadership, management and enterprise architecture for a large, enterprise software provider, began his Azure-based authentication project using individual subscription accounts for the service. The company wanted to let employees experiment with the system.

“Then we got an enterprise Azure enrollment that we tied to our Microsoft enterprise software,” he explains. In this arrangement, companies can list various departments within an enterprise enrollment, which in turn can contain different accounts.

“To handle authentication, we tied in Active Directory through our Office 365 service,” Vu says. That allowed users to access Office 365 and Azure via the same account.

The company replicated its on-premises directory with the cloud-based Azure Active Directory, enabling Azure applications to authenticate users directly in the cloud. It also enabled him to mirror the internal roles that his employer had created for its employees into the cloud-based system.

Like Vu’s organization, EnCana migrated much of its functionality to Azure using the service’s own Azure AD system to authenticate its employees with other third-party cloud providers.

“Now I can log into a service or modern SaaS apps using modern authentication techniques,” says Biswanger. “From the user experience perspective it all looks the same, but it’s a lot more resilient.”

This replaces credentialstuffing with more modern authentication protocols that enable machines to speak to each other securely and exchange a richer set of information, and it is an important part of the modern cloud-based authentication process, says Clive Longbottom, founder of UK-based tech advisory firm Quocirca.

“Keep away from simple username/ password pairs: use 2FA (two-factor authentication) tokens, biometrics, whatever,” he says. “Try to use passwords that even the user doesn’t have to know, either through SSO systems , or via technologies such as OAuth.”

OAuth, managed by the Internet Engineering Task Force (IETF), is a framework for authenticating and authorizing software to make requests for an application programming interface (API). OAuth essentially enables cloud applications to ask each other for services, and as such can be used for many different online interactions. OAuth works at a relatively low layer of the cloud user-authentication technology stack, and is a platform on which to build other technologies.

One such technology is OpenID. Created by the non-profit OpenID Foundation, OpenID is a vendor-independent authentication system for website owners. Users can get OpenID credentials from various providers.

In an OpenID transaction, a website supporting the standard (the “relying party”) gives a visitor the option to present their OpenID credentials in the form of a URL. The browser directs the user to their identity provider’s website, where they log in.

Optionally, the relying party can ask the identity provider for extra credentials such as name, age, gender or email address. In this scenario, the identity provider allows the user to decide which information they provide.

Once the user has authorized themselves for the relying party via OpenID, they can then return and log in automatically without re-authenticating. OpenID Connect is the latest version of this protocol and is built atop OAuth 2.0. It serves web, mobile and JavaScript-based clients. Consumer-facing websites along with enterprises and government organizations use the technology, which can be extended to support optional features such as encryption and session management.

Another common protocol used in cloud authentication is the Security Assertion Markup Language (SAML 2.0). Created by standards body OASIS, the protocol allows two domains to exchange authentication and authorization data with each other.

Based on XML rather than more lightweight dataexchange mechanisms such as REST (Representational State Transfer) and JSON (JavaScript Object Notation), SAML performs broadly the same function as OpenID, but with some important differences.

For example, whereas OpenID refers the relying party to an identity provider, SAML 2.0 exchanges information between domains that already trust each other and have an existing relationship.

Offloading cloud authentication via IDaaS

Some prefer to offload management of ID issues entirely to an external provider. Putting the entire authentication process into the cloud will become common practice, says Raef Meeuwisse, an ISACA governance expert and author of Cybersecurity for Beginners, whose day job is director of cybersecurity and data privacy governance at consulting firm Cyber Simplicity in London.

“Most organizations can’t afford the security expertise and the scale of technologies that they need to be able to run authentication in-house,” he says, pointing to technologies such as multifactor authentication and geo-detection as examples of how technologies are changing.

“Cloud authentication will be the thing that is running most enterprises,” he continues. “Most enterprises will subscribe to one of a few cloud authentication technologies, and that will be the way to go.”

NEIU is a case in point. After his departure, former NEIU CIO Tracy says that the university cut through the whole tangled mess and handed authentication over to an ID-as-a-Service (IDaaS) provider. It was only possible at that point because thirdparty services had evolved to manage identity in the cloud, Tracy argues. He cites not only simplicity but also resilience as a benefit.

“Sometimes our directories or network connectivity would go down. There had to be an ability to log in with cached credentials,” he says. “This cloudbased ID management system could manage the timing between the provisioning of the resources and the change of the password in the directory, so you have fewer of those timing problems where something gets ten minutes behind and (your users) can’t log in.”

A sense of entitlement

Even when shifting some functionality into the cloud, CISOs often find themselves with challenges, one of which involves what GIFs Simmonds calls “entitlements.” It is one thing to authenticate access to a cloud-based application, but it is more complex to tell the application what the user is entitled to do with it. On well-configured software, user privileges will vary by role.

“The challenge is can I pass enough rich information out of my identity system such that the entitlement layer in front of the cloud service is capable of making a rules-based decision?” Simmonds asks. That depends not only on the maturity of the IAM system, but also on the cloud application’s ability to segment functionality based on those user entitlements.

This is a challenge EnCana is still facing. It might have moved some authentication functionality to Azure, but it still uses what he calls a “redirection shim” to authenticate with third-party services that reside outside the Azure cloud. He deals with approximately 70 separate cloud services.

EnCana stores the credentials and the authorization for each third-party, cloudbased application in a shadow account in the third-party cloud service tied to the user’s account in Azure Active Directory. However, when a user’s status and requirements change due to a promotion, transfer, change of job responsibilities or other event, administrators must change their authorization entitlements manually in each cloud application that the user can access. Would it not be more efficient to do this centrally?

“On the surface that would be ideal,” says Biswanger, but he argues that the problem is simply too complex. “Even when we’re doing internal provisioning and I hire somebody, thinking about what they should have access to is a reasonably complex enough bit of work, just for my company.”

Providing a consistent experience among internal and external applications is another common pain point. EnCana has approximately 800 applications running internally on its own premises, aside from the cloud-based applications.

“For anything that’s in the new authentication methods — using OAuth- or SAMLbased authentication with assertion capability — it’s a nice experience. It works on mobile devices, home devices and my corporate desktop,” Biswanger says. “For anything that’s still in my datacenter, sequestered from the Internet that doesn’t support modern authentication, that is now the crappy experience.”

Another problem is managing identities from third-party companies that have partnered with EnCana. A contractor might work for EnCana and for five other companies. All those organizations could use the same cloud-based directory service. One might think all of the systems could all log on to each other’s systems using a single ID, but it typically does not work that way. The contractor company’s employees must maintain multiple sets of credentials — one to access their own employer’s systems and the others to log into each of their customer’s computers.

“We need some mechanism by which when you work for an outsourcing company, my company trusts the outsourcing company, and we only have to manage (one) identity there,” Biswanger says.

He is describing federated identity, which as a concept has been around for 15 years or more. It is a difficult concept to implement, says Simmonds, and one problem is managing transitive trust.

For one thing, Company A might trust Company B, and Company B might trust company C. Does that mean Company A can trust Company C? Then, what if Company D joins?

“It’s what Jericho referred to as the n factorial problem — once you get to n>3, it doesn’t work,” says Simmonds. “You need a huge amount of independent oversight to make it possible.”

These cross-domain challenges are among the many reasons to err on the side of caution when providing access to cloud applications, the experts warn.

“Make sure that privileged access is provided to as few people as possible and even where it is provided, try to ensure that those users still do not have read/write activity to data that they should not see,” says Longbottom. “Ensure that the means of access are not shared. It has to be a case that any action can be drilled right down to a specific individual.”

Jeff Spivey, past board director of ISACA and CEO of Charlotte-based security consulting firm Security Risk Management Inc., highlights governance as a key talking point when creating cloud-based authentication products.

“From day one, audit must be involved in the whole process to ensure that whatever is being constructed in the cloud is acceptable to the auditors and executive management and the board of directors that own all of this,” he says. Companies must decide the level of authentication necessary based on the sensitivity of the cloud-based data that a user is accessing.

How can companies factor that level of governance and risk-based policy into their cloud authentication strategies?

At EnCana, Biswanger is implementing a virtual identity management layer to help with this issue. The on-premises software will abstract the identity information from Azure and other identity data sources in the organization, providing a more functional front-end interface that applies locally defined policies and business logic to the authorization process.

“The dream there is that (it) allows me to log in based on context and get different access,” he says. “I can apply those rules at authentication time. It’s putting a lot more smarts at that identity layer.”

Cloud authentication might be difficult, but it is an important part of the cloud computing story, and organizations should have both the human resources and the budget to tackle it. An option is to use a third-party service provider to manage it if the company cannot. It presents part of the often-unacknowledged overhead associated with cloud security.

Allocate 10 percent of the savings you expect from a cloud computing strategy and commit that to security management, advises Simmonds. Cloud authentication will be a part of that budget. He recommends that companies do the same for service management. Suddenly, those return on investment figures might look less promising, but they will also be a lot more realistic.