An early cloud adopter looks to streamline
Four years ago, Citrix products and services relied on deployments on premises and a packaged license model, but they knew that the cloud was the future. To evolve their business, Citrix started to expand into delivering its technology as software as a service (SaaS). For example, they migrated ShareFile to a cloud platform, creating a secure enterprise file sync and sharing (EFSS) SaaS platform. Other SaaS offerings include Podio, a team workflow solution, and Citrix Cloud, a management and integration platform.
The move to a cloud platform was a huge success for these services, giving customers greater elasticity and scale among other benefits. However, the products lacked a unified authentication mechanism. Each SaaS offering used its own authentication mechanism, identity policies, and database. Some included two-factor authentication, some didn't. Decades of product-centric business had created development silos, and customers felt the effect whenever they accessed Citrix services, many of which required different logon credentials.
Figure 1. Citrix wanted a unified authentication mechanism for its many SaaS offerings.
Single sign-on across Citrix Cloud
With single sign-on as the goal, the Citrix Identity Platform (CIP) team got started. CIP was designed to support Citrix Cloud, a mission-critical service that handles more than 10 million Citrix users worldwide. The solution needed to unify and simplify the customer experience across the spectrum of Citrix SaaS offerings.
The CIP engineers also wanted a solution that was quick to update and deploy. Citrix Cloud is highly complex, and updates require many services to be built and deployed together in a two week release cycle. From the outset, the CIP team knew that they wanted to be able to update CIP quickly, so they needed support for a true CI/CD pipeline. That ruled out monolithic architectures.
Since CIP was a relatively small project for Citrix, it seemed like the perfect environment for a simpler, microservices-based approach. A smaller set of identity services could be deployed separately from everything else in Citrix Cloud, and each service could be built, deployed, and interacted with separately.
The plan was to build CIP as a scalable, resilient platform-as-a-service (PaaS) offering with integrated support for single sign-on services for use by other Citrix Cloud tenants. A PaaS approach would free the team from the responsibility for managing the hardware and the operating system, which is handled by the service provider (Microsoft in this case). The Citrix team wanted to focus on the authentication issue, not cloud administration.
Service Fabric and the case for density
A microservices architecture helped the Citrix team solve another issue: density. When the CIP team began investigating PaaS hosting environments for their identity services, they first considered Azure Cloud Services, which was already in use at Citrix. Azure Cloud Services provides cost-effective virtual machines and a complete, configured environment for deploying applications. Within that environment, developers configure the number of instances of their services they want to run, and the platform scales up and down accordingly.
The model worked well for their tiered applications, but microservices did not fit the Cloud Services model as well. The CIP team wanted the flexibility to pack more microservices on fewer nodes. Densely packed services would provide the scale they needed to support millions of sign-ons without paying to scale out on so many individual virtual machines. If services are tightly bound to the host in a 1:1 relationship, much of the flexibility of a microservices-based architecture is lost.
Although Azure Cloud Services provided part of the solution, Service Fabric turned out to provide the complete environment that Citrix was looking for. Service Fabric is designed with distributed architectures in mind, and enabled Citrix to create 100 services yet run them on only 10 nodes. The CIP team could run a cluster of any size they liked and keep costs in check.
Citrix engineers were in San Francisco in 2016 for the //Build Developer Conference, where Microsoft announced that Service Fabric was generally available as a service in Azure. Service Fabric had been in production use at Microsoft for five years, but now it was publicly available as a mature microservices application platform. With support for lifecycle management, stateless and stateful services, density, and performance at scale, Service Fabric had everything the CIP engineers were looking for.
Citrix immediately started using Service Fabric for CIP and began working it into with their existing testing and development processes, eventually building their integration systems around it.
CIP architecture based on Service Fabric
CIP is an implementation of OpenID Connect, a simple identity layer built on top of the OAuth 2.0 protocol. It authenticates users in different ways, generates access tokens for use in various systems, and provides a single-sign-on solution for Citrix products.
Figure 2. Leveraging Service Fabric to build the Citrix Identity Platform (CIP) on Azure.
An earlier implementation of the architecture included two virtual machine scale sets: one for the front end and one for the back end. The team thought they would need the additional scale to support the load. However, they discovered it was simpler—and just as scalable—to use only one scale set. The simpler deployment was easier to manage, and better still, running the instances of their microservices in a single scale set enables the team to deploy identical environments for development, testing, integration, and staging.
After the move to a single scale set, the team kept a close watch on performance but didn’t see any negative effects. They can quickly scale up the entire platform by adding virtual machines and get as much performance as they want. Service Fabric balances the load across nodes perfectly—a huge win.
CIP is designed to handle identity management and authorization through integration with Azure Active Directory. CIP uses microservices to accept credentials, create principals, and return signed tokens. In addition, it can federate authentication to other directory services.
The microservices were designed to encourage internal business units at Citrix to create their own plug-ins and enable federated authorization to their products. The product teams support various types of authorization, so flexibility was important, as was isolation. The Service Fabric clusters are isolated by a virtual network that is separate from other services. The product teams can experiment with CIP and write microservices that run in an isolated service without affecting CIP. Service Fabric makes implementation of these product-specific services a straightforward, controlled process for the CIP engineers.