Cloud IAM Protocols + Architecture

Written by Greg Keller on July 2, 2017

Share This Article

We’ve recently kicked off a new series of whiteboard videos in which we dive into the various topics in the cloud IAM space (sometimes referred to as CIAM or identity and access management), especially as they relate to JumpCloud’s Directory-as-a-Service®.

You can watch the first in our whiteboard series below, which illustrates the protocols that JumpCloud’s cloud identity management platform uses including SAML 2.0, RADIUS, OAuth, and LDAP to ensure that users can connect with the IT resources they need. We also talk through the progressive cloud-based architecture that underpins JumpCloud’s cloud directory services.

In this post, we’ll walk you through our cloud directory architecture and the protocols that are addressed in the video. By understanding the architecture of JumpCloud’s cloud identity provider and the protocols implemented, we hope to give you a better understanding of how our model of cloud IAM could work with your unique infrastructure.

Our Core: Directory Service

At the epicenter of JumpCloud’s IDaaS platform is our core directory service. It’s important to note that our directory service and platform at large is not an instantiation or a hosted version of OpenLDAP or Active Directory® up in the cloud; it is an alternative to or replacement for AD and LDAP. While JumpCloud’s cloud directory is built in the spirit of a traditional directory service like LDAP or AD, it is our own proprietary architecture delivered in a SaaS-based model. However many of the same identity management concepts still apply.

At the center of our virtual directory service are two primary objects – the user object and group object – critical for the management and appropriate authentication, authorization, and management of your employees identities:

The User Object

The ‘user account’ is the key to an individual getting authenticated and authorized to access an IT resource. The user object securely stores all of the necessary information for authentication and other operations including our employee’s legal name, username, email and other various attributes, and of course credentials. With JumpCloud, the storage of our information is done through very deeply encrypted, hashed, and salted versions of that information. We never store clear text passwords in any capacity within our infrastructure. For more information on JumpCloud’s security process see this page.

The Group Object

The second object type is a group object. Groups are exactly what the name implies: they are collections of objects, typically a collection of users like a ‘sales group’ or a group of systems. Groups are the object that other sources defer to for authorization. Groups contain user members and within the JumpCloud admin console you can add users in or take them away with just a few clicks. This doesn’t just superficially add or remove users from a container. Since those containers (the group objects) can be granted access to various resources, by adding a user to a group you are granting that user access to all the resources that group needs.

So now with Users and Groups defined as the basis for authentication and authorization against resources, how, specifically are those resources bound to JumpCloud so they can interact with the user identities?

That is where the protocol interfaces come into play.

CIAM Multi-protocol Support

JumpCloud has benefited from the fact that it is been built from the ground up to work with the myriad protocols in use today. That makes our cloud directory extremely versatile and adaptable and is where we spent considerable time early on in the development of the modern IDaaS platform. We knew that IT resources come in many forms (e.g. systems, cloud servers, on-prem and web applications, internal and cloud file storage, and network infrastructure) and a virtual identity provider had to provide the widest array of mechanisms a web based or on-prem resource could attach to.

Let’s walk through the major protocols in use within the CIAM platform  to see the various resources that can connect to our directory service and, thus in turn, what an employee can connect with.

Let’s start at the foundation.

The JumpCloud System Agent

DaaS Diagram

We are first going to talk about our system agent.  Admittedly, this is not a standard protocol, and is deeply rooted in our proprietary mechanism to bind a machine virtually to our cloud-based directory – all the while keeping it secure and not dependant on the internet for operability.  

The agent is platform agnostic, which means it can be deployed to Windows, Mac and Linux systems. It can also be deployed regardless of whether you’re dealing with physical systems like your employee’s laptop, or virtual systems, like a cluster of Linux systems up in the AWS or Google Cloud.

The JumpCloud system agent does, in effect, four key things:

  1. User account management. This allows admins to create a new user account on any machine that has the JumpCloud system agent installed. You can also manage pre-existing user accounts remotely, without being ‘at the machine’.
  2. Event logging. The JumpCloud agent will collect a variety of event-based data, from who’s logging into what machines, when, to indicating what IP address the requests are coming from. This feature is very important for security and compliance reasons especially in the case of cloud-based servers.
  3. Command execution. An administrator can build scripts and deploy them against individual endpoints or groups of systems all from the JumpCloud admin console or API. The agent receives these commands, (PowerShell, Bash, Python, etc.) and will execute the operation, returning results back to JumpCloud.
  4. Multi-factor authentication. JumpCloud’s agent enables MFA/2FA on Mac and Linux endpoints. So, in addition to the JumpCloud password, you can require your users to input a TOTP token in order to get into their machines. This can be done with their mobile phones with well known applications like YubiKey, Duo for Mobile or Google Authenticator.

So now that it’s understood how a Windows, Mac or Linux system is bound to the JumpCloud cloud directory service, what about other resources like applications or networks? This is where many of the protocols you’ve likely heard of, or integrated with previously, will come into play.

SAML 2.0

SAML with JumpCloud

JumpCloud supports the SAML 2.0 protocol in order to connect to a wide variety of web-based / SaaS applications and services. In the SAML model, JumpCloud is the “IdP” or Identity Provider. JumpCloud’s directory service is the ‘source of identity.’ The product supports a large library of apps, typically business productivity apps your company subscribes to. These could be apps ranging from BlueJeans to Amazon AWS/IAM, to Slack, GitHub, Atlassian, Salesforce, and hundreds of others. We offer about 150 web-based application connectors (and growing quickly) that utilize the SAML protocol. For those not specifically listed in our library, we have a generic SAML adapter to build out custom configurations to apps and services that support the SAML 2.0 protocol. You can also feel free to request any integrations as well.

Referring to the Group object above, JumpCloud can restrict access to your apps by associating a SAML app with specific user groups. Therefore, whenever you add a user to that group, they will get access to the SAML connector, and thus access to the web app. In reverse, when the user is removed from the group, they are denied access to the app. This is the power and simplicity of group-based assignments to resources.

See our full list of SAML connectors here or search for support tutorials on individual SSO connectors on our Knowledge Base.  


Applications come in many delivery methods (e.g. SaaS or on-premise), and further provide various ways to control access. SAML is one, as described above, but LDAP is even more ubiquitous having been a stalwart for nearly 30 years. LDAP is most commonly associated with being known as a ‘directory’ but it has enforced its own protocol which has been adopted en masse by software vendors for the last few decades to ensure their apps could be directly bound to a standard directory service. To be even more clear, LDAP is the protocol and the directory service solution is OpenLDAP.

Let’s discuss JumpCloud’s support for LDAP.

DaaS Diagram

JumpCloud’s cloud hosted directory offers a powerful feature – or rather a service. We call it “LDAP-as-a-Service”. Our hosted LDAP functionality, in effect, lets you bind applications that support the LDAP protocol with JumpCloud’s core directory services.

Another way of saying this is that our LDAP server endpoint is OpenLDAP. So the app or resource is natively interfacing with the LDAP protocol to OpenLDAP, and we manage the transmission of LDAP to our proprietary directory infrastructure beyond the LDAP server endpoint. Simply put, you focus on integrating the apps with standard LDAP configs, and we strip away all the overhead of managing OpenLDAP servers and connecting those applications to your users. All you have to do is bind your resources by configuring your applications to communicate with our LDAP servers as appropriate.

LDAP is also heavily used with on premises applications. These could range from on-premises file share servers like QNAP or Synology to self-hosted applications like Atlassian Jira and Confluence, Jenkins, OpenVPN, or similar. For DevOps teams, LDAP is still very deeply utilized by their resources such as MySQL and many others. User Groups can also restrict access to the resources bound to JumpCloud, just like the SAML-based apps listed previously. As you will see, this model will be a recurring theme throughout the JumpCloud console.

So now that we’ve discussed how application resources are bound to JumpCloud through SAML and LDAP, what about networks? That’s where RADIUS comes into play.



Similar to the LDAP-as-a-Service, our product also offers RADIUS-as-a-Service – often referred to as cloud RADIUS or virtual RADIUS. This is literally RADIUS in the cloud. Like LDAP, RADIUS is a well known and standardized protocol. It’s dated (e.g. the ‘D’ in RADIUS stands for dial-up!) but has been efficiently ported for use in modern resources. Just like LDAP, we take the hard part of managing RADIUS servers off your plate. It’s all cloud-based so you don’t need to wrangle with the protocol or FreeRADIUS servers. You simply use the platform.

Our service is based upon the widely adopted FreeRADIUS server. We therefore are responsible for the uptime, availability and security of the RADIUS infrastructure, delivering this from a network of RADIUS infrastructure around the globe.  

You can use RADIUS-as-a-Service for anything as long as it speaks to the open RADIUS protocol. Common integrations are with Aruba and Meraki WAPs that need to authenticate users joining the WiFi network. Another can be access to the VPN. For example, let’s say you want to stop the process of sharing SSIDs and passwords, and you want your employees to use their credentials to get access to the WiFi. This dramatically increases security as each person is individually joining the WiFi network. Inside of JumpCloud’s cloud RADIUS service, you can accomplish this by simply adding a user to your WiFi or RADIUS group. This will provide them access to the WiFi network, but will require them to use their core credentials that are also used for the cloud directory service.

Another common use related to RADIUS involves VPN clients, such as OpenVPN. There are a number of different VPN clients and – again – as long as they work with the RADIUS protocol, JumpCloud’s IDaaS platform can work with them. At the end of the day these too are providing network access.

Thus far you’ve seen how various authentication protocols and our system agent bind IT resources including systems, applications and networks to the core directory service. But there’s more. They include other well patterned approaches and protocols such as OAuth and RESTful APIs.

OAuth and APIs

JumpCloud’s use of OAuth is leveraged in a very specific manner for certain use cases. We leverage OAuth to securely connect to and deeply integrate with two very special tenants that are often referred to as directories themselves: G Suite (formerly Google Apps for Work) and Office 365, which is really Azure AD when you look under the hood.

G Suite

G Suite JumpCloud Integration

We utilize the OAuth protocol to bind to your G Suite account directly. OAuth enables us to use a modern, cloud-forward mechanism to bind directly to the Google cloud directory infrastructure. In doing, we have removed the need for integration utilities like Google Apps Directory Sync (also known as Google Cloud Directory Sync) – which is a self-hosted server that connects an instance of Google to a backing directory like LDAP or Active Directory. Instead, you can import all of your existing Google identities into JumpCloud. This centralizes your control of your organization’s identities, the provisioning, and the password management with Google and adding G Suite as a resource alongside the employee’s apps, systems and networks.

Office 365

The same directory-level integration that we laid out above for G Suite also applies identically for Office 365. However, since this is Microsoft software, a lot of folks ask us how we manage identities in Office 365 without Active Directory and/or Azure. The answer is with our API integration using OAuth. When you compare this model to Microsoft’s, the big difference is that ours is 100% cloud. There is no additional need for an Active Directory and self-hosted servers (e.g. DirSync, Azure AD Connect, ADFS services, and more). We stripped away all of that overhead keeping everything cloud-based: Direct cloud-to-cloud integration with zero need to manage anything on-premise. And don’t forget that we work with Mac, Linux, G Suite, AWS, and many other non-Microsoft solutions in a seamless manner.

The Final Word: Cloud IAM Protocols + Architecture

jumpcoud Directory-as-a-Service

Let’s step back and look at the totality of what JumpCloud is doing. The reason we focused on these protocols as the foundation for our cloud directory is so that we could ultimately provide as much breadth as possible to an organization when it comes to centralizing employee identity and binding as many resources as possible to those identities. For the user, we strive to make this process invisible. When a new user is onboarded, they are connected to the IT resources they need right away. Voila.

For the IT admin, our multi-protocol approach unifies the management of identities so that each user has a single set of credentials instantly mapped to the many things an employee needs. The same is true when it comes time to offboard an employee. An admin is able to extract a user from from access to a myriad of different resources across different protocols from one control panel. That is the power of JumpCloud.

Take the Next Step

If you would like to learn more about how you can leverage JumpCloud’s cloud IAM protocols and architecture, contact us directly. Alternatively, you can sign up for a free account with our Directory-as-a-Service platform and try it out for yourself. Your first 10 users are free forever.

Greg Keller

JumpCloud CTO, Greg Keller is a career product visionary and executive management leader. With over two decades of product management, product marketing, and operations experience ranging from startups to global organizations, Greg excels in successful go-to-market execution.

Continue Learning with our Newsletter