The focus of several questions I was asked at Interop involved identity management and application access in a cloud computing environment. This makes sense; not all applications that will be deployed in a public cloud environment are going to be “customer” or “market” focused. Some will certainly be departmental or business unit applications designed to be used by employees and thus require a certain amount of access control and integration with existing identity management stores, like Active Directory.

Interestingly F5 isn’t the only one that thinks identity and access management needs to be addressed for cloud computing initiatives to succeed.

It's important to not reinvent the wheel when it comes to moving to the cloud, especially as it pertains to identity and access management. Brown [Timothy Brown, senior vice president and distinguished engineering of security management for CA] said that before moving to the cloud it's important that companies have a plan for managing identities, roles and relationships.

Users should extend existing identity management systems. The cloud, however, brings together complex systems and opens to door for more collaboration, meaning more control is necessary. Brown said simple role systems don't always work, dynamic ones are required. [emphasis added]

--“10 Things to Consider Before Moving to the Cloud”, CRN, 2010 

Considering the emphasis on “control” and “security”, both of which identity management is closely tied, were the top two concerns of organizations in an InformationWeek Analytics Cloud Computing survey this is simply good advice.

The problem is how do you do that? Replicate your Active Directory forest? Maybe just a branch or two? There are overarching systems that can handle that replication, of course, but do you really want your corporate directory residing in the cloud? Probably not. What you really want is to leverage your existing identity management systems where they reside – in the corporate data center – but use its authentication and authorization information to allow or deny access to cloud-based applications.

In a nutshell what we’re doing is using the existing identity access mechanisms in conjunction with the ubiquity of HTTP* to enable cloud-based application access control without requiring replication of identity stores. The architecture uses fairly common security techniques combined in a way that turns public cloud computing-hosted applications into what is effectively a private resource; inaccessible to anyone that hasn’t been authenticated via the corporate infrastructure. Additionally, we employ encryption of in-transit data to keep it secured from prying eyes.

So how does it work?

Basically we’re using BIG-IP Edge Gateway (EGW) as a shielding agent for applications hosted, well, anywhere. Using BIG-IP Global Traffic Manager (GTM) to resolve domain queries, users are directed to the appropriate EGW managed site based on specified policies regarding location, performance, and availability. EGW then verifies user credentials against ActiveDirectory and uses a specially encrypted cookie to encapsulate authorization information that is subsequently used by the application to allow access. Requests to the application that (a) do not come from the EGW and (b) do not have a special cookie are not allowed access to the application. This is similar in implementation to Oracle OAM and CA solutions, both of which F5 integrates with.

Additionally, EGW scans outbound responses to ensure it is valid and adheres to security policies before it is delivered to the user. Cookies are encrypted to ensure they can’t be tampered with, and data is encrypted with the appropriate SSL certificate to prevent in-transit exposure.

Sessions between client and EGW as well as between EGW and applications are encrypted and optimized and data is compressed when it makes sense to do so, based on context-aware policies. While the application and EGW may physically reside in separate locations, EGW can leverage both symmetric and asymmetric optimization to ensure the user is connected without impacting performance. This is particularly advantageous if applications migrate from one location to another as EGW can transition user requests to follow the application with minimal impact.

Ultimately, what this provides is the means to extend corporate identity management and application access systems “out” to the cloud without a physical presence. The ubiquitous and flexible nature of HTTP makes it possible to enable corporate applications to reside in public clouds without concerns that illegitimate users may gain unauthorized access. This also makes it possible to take advantage of SSO (single sign-on) and credential caching capabilities to enable additional authentication for other applications being requested. Control remains within the organization without a requirement to replicate, duplicate, or update secondary or tertiary identity stores.

What’s going to happen for a while with cloud computing, until offerings mature, is that organizations will need to find architectural solutions to extending existing infrastructure and its associated control over security, access, and delivery policies. It’s not so much that there will be a “product” you can buy that will do X or Y, but rather existing solutions will be leveraged in such a way as to provide an architectural solution to the problems that exist when attempting to incorporate cloud-based resources into a broader data center strategy. This F5 architectural solution is just one of many that takes advantage of the way in which applications and the application delivery infrastructure can work together to extend organizational control out to external resources, bringing the benefits of lower-cost compute resources to the enterprise without sacrificing the control and security demanded.

* F5 APM (Access Policy Manager), which provides the web application access control in this scenario as a part of EGW, supports only HTTP while EGW itself supports a much broader range of application protocols.