Single Sign-On For The Cloud

Get the full-length single sign-on and the cloud report

>> See all of our reports <<

When it comes to integrating cloud applications into a corporate environment, one of the biggest challenges for many IT shops is identity management. Users often create their own logon credentials to business-related cloud applications. This can lead to a variety of problems, including the use of easy-to-crack passwords and the difficulty of cutting off access when users leave the company.

So how do you build an identity management framework for all of your cloud applications? There are four choices, all of which involve Active Directory, Microsoft's popular directory software, and one that uses the cloud itself.

AD or another LDAP-based directory should be at the heart of your cloud ID management strategy. Leveraging AD to manage access to cloud apps addresses a number of security, risk, and compliance issues. It also reduces the administrative burden of adding and removing users, facilitates the deployment of single sign-on, and lets you do some cool things with role-based authentication based on various group memberships and user attributes.

The four approaches you can use for managing access to cloud apps are either full or partial synchronization of Active Directory, federation, and identity-as-a-service. Here's how they work.

Active Directory Synchronization

With full AD synchronization, you leverage Active Directory to authenticate users to a particular cloud application. Enterprise single sign-on isn't really all that important for companies that use one or a small number of cloud apps. This situation applies to 27% of 166 respondents to InformationWeek's State of Cloud Computing Survey, who have only one cloud application provider. In this case, you simply let your cloud provider synchronize all user objects in AD at a predetermined interval.

The benefit of full synchronization is that you can leverage your directory for authentication. The drawback is that you must punch a hole in your firewall to allow incoming LDAP queries from the cloud provider.

Another full-synchronization option is to install an agent on your domain controller that synchronizes AD outbound over SSL. This is a better approach, because it doesn't require a separate port to be opened in the firewall. Note that the level of detail that a cloud provider will synchronize can differ. For instance, one provider might only synchronize the user attributes needed to confirm a user's identity, such as the user ID, first and last name, and group membership. Another provider might synchronize your entire directory. That leads to the partial synchronization option.

For security and compliance reasons, a company may not want to hand over a full copy of its directory services infrastructure to a third party. With partial synchronization, you only copy the attributes necessary to identify a user.

Here's how it works: When an employee logs on to a cloud application, the app forwards the logon request to the employer's Active Directory domain controller to validate the user. With this approach, you get real-time AD authentication but without the security and compliance issues of having a full copy of your directory hosted off-site. The downside is that if a domain controller isn't available to validate the request in real time, then the user won't be able to authenticate to the cloud app.

Federation, the third approach to managing access to cloud apps, grew out of the need for companies to provide access to applications for business partners and suppliers. Two or more companies set up a system that allows access to specific systems using predefined authentication and access mechanisms.

The concept is simple, but implementation is hard. Companies have to deal with complex identity standards and mechanisms such as identity tokens and digital certificates. You also must purchase, configure, deploy, and manage the infrastructure required--including dedicated servers to run the federation infrastructure--in order to make it work.

Microsoft offers Active Directory Federation Services, which is free with the base Windows operating system. ADFS supports many of the standard identity protocols in use today, including SAML 1.1 and SAML 2.0, WS-Trust, and WS-Federation. IBM and Oracle also offer comprehensive federation products: IBM's Tivoli Federated Identity Manager and Oracle's Identity Federation.

Identity-As-A-Service

Another option for simplifying ID management for cloud applications is to turn to the cloud. A new category of providers now offers identity-as-a-service, or IDaaS. With this service, an identity provider, or IDP, acts as a broker between your employees and the cloud services they use. The IDP makes it easier to manage multiple cloud services, and provision and deprovision users.

Consider this scenario: Company A provides Salesforce.com, Google Apps, Office 365, Dropbox, and WebEx as corporate-issued Web apps. In the absence of an ID management product or service, each user (or IT) would have to create a user profile within each individual application, and employees would log on separately to each application. While the user's credentials could be tied to AD, the user would still have to log on manually to each app.

With IDaaS, instead of logging on to each application separately, you establish a session with an identity provider. The IDP responds to requests for credentials by a cloud Web application, typically via standards such as SAML or OAuth, automatically logging you on to the cloud app. Many IDaaS providers offer a portal or will connect to a company intranet that lists all the user's cloud applications. The user clicks the appropriate icon and is logged on to the application.

With IDaaS, companies still need to link Active Directory to the IDP and, for some, that's a drawback. However, cloud identity providers typically don't store passwords, only user attributes. Your users' passwords aren't at risk if the provider's system is hacked or breached. You can minimize the number of user objects that you sync with an IDP if you have specific access needs. For example, if only the sales and marketing team needs access to Salesforce, then you can limit AD synchronization to the specific organizational units within Active Directory that contain the users needing access to Salesforce. Organizational units are used to group users or departments that share common security policy requirements.

Here's another plus: With IDaaS you get some cool security features that would be more difficult to implement in the absence of an identity management tool. For example, you could configure an access control policy that says if a user isn't connecting from an internal subnet (that is, the employee is off the corporate network), then force two-factor authentication.

But here's where identity providers may really be worth their weight in gold. The good ones have already federated with the most popular cloud application providers. So instead of spending time building and managing a federation server farm, and the SSL and token-signing certificates that are required to make it work, you can dump that responsibility on an IDP. And instead of syncing AD with 10 different cloud providers, you can outsource that task to a single vendor, or in this case, your IDP of choice.

There are many provider choices if you're considering IDaaS: ActivIdentity, EmpowerID, Janrain, Intel Cloud SSO, PingFederate, OneLogin, and Symplified are some of the vendors that offer cloud identity management help.

User Provisioning

The ability to provision and deprovision user accounts fast is perhaps one of the biggest advantages of using an identity provider. If you were just using Salesforce and needed to bulk import 100 new employees, you could do that with the DataLoader tool that Salesforce supplies. However, that's a manual, potentially cumbersome, process.

Alternatively, you could leverage some of the APIs that Salesforce exposes to provide customers with a range of automation tasks, including user account management. But most IDaaS vendors have already integrated those APIs into their identity clouds. That means when you create new users in Active Directory they'll automatically be synced to your IDP, and from there, the IDP will make an API to create the new user account within the cloud application. Ultimately, you're using AD to control group-based access policy and to add and remove users allowed to access your cloud apps.

While IDaaS has many benefits, it can open up a number of compliance issues. Compliance mandates that deal with authentication and access control, such as PCI and Sarbanes-Oxley, will look closely at an IDaaS implementation, because for all intents and purposes, you're exposing critical applications (that is, Active Directory) to the Internet. An auditor will scrutinize password complexity policy, along with your ability to centrally manage and review logs. Log management and review is important, because it can provide early warnings of intruder attempts to access to your systems and employee misuse.

If you have an internal log management infrastructure (or even a cloud log management infrastructure), the vendor you select should be able to provide logs of user account activity. At the very least, there should be adequate logging features within the cloud identity platform itself that you can access.

Cloud applications are a normal part of the business applications and tools mix that employees need to do their jobs. Given the variety of options that IT has for managing user access to cloud services, there's no reason to leave identity and access management of business applications in users' hands. And as more IT shops make the transition to cloud apps with highly mobile workforces, IDaaS will become more widely accepted and deployed.

InformationWeek: Oct. 15, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)