Cloud-to-Ground, The Last Frontier?

Whilst Cloud-to-Cloud service integration is relatively straight forward, Cloud service to on premise integration presents more challenges for the enterprise architect

By Ed King, VP Product Marketing – Axway (following acquisition of Vordel)

Cloud-to-Cloud security integration is now a fairly well solved problem. Cloud based services allow extremely limited access to backend infrastructure and data store. Typically integrations are done via highly constrained REST APIs and occasionally SOAP Web Services. Thus, security integration between Cloud based services has largely been focused on access control and API security. Cloud-to-Ground security integration is the last frontier that must be concurred before Cloud adoption can hit its full stride. Cloud-to-Ground security integration is a much more difficult and complex technical problem compared to Cloud-to-Cloud integration. In this blog post we will discuss three key challenges in linking security from Cloud-to-Ground and how to leverage new and existing security technologies to make it work.

It’s 10pm, do you know where you users are?

The first common Cloud-to-Ground security integration problem for an enterprise to solve is to enable an on-premise user already signed-on locally to have single-sign on (SSO) access to Cloud based services. This is a straightforward problem to solve because most Cloud based services today support SAML and increasingly OAuth 2.0 based federated SSO. The Cloud service providers invariably offer well-documented APIs for SSO integration based on these standards. Unfortunately, the preparedness on the on-premise side is not as good. Traditional identity management platforms support at least SAML, but often as a bolt-on, extra-cost federation module. OAuth 2.0 support is still more miss than hit.

Instead of just adding a bolt-on federation module, consider deploying a stand-alone Security Token Service (STS) instead. STS solutions provide token mediation for standard and proprietary token types and broker trust between on-premise and Cloud identity platforms. The STS approach provides you with the flexibility you’ll need as you expand your Cloud and mobile usage, as well as safeguard you against future changes in federation standards. There are a number of standalone STS products such as Ping Identity, or you can find it as a feature of most API server and gateway products from companies such as Axway/Vordel and Oracle.

The challenge with Ground-to-Cloud SSO is that today’s employees are no longer bound to the office. Even if we aren’t all road warriors or work in a field job, most of us take some work home or work from home part-time. The instinctive IT response is to ask remote workers to use VPN, then the normal SSO flow would work perfectly. VPN is a cumbersome but viable solution for home working scenarios, but is technically challenging for mobile workers. VPN while on mobile networks, hotel and public WiFi, or enterprise guest networks can be frustrating to downright impossible. To solve this problem you need to move the initial login point into the Cloud or in the DMZ, which we will discuss next.

Knock, knock, who’s there? The outside-in use cases.

Network perimeter security does a good job of obscuring on-premise resources to the outside and blocking direct access from external endpoints. This creates a technical challenge for integrating Cloud based services with on-premise systems. Let’s look at two use cases:

(1) SSO from Cloud based identity platforms, and

(2) Data and functional integration between on-premise with Cloud based services.

Above I proposed moving the initial login point from behind the firewall to the Cloud or the DMZ. A number of Cloud based SSO solutions now exist to do just that. These Cloud-to-Cloud SSO solutions offer users a comprehensive catalog of prebuilt integrations to popular Cloud based services such as Salesforce, Workday, and Google. Users can log into services such as Okta, Symplified, and VMware, then SSO to a catalog of Cloud based services without having to tangle with the company VPN. However, SSO is a misnomer because it is really Dual Sign-On: Cloud and on-premise. On-premise assets are still protected by on-premise identity management systems such as Oracle Access Manager and CA SiteMinder and are inaccessible to the Cloud based SSO platforms.

To achieve true SSO across Cloud and on-premise, a user who is authenticated by the Cloud/DMZ SSO platform must be able to SSO to on-premise systems and be able to see Cloud and on-premise applications in a single integrated application catalog. This can be done by introducing a trusted gateway into the DMZ. The gateway is trusted by the on-premise SSO platform and can take a SAML token from the Cloud SSO platform in exchange for the proprietary token used by the on-premise system, such as Oracle’s Obsso cookie or CA’s Siteminder session token. The gateway can also perform dynamic URL mapping so the internal applications can be accessed without VPN. Here is a video showing an example of a user logged into VMware’s Horizon Application Manager in the Cloud then SSO to an on-premise application protected by Oracle Access Manager.

The second case is the integration of a Cloud based application to an on-premise system. For example, Salesforce.com pushing new customer records into an on-premise Siebel CRM. Instead of poking a hole in the firewall to allow direct access, the better way to achieve a secured integration is to make on-premise systems look like a Cloud endpoint, thus leveraging the web oriented architecture (WOA) for integration. This means putting up a REST API façade that can be exposed externally. This API based integration approach makes integration easier and more secure. API security can be easily achieved using off-the-shelf API Server, API Gateway, and API Management products. These products not only control access to the APIs, but can also monitor the flow of date from on-premise systems to the Cloud and enforce data redaction policies for security and privacy purposes.

Are you an identity pusher? Try to be an identity provider.

Whether it is SaaS, PaaS, or applications you stand up inside IaaS, all these applications still have access control built-in to ensure users can only see and do what their job roles permit. Where do these applications go for identity data to make authorization decisions? Traditional software architecture uses either an embedded user repository, or can point to an LDAP Directory. Either way, an identity needs to be provisioned into the application or local LDAP. In the case of Cloud, this means pushing identity records from on-premise identity platforms to Cloud based services. This is the traditional provisioning nightmare that the enterprise has not been able to solve despite throwing millions of dollars at it. Except the problem just become more complicated by adding external Cloud based resources. Emerging standards like SCIM and more modern provisioning solutions such as Identropy attempt to solve the Cloud provisioning problem.

The better solution is to have applications, especially Cloud based services, support the claims based identity model, such as Microsoft SharePoint 2010. The claims based model enables the application to reply on an external identity provider to supply user authentication and role information. By delegating to an external identity provider, the application can control access without retaining the identity locally. Here is a video showing how to set up SharePoint 2010 for claims based access control.

Two major challenges have to be overcome for this model to scale.

1) More Cloud based applications have to support the claim based identity model.

2) The enterprise must develop its own identity provider service. This is best achieved by exposing the identity provider service as a REST API.

If you are interested in learning more about this topic, you can view this webinar I presented with Eve Maler of Forrester Research: The IAM-As-An-API Era: You Must Become A Cloud Identity Services Provider

Summary

Cloud-to-Ground security integration is still a challenge and most solutions are not very elegant, yet. However, enough technologies already exist such as API Servers, Cloud Gateways, Cloud SSO and Security Token Service that can build on your existing security infrastructure to provide good solutions today. New emerging technologies and standards such as OpenID Connect, SCMI, UMA, HTML5 WebSocket all hold promises to make these solutions increasing better, more secured, and more scalable.

Ed King VP Product Marketing Emerging Technologies Axway (recently acquired Vordel)

Ed has responsibility for Product Marketing of emerging technologies around Cloud and Mobile at Axway, following their recent acquisition of Vordel. At Vordel, he was VP Product Marketing for the API Server product that defined the Enterprise API Delivery Platform. Before that he was VP of Product Management at Qualys, where he directed the company’s transition to its next generation product platform. As VP of Marketing at Agiliance, Ed revamped both product strategy and marketing programs to help the company double its revenue in his first year of tenure. Ed has also held senior executive roles in Product Management and Marketing at Qualys, Agiliance, Oracle, Jamcracker, Softchain and Thor Technologies. He holds an engineering degree from the Massachusetts Institute of Technology and a MBA from the University of California, Berkeley.