Be proactive and prepare your AD environment for the future
What aspect of cloud computing do identity professionals care most about? The answer is cloud identity. What is cloud identity? What are the limitations of existing identity and access models that you’re already familiar with? What are the different methods of managing cloud identity? Once you have a knowledge framework in place, it’s much easier to make sense of the various moving parts that make up cloud identity and thus understand it as a whole. Perhaps a good place start this discussion is with my definition of enterprise cloud identity:
Enterprise cloud identity is the practice of securely extending the core corporate identity infrastructure outside an organization’s perimeter to manage access to distributed services, applications, and infrastructure.
Creating a general definition of a complex topic often requires some simplification; this definition is a bit simplified in that it ignores private and hybrid cloud models. The public cloud, however, presents both the most significant growth and the toughest security challenge, so this definition fits most cloud scenarios.
The first half of the definition—"securely extending the existing corporate-identity infrastructure outside an organization’s perimeter"—is something that’s hard for the traditional enterprise identity and access model (IAM) to do. Here's why.
In the enterprise realm, your digital identity is dictated by the corporation for which you work. Your identity is kept in one or more identity stores, such as Active Directory (AD) or a Human Resources database. Authentication is the process of confirming a user's identity; the Kerberos protocol handles the authentication process as a part of AD services. Overall, identity is tightly controlled to stay within the corporate perimeter. As a result, collaborating with other companies usually involves separate accounts at the other company, or perhaps a limited trust relationship between the companies if long-term collaboration is planned.
Cloud computing complicates this traditional, password-based model because cloud services aren't on your protected corporate network—they’re on the wide open internet. These services naturally require some kind of identity to use them. The simplest (and default) approach is to create a separate set of accounts on the application’s website for users who need to access that application. As anyone who has worked in identity for more than a month can tell you, this approach creates problems. Is the session between user and service encrypted so that the password isn’t exposed in transmission? Do you trust the security measures of the (possibly quite small) service provider? Who manages the creation of these accounts when users need to access the application? Who changes their access rights as their role changes? Who manages the separate set of passwords? (The user does.) Can you prevent users from re-using their corporate password and thus potentially exposing it? (No.) What is the mechanism for users to recover their password when they’ve inevitably forgotten it? Can this account-recovery mechanism be gamed (by guessing the answer to common security questions)? Who terminates access to the account immediately if the user has been terminated? Your company might be able to manage such concerns for just a few cloud service providers, but when you scale it for the predicted growth in cloud services (large enterprises are projected to use hundreds or even thousands of SaaS providers within the next few years), you can see how this brute-force approach won’t keep up.
Another solution is to use the vendor’s own connector to synchronize your identity data with the solution. Doing so is generally an improvement over maintaining separate accounts, but it’s still a less-than-perfect solution. For example, Microsoft’s Online Services Directory Synchronization for Office 365 assigns a new password to the synchronized account that must be maintained manually. This automates account creation but still leaves the issue of manual password management. Also, though these connectors may scale up nicely for the vendor's own customers, they don’t scale out. They work only for that vendor.
The ideal approach is to reuse the identity you already have in your enterprise, thus eliminating the duplicate-account management issues. Doing this with the password-based (aka shared-secret) model, however, still requires sending password data over the Internet to the service. Sending password data across the internet is a bad idea. It’s certainly not a sane practice to land one of your company’s domain controllers (DCs) at every service provider and open ports on your firewall to allow replication between it and your other DCs! Passwords don’t have any limitations in scope. If someone is given a password, or cracks it, they can gain access to a system (assuming he or she has network or physical access to it) and its information until that password is changed or the account is deactivated. If you drop your car keys on the sidewalk, anyone who picks them up and finds your car can drive away with it until you have the locks changed. Pamela Dingle of Ping Identity likes to say, “Trying to push passwords into the cloud is like putting the bank vault door on the outside of the bank.” The sidewalk is the Internet; anyone strolling by can take a crack at that vault. So, securely extending your existing corporate identity infrastructure outside your organization’s perimeter, without entering another password once you’ve logged on to your corporate network (aka Internet Single Sign-On—SSO) requires another method—as you'll see shortly.
The second half of my definition of enterprise cloud identity is "to manage access to distributed services, applications, and infrastructure." This is authorization, which is the process of controlling the authenticated user’s access to network resources (e.g., file server, internal corporate web page). You need authorization to manage access outside your perimeter, just as you do inside your perimeter. Inside, AD takes care of this by managing group membership in a user’s security token. And though it’s not strictly identity management, a third identity-management function is auditing: The feedback loop that ensures your identity and access-management configuration is what you expect it to be. Account management in general—and authorization and auditing in particular—are available in cloud identity, but they vary significantly in their maturity compared with federation, and in their adoption from provider to provider.
Fortunately, there’s a way to securely extend your existing corporate identity infrastructure to manage access to cloud services. Federation—or federated identity—is a collection of standards and technologies that enables both authentication and authorization data to securely pass between an identity provider (e.g., your AD implementation) and service providers (e.g., Microsoft’s Exchange Online mail hosting service, Zoho’s online business applications) without exposing password data. In federation-speak, service providers are also known as relying parties because they rely on the identity data that the identity provider gives them.
How does federation manage this trick? To the AD administrator familiar with Kerberos, federation uses security tokens in much the same way that Kerberos uses tickets. Unlike a password—which is usable no matter who has it, when they got it, and when they use it—AD's Kerberos ticket and federation’s security (e.g., Security Assertion Markup Language—SAML) token are tightly restricted on when they’re valid. If a bad guy grabs them, they’re not usable out of the context they were originally generated for.
A good parallel for the Windows administrator is the difference between Windows NT’s NTLM authentication and AD's Kerberos authentication. NTLM uses a shared-secret authentication method, sending a hash of the user’s password over the network, whereas Kerberos uses a digitally signed and encrypted ticket with specific conditions attached to its use. Similarly, separate accounts for a service provider require entering passwords over a (presumably) encrypted connection, whereas federation uses a digitally signed and encrypted token with specific conditions attached to its use. Neither a Kerberos ticket nor a SAML token contains password data.
Note that federation doesn’t eliminate passwords; you still have to log on to your corporate network with a password. It does, however, keep that password local to your protected corporate environment instead of transmitting it over the Internet. Once you’ve set up your first few federated trusts, it’s a straightforward matter to set up new ones as your business requirements change. And federation isn’t only used over the internet; it can also be used to enable authorization and authentication for web services inside your own company.
There are a number of federation solutions available today. Oracle’s Identity Federation, Microsoft’s Active Directory Federation Services (AD FS), and Ping Identity’s PingFederate are all ways you can set up federated trusts with varying degrees of complexity. In upcoming Windows IT Pro columns and articles, watch for deeper dives into federation and how it works. For more information, see "How ADFS "Does" Identity Federation" (Instant Doc ID 95469).
Remember, not only do you need to securely extend your identity infrastructure, you also need to be proactive about it. Whether your IT department is ready for it or not, your users will use (probably already are using) cloud services; they’re just too easy to set up. If you haven’t set up a way for them to easily re-use their existing identities on their cloud service provider, they’re going to set up duplicate accounts to get their work done. And when one of these users leaves the company or gets terminated, the odds are very good that their account will remain active and open to do with as they see fit. You need to design and implement a cloud-identity strategy for your company’s security.
Enterprise cloud identity is about taking the identity infrastructure you’ve built up so carefully over the years and securely extending it for the next phase of computing. Federation is the key enabler for businesses to accomplish this. How deeply you need to understand it depends on whether your role is AD administrator, web services developer, or end user. But everyone will be using it in the future.