More users and companies are running software applications in the cloud than ever before. When even the US Federal government is looking to get into the cloud, it's a clear indication that it has reached wide acceptance. Similarly, Identity as a Service (IDaaS) has been around for years, but how often do admins considering this approach bother to take a deeper dive into the issue of directory access?
Most companies have a local Active Directory, but how would a cloud-based service be able to securely leverage those well-known, centralized names and passwords? This article discusses 4 possible ways cloud based services can access a local active directory.
Site-to-site VPN between the cloud server and the customer's LAN
If the IDaaS is single-tenant, then one seemingly straightforward option is a Site-to-site VPN between the cloud server and the customer's LAN. The networking teams on the customer and IDaaS sides can work together to establish an IPSec tunnel between two specific endpoints and restrict access to one or more domain controllers and only allow a specific port (e.g. 636 for secure/encrypted LDAP). This approach may grant real-time access to the customer's directory, but VPN traffic in a cloud provider incurs extra cost, setting it up takes technical know-how on both the customer and provider sides and any hiccups at the network level will cause outages, however brief, if the service depends on real-time access.
Besides these drawbacks, please also note that this is not typically a realistic option for multi-tenant providers. In this environment, multiple customers share the same server, so extra precautions would need to be taken to silo the virtual network for a specific customer – steps that are non-trivial as well as counter to the cost-savings of multi-tenancy.
Open a port on the customer’s firewall
A more cringe-worthy approach is to open a port on the customer's firewall, allowing the cloud service direct access to one or more domain controllers. This is not a best practice from a network security standpoint, but that has not stopped some products from implementing their LDAP-based authentication utilizing this grim option. Yes, firewall rules can help limit risk by whitelisting this access to only specific IP addresses belonging to the cloud provider. A Read Only domain controller can also be employed, but that only makes this feel slightly "less dirty." Identity federation, as a whole, has thankfully helped usher this approach towards extinction and it is really only mentioned here for completeness.
The subtle reference in the prior paragraph notwithstanding, identity federation is another option that shows some real merit. Most large cloud providers utilize this as one of the primary methods of authenticating against their own directories. Google may have a proprietary Directory API, but it cannot be used to authenticate a user. Other providers like Microsoft have APIs based on open standards such as OAuth that they've packaged as stand-alone libraries to reduce their complexity.
So why not apply this same approach to customer sites?
Well, it should not come as shock that most companies do not have the resources or infrastructure of these behemoths. Another downside is that the IDaaS provider is completely out of the loop when the user authenticates against the cloud. It may eventually receive indication that the user authenticated successfully, but identity federation does not give the IDaaS provider any indication of the user's actual password. While many cite this separation as a virtue of identity federation (and they're not wrong), but keep in mind that this precludes other scenarios such as password synchronization to legacy systems or applications. Please note that utilizing this cloud-based directory approach also locks you in to a specific vendor -- which can limit your options later.
The final method for discussion is some form of directory synchronization. When done correctly, this can provide numerous advantages. Many open source queuing products, such as Apache Kafka, provide enterprise-quality performance and scalability. Queue-based systems process billions of messages per day, but you rarely hear about them because they're stable and often operate solely in the background.
There are many high-quality comparisons of these systems and they can make for an interesting, albeit lengthy read. These products have built-in support for multiple types of acknowledgements, TLS-based encryption and all types of delivery methodologies. Messaging-based implementations can define their own message types to transfer data in one or both directions and, critically, no additional ports need to be opened on the customer's firewall. A single outbound connection from the customer LAN to the cloud is enough to allow TCP queue traffic to travel in both directions.
Hopefully this served as a gentle introduction for how cloud-based systems can securely leverage your central Active Directory. There are options in this arena that don't involve creating a VPN, replicating an entire directory, opening firewall ports, or pinning yourself and going all-in with a single cloud vendor.
We've seen an increasing number of our customers show interest in cloud-based services and deployments and are ready to discuss the benefits and options with you as well. Please visit our site for more information, or email us to set up a time to talk directly.