The Cloud Authentication Challenge

Everyone “knows” that one of the largest issues holding back wider adoption of the Cloud is security. How can information that is stored in the Cloud be truly secure? The reason the Cloud is so challenging is that many people, both technical and non-technical, don’t fully understand what technologies they need to make it usable and secure at the same time. Authentication—determining that a user is a valid user—is key.

Authentication is one of the most significant challenges of working in the Cloud. When servers were within our own datacenters, most organizations had a centralized authentication process, usually Microsoft Active Directory, and all the audit logs the security folks needed were readily available. A few of the more mature organizations also implemented a multi-factor authentication solution where users would need a special pin code from their phone or a token before they could get access to the network.

The Cloud world is remarkably different from the traditional way authentication is done in both in scope and functionality. To begin with, each Software as a Service (SaaS) provider, Infrastructure as a Service (IaaS) provider, and Platform as a Service (PaaS) in the Cloud has its own authentication process to authorize users and allow access to the respective management consoles. This doesn’t account for the management of OS, Application, and Appliance authentication for resources that exist within each of those Cloud solutions.

Many of the benefits we previously had under the centralized model, such as centralized control and available audit logs, are unavailable in the Cloud. While security professionals recommend against using the same username and password on multiple sites, users often don’t listen. Without a viable authentication process, when a hacker steals usernames and passwords from one Cloud service, chances are good that the hacker will be able to access other accounts of those same individuals.

For corporate security teams, the challenge is magnified because there may not be a mechanism to know that users are re-using their passwords on multiple sites or be a way to prevent it. That presents a real risk to corporations, especially when the data being put into the Cloud is sensitive or could disclose trade secrets.

The good news is that Cloud providers recognize the extent of this problem and many have implemented different APIs within their services to allow organizations to manage their users. Salesforce, Google, Twitter, Facebook, and Amazon all have APIs to facilitate authentication and account management. Salesforce, obviously being more focused towards corporate customers, has a full range of options including Federation, which supports the use of single sign-on, and Delegated Authentication, which supports tying in an organization’s LDAP directory for authentication.

Another interesting twist on the current authentication options in Cloud services is the re-use of one Cloud provider’s authentication solution within a different Cloud provider. An example of this would be to use the OpenID Connect protocol to link Salesforce accounts with their respective Google accounts and then rely on just Google’s authentication mechanism for both services. For customers of Salesforce and Google Apps for Work, this is quite an advantage to securing their Cloud space. Not only can they centrally manage the account provisioning process, but can also enable advanced security features supported by Google such as multi-factor authentication.

To lend even more flexibility (and confusion) to the authentication landscape, there are third-party SaaS vendors that specialize in aggregation of authentication services. These companies can aggregate multiple authentication sources and present a “virtual directory” that consists of multiple authentication sources. Their products can also present a multi-tenant style authentication architecture that allows the presentation of OpenID, SAML 2.0, OAuth, LDAPS, and others via an authentication gateway.

As Cloud services continue to mature, it should be expected that most organizations will begin to capitalize on these APIs. What’s really exciting, however, is when these concepts become prevalent inside our traditionally on-premise networks. Federation and authentication APIs mean organizations no longer have to be dependent on a Microsoft Active Directory model or traditional LDAP infrastructure. In fact, most organizations will begin moving to the Cloud in limited capacity within the next few years, if they’re not there already, and it will become natural for traditional networks to tie into their Cloud counterparts for authentication rather than the other way around.

Regardless of the approach, it’s safe to say that the authentication paradigm has changed. Considering the ease with which passwords are phished, and the number of usernames and passwords people have, it’s not surprising that there are disruptive technologies being brought to market. As security and IT practitioners, any time we spend getting a better understanding of these concepts is a step in the right direction—they won’t be going away any time soon.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *