kitson - Fotolia
As enterprises continue to expand into the cloud, the question of identity -- how users are identified, authorized...
and authenticated to the services in question -- becomes increasingly important. Consider the typical enterprise: first, cloud adoption is likely to start small and then snowball, which is a particularly common occurrence with software as a service. For example, a small team might begin using a service like Slack or Basecamp to help it solve business problems. As value is demonstrated and more personnel embrace the service, usage will begin to expand to other areas. There could be large-scale cloud deployments like Office 365 or SalesForce, which have their own mechanisms for handling user identity, such as Azure Active Directory. Users will be accessing applications from a myriad of devices such as mobile, PC and tablets, both from inside and outside the organization, and internal applications using internal identity stores and potentially multiple AD forests or domains, application-specific user stores and databases, with single sign-on mechanisms already in place to service the existing technology footprint. It can all get really complicated, really fast.
All this makes the question of identity both more important - and more complicated - than might otherwise be the case. Many cloud services require application-specific username and password combinations. Others have the option to leverage external identity providers: "enterprise-grade" identity providers, and in some cases, consumer-focused services like Google, Twitter or Facebook. It's a common practice for some SaaS applications to leverage these services as identity providers -- the system of record for identifying, authorizing and authenticating users. All of this happens while utilizing a variety of standards and APIs such as SAML, OAuth, SPNEGO and OpenID. At the same time, legacy applications and systems continue to operate the same ways they always have and deal with user identity in their own unique and often proprietary ways.
Resolving complexity or adding more?
As the complexity compounds, it has pushed the development of new ways to manage identity -- in particular, how to federate user identity across multiple cloud services, and between internal user stores and external services in the cloud. Microsoft, for example, has introduced Azure Active Directory, a cloud identity management system that ties together with other services like Salesforce, and with internal Active Directory implementations within an enterprise. This provides a single point for user management, streamlining the user experience and in many cases, facilitating more robust security.
This sounds great in theory, but can also add its own set of challenges. With Azure Active Directory, there have been outages, such as an issue in December 2015 that brought down services dependent on Azure AD, synchronization issues and complex configuration. Not every cloud service -- or legacy internal application for that matter -- will be able to integrate cleanly. There are multiple standards and APIs on the back end, so not every application will interact with a given identity provider and its cloud identity management system in the same way.
So the question then becomes, is it worth it? From a security point of view, is it worth it to add the complexity of implementing federated ID in order to help streamline the user experience and reduce complexity in other areas? As with most things, the answer isn't "one size fits all." There are a few key questions to answer before enterprises wade into these waters. The answers to these questions will dictate the right approach to take with cloud identity management.
Determining the right cloud identity management
Before enterprises undertake any "solutioning," it's important to understand two things, both of which are unique to the environment: the enterprise's technology landscape, and its security and usability requirements. It might sound trite to go back to these two fundamentals, but both are true.
To decide whether a federated ID approach is right for a specific situation -- and before even considering the specifics of implementation -- enterprises will need to understand their own usage: what services they want to federate identity to, as well as what existing identity-impacting technologies they have in place now that they might want to federate with. This is a bigger question than it might seem on the surface. Most organizations of any size will have legacy technologies going back years or decades, but don't have a reliable inventory of what technologies they currently have in place, let alone one that is complete enough to allow a full understanding of what cloud services are being actively used by folks throughout the business. This could include one-off or limited-scope usage. What is included or excluded in the approach will dictate which cloud identity management approaches are viable and which are not.
As with any technology, enterprises will want to understand the requirements of what the cloud identity management system has to do. There is both a usability and security component to this. From a usability standpoint, what are the expectations? Is the expectation that the enterprise will be able to manage some or all cloud services from one platform, including external SaaS, legacy applications and internal apps? If so, the enterprise will have a different set of questions to consider, as compared to a business that is seeking to manage users only in the cloud, or in a narrowly-defined subset of services. Likewise, from a security standpoint, consider an organization's level of comfort with storing and managing information about users outside of the organization. If an enterprise isn't comfortable with that prospect, then architectural approaches that leverage cloud-based identity providers will be a nonstarter. A number of factors can influence this. Are there contractual or other agreements that preclude sharing this information externally? Does the enterprise have employees in jurisdictions where sharing of certain user data is legally constrained? Before making any technology decisions, organizations might require enlisting support from teams like legal or compliance to answer these questions.
Federated ID in the cloud has a lot to offer in terms of benefits. It has the potential to reduce the scope of a tremendously complex and challenging problem, while at the same time making users' lives easier. How often is that the case? That being said, it's not for everybody. The determination of whether this approach is right for a specific enterprise is, once again, a decision that needs to be made on the basis of a systematic and workmanlike understanding of the security requirements, usage expectations and existing technology footprint.
Find out if your enterprise should engage a cloud service broker
Learn how to manage multiple cloud service providers with an inventory
Read about how federated identity management protects Helix Nebula