Extend the Enterprise into the Cloud with Single Sign-On to Cloud-Based services

by Mark O’Neill, CTO, Vordel

In this blog post we examine how Single Sign-On from the enterprise to Cloud-based services is enabled. Single Sign-On is a critical component for any organization wishing to leverage Cloud services. In fact, an organization accessing Cloud-based services without Single Sign-On risks increased exposure to security risks and the potential for increased IT Help Desk costs, as well the danger of “dangling” accounts from former employees which are open to rogue usage.

Let’s take a look at Google Apps and the concept of Single Sign-On. Organizations are increasingly using Cloud services such as Google Apps for email and document sharing. Google Apps, especially Gmail, are a popular option for organizations making their first foray into leveraging Cloud-based Services. While the cost advantages of this model are compelling, organizations do not want to create a whole new set of accounts for their employees in the Cloud, or force their employees to remember a new password.

The solution to this problem is to allow users to continue to use their own local accounts, logging into their computers as normal, but then seamlessly being logged into the Cloud services. In this way, the user experiences a continuous link from the corporate systems, such as their Windows login, into the Cloud services, such as email. This is known as Single Sign-On, and is enabled by technologies such as Security Assertion Markup Language (SAML). This allows operations staff to manage their organization’s usage of the external Cloud services as if they were a part of their internal network, even without the same degree of physical control. As a result, the usual problems of password synchronization, user provisioning (adding users) and de-provisioning (removing users), and auditing are minimized.

When an organization wants to use Gmail for its employees, they usually get a key from Google to enable single sign on. This application programming interface (API) key is only valid for the organization and enables its employees to sign in. As such, it is vitally important this key is protected. If an unauthorized person gets the key they can log in and impersonate the email account owners, share Google documents and generally have unlimited access to users email and documents.

A good solution to overcome this issue is to provide Single Sign-On between on-premises systems and the Cloud. However, the key security requirement of Single Sign-On is protection of API keys. In effect, these API keys are the keys of the kingdom for Cloud Single Sign-On. I will discuss the topic of protecting API keys in a future blog, but want to underscore the importance of their security. After all, if an organization wishes to enable single sign-on to their Google Apps (so that their users can access their email without having to log in a second time) then this access is via API Keys. If these keys were to be stolen, then an attacker would have access to the email of every person in that organization, by using the key to create a signed SAML assertion and sending it to Google. Clearly that must be avoided.

Single Sign-on Options:

There are two broad paths for any organization interested in implementing Single Sign-On today. One option is for an organization’s developer staff to create Single Sign-On via the sample code offered by all Cloud Service providers for the purpose of connecting to Cloud Services. This approach appeals to developers who want to create and code the connections into existing applications. The programming approach means it is the developer who is doing the work by writing code and making the connections to an organization’s applications.

A second approach is to take an off-the-shelf product like a Cloud Service Broker and use this technology to configure the managed or “brokered” connection up to the Cloud service. If an organization decides to leverage an off-the-shelf product, it usually results in systems doing the configuration and does not involve developers writing code. This is because the Cloud Service Broker sits external to the application and acts as a piece of network infrastructure brokering the connection. As a result, the management of this process comes under the responsibility of those managing the network infrastructure. Additionally, the Cloud Service Broker brokers the connection to the Cloud without having to get mired in the intricacies of particular programming of APIs for each product.

Implementation of Single Sign –On:

The implementation of Single Sign-On for a large enterprise is challenging. Typically it is a long involved project that requires the stitching together of applications that were not originally intended to work together, with products which use proprietary approaches and proprietary (read: not SAML or OAuth) tokens. This approach is labor intensive and time consuming. Within the consumer world the rise of more agile technologies like REST and the Web Service stack has enabled the more efficient adoption of Single Sign-On. Additionally, the growth of Cloud based services like Google Apps means we are seeing more lightweight Web technologies. These more straightforward Web technologies mean organizations, especially SMEs, can leverage off-the-shelf technologies such as a Cloud Broker to broker users’ identity up to the Cloud provider and secure the API keys via Single Sign-On

How are API keys protected?

API Keys must be protected just like passwords and private keys are protected. This means that they should not be stored as files on the file system, or baked unto non-obfuscated applications which can be analyzed relatively easily. In the case of a Cloud Service Broker, API keys are stored encrypted, and when a Hardware Security Module (HSM) is used, this provides the option of storing the API keys on hardware, since a number of HSM vendors now support the storage of material other than only RSA/DSA keys. The secure storage of API keys means that operations staff can apply a policy to their key usage. It also means that regulatory criteria related to privacy and protection of critical communications (for later legal “discovery” if mandated) are met.

Other Benefits of Single-On

In addition to protecting API keys it is worth noting the cost and productivity benefits Single

Sign-On offers an organization. Consider the fact that users with multiple passwords are also a

potential security threat and a drain on IT Help Desk resources. The risks and costs associated with

multiple passwords are particularly relevant for any large organization making its first steps into

Cloud Computing and leveraging Software-as-a-Service (Saas) applications. For example, if an organization has 10,000 employees, it is very costly to have the IT department assign new passwords to access Cloud Services for each individual user and indeed reassign new passwords whenever a user forgets their original access details.

By leveraging Single Sign-On capabilities an organization can enable a user to access both

the user’s desktops and any Cloud Services via a single password. In addition to preventing security

issues, there are significant costs savings to this approach. For example, Single Sign-On users are

less likely to lose passwords reducing the assistance required by IT helpdesks. Single Sign-On is also

helpful for the provisioning and de-provisioning of passwords. If a new user joins or leaves the

organization there is only a single password to activate or deactivate vs. having multiple passwords

to deal with.

Conclusion:

Although Single Sign-On is not a new concept, it is finding new application for connecting organizations to Cloud service providers such as Google Apps. It is a powerful concept, enabling users to experience seamless connections from their computers up to their email, calendars, and shared documents. Standards such as SAML are enabling this trend. A Cloud Service Broker is an important enabling component for this trend, enabling the connection while protecting the all-important API keys.

Mark O'Neill – Chief Technology Officer - Vordel

As CTO at Vordel he oversees the development of Vordel’s technical development strategy for the delivery of high performance Cloud Computing and SOA management solutions to Fortune 500 companies and Governments worldwide. Mark is author of the book, “Web Services Security”, and a contributor to “Hardening Network Security”, both published by Osborne-McGrawHill. Mark is also a representative of the Cloud Security Alliance, where he is a member of the Identity Management advisory panel.