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 that 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 to 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
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
How are API keys protected?
Other Benefits of Single-On
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.
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 is the chief technology officer with Vordel. As CTO 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. O'Neill is author of the book, Web Services Security, and a contributor to Hardening Network Security, both published by Osborne-McGrawHill. O'Neill is also a representative of the Cloud Security Alliance, where he is a member of the Identity Management advisory panel.
Get HelpContact Us
Follow Us on: