Welcome to Groups!
We’re happy to announce that JumpCloud’s “Groups” functionality has gone live for all new organizations signing up for the JumpCloud service. As will be explained below in more detail, customers and evaluators who had established accounts before April 11th, 2017 will be invited to migrate in the coming weeks.
Tags to Groups – Some History
In JumpCloud’s earliest incarnations, we designed the product’s grouping mechanism, an object class referred to as “Tags”, to perform in a very specific way: to provide many users access to many systems. This use case was primarily designed and suited for a technical audience (e.g. DevOps teams), where a team of admins could access a set of servers to do their jobs. In other words, a user-to-system matrix association.
As we evolved JumpCloud in late 2014 to focus more purely on directory services, we extended the concept of our “Tag” object to do more and behave more like a traditional role based access group. For example, the users within a Tag could act as an LDAP groupOfNames or POSIX group for resources integrated to JumpCloud. Users in a Tag could also act as group-based access control for our SSO apps or RADIUS servers. Further, an admin operating JumpCloud would still need to visit several decentralized user interfaces to completely on or off-board an employee from JumpCloud and subsequently their resources. It became clear that “Tags” had done its service and needed to be evolved.
On to Groups!
Groups are exactly what their label implies: Groups of objects. We implemented this system to simplify the experience for admins and properly support a new association model (e.g. a graph model) between objects – something we feel will give limitless scalability to our directory architecture and model over time.
Let’s go through some basics:
–What are Groups?
Groups are collections of JumpCloud objects (e.g. a collection of users or systems). These group collections are then associated with other objects to form relationships between them.
The primary function of these relationships enables admins to grant or remove access to or from objects (e.g. a user associated with various resources) in a very efficient way. A very simple visual of this is as follows:
–What kind of Groups does JumpCloud support?
- Groups of Users – These are logical collections of users (employees). For example: “Sales Team” or “DevOps Team”
- Groups Of Systems – These are logical collections of systems. For example: “Production Servers” or “Boulder Office Workstations”
–How do Groups Work?
NOTE: You can review our Getting Started with Groups here on our Knowledgebase.
Groups of Users principally drive the employee onboarding process. This Group object, containing specific types of employees (e.g. sales, marketing, engineering), is connected to other resources that class of employee need access to:
- Groups of Systems (typically servers – as personal machines are bound directly to the user)
- SSO Applications
- RADIUS Servers
- Directories (G Suite, Office 365 and LDAP).
When a Group of Users is associated to those associated resources mentioned above, an admin simply adds a user to give them access to those things or removes the user to take away access.
Groups of Systems contain any number or type of machines (physical or virtual). This Group object is important for the following reasons:
- They can be bound to Groups of Users to replicate the power of what Tags did (many users associated with many systems)
- They can be leveraged for DevOps purposes, primarily via the API as is done now with Tags to auto-scale virtual infrastructure.
- They can be leveraged to execute commands against en masse.
–What kind of Groups does JumpCloud NOT support?
- Nested Groups or ‘Group Hierarchies’ are not supported – Creating a Group and then nesting a Group within it (e.g. “Sales Team” Group of Users containing another sub-group called “SDR Team” is not available initially. This will be implemented in the future.
Tags to Groups Migration
Many of you reading this have been customers of JumpCloud for some time and thus have been heavily leveraging Tags. Each organization will be invited to automatically migrate in the coming weeks. These organizations will generally be bifurcated into two groups:
-First wave: Those not using Active Directory Bridge
-Second wave: Those using Active Directory Bridge
Each organization will receive emails leading up to your migration wave describing various ways to prep for the conversion. Your administrative dashboard will then display a banner inviting you to convert:
A complete set of migration documentation will be provided in advance of your self-triggered migration explaining the underlying process. In short, here is a synopsis of these considerations which will be elaborated on in follow-up documentation:
- Tags will automatically convert into a unique Group of Users and a unique Group of Systems. Both will be associated to each other to ensure connectivity between users and their systems.
- Tags created and leveraged for SSO application access will convert into a Group of Users with the associated application bound to the Group.
- New “Implicit Deny” implementation – JumpCloud traditionally had a philosophy to implicitly allow access to a resource. For example, when a SAML connector was created and no Tag leveraged to restrict access, all users could have access to that application. This is now changed to ensure an admin either binds a user to a resource (or a resource such as an app to a specific Group of Users). This directly affects the following:
- SAML Connectors – All applications must be bound to a Group of Users to provide access to users.
- LDAP-as-a-Service – The LDAP on/off toggle has been removed and now Groups of Users can be elected to add those users to LDAP along with their membership to the group.
- RADIUS-as-a-Service – Similar to above, RADIUS servers must be bound to a Group of Users to gain access.
NOTE: You can review our Binding Users to Resources article here on our Knowledgebase.
With the move to Groups, we have taken the opportunity to introduce new API endpoints to operate and integrate with Groups functionality. This also includes a complete overhaul to our API documentation.
- Version 1.0 API Documentation (e.g. for orgs still using Tags) can be found here.
- Version 2.0 Documentation (e.g. for those migrating to or already using Groups) can be found here.
We hope you’re as excited as we are for Groups! Please be sure to contact our Customer Success team for any insight or assistance planning your migration from Tags to Groups!