Sticky Sessions for Jamf Cloud

Learn how to use persistent sessions when interacting with Jamf Cloud hosted APIs

Overview

Jamf Cloud hosted environments run on infrastructure that is clustered to ensure high availability and performance. This means that interactions with Jamf Pro may be routed to various web applications, which do not directly communicate with each other. Most browsers use cookies to cache a session with the web application that they initially interact with, ensuring that future interactions from that same browser occur with the same web application.

Most tools that interact with APIs do not natively have this type of functionality built-in. Therefore, it's common to see requests to the API handled by different web applications. In workflows where a sequential series of operations must occur or where subsequent calls are dependent upon earlier calls, this can often be problematic due to the cluster refresh, which occurs every minute.

This article describes how you can use cookies to identify the web application within a cluster that you're interacting with, and force future interactions to occur with that same web application.

❗️

Warning

For API workflows that do not require all interactions to occur with a single web application, Jamf recommends not using the workflow described below. Directing all traffic to a single web application may negatively impact performance, especially for large automated processes.

When to use Sticky Sessions

Common workflows that may require the use of cookies to interact with a given web application include almost all API calls that create new resources, assuming subsequent interaction with that resource is required. Frequent interactions with endpoints that require the use of Optimistic Locking may also benefit from the use of sticky sessions.

To better understand when the use of sticky sessions are necessary, we'll examine an example scenario. Imagine a scenario where we would like to create a device group and add that group to the scope of an existing deployable resource. After creating the device group, there is up to a 60 second delay before all other web applications become aware of the newly created resource. An immediate request to update the deployable resource with the new device group could be routed to a web application other than the original one that created the smart group, resulting in a error response. These are the types of issues that can be prevented by using cookies to establish a sticky session.

How To Create Sticky Sessions via cURL

  1. Request header information from any page or API resource. This can be done using the -v flag for verbose responses or the --head flag which will return only the header information.
    i. When interacting with the Jamf Pro API, this can easily be included with your initial request for an authentication token similar to the following:
    curl -v --header 'authorization: Bearer AccessToken' https://company.jamfcloud.com/api/v1/auth/tokens -X POST
    ii. When using the Classic API, if no initial requests are part of your workflow, a request to any page, including the login page, which returns header information, will provide the required information.
    curl --head https://company.jamfcloud.com
    iii. A sample response may look something like the following:
curl --head https://company.jamfcloud.com
HTTP/1.1 401
Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
Content-Length: 8921
Content-Type: text/html;charset=utf-8
Date: Wed, 08 Apr 2020 18:39:42 GMT
Server: Jamf Cloud Node
Set-Cookie: JSESSIONID=C29C9EC374DD304FADE008C160791315; Path=/; Secure; HttpOnly
Set-Cookie: APBALANCEID=aws.use1-std-ellison4-tc-1; path=/;HttpOnly;Secure;
Strict-Transport-Security: max-age=31536000; includeSubdomains;
X-FRAME-OPTIONS: SAMEORIGIN
Connection: keep-alive
  1. Parse the response for the cookies as well as their values. The cookie name used in this workflow may vary based on hosting region and infrastructure. Most commonly this will be APBALANCEID or jpro-ingress.
  2. Include this cookie and its value in all subsequent requests in your workflow that require interaction with a single web application.
    curl -b "APBALANCEID=aws.use1-std-ellison4-tc-1" https://company.jamfcloud.com/JSSResource/endpoint

Summary

The use of cURL is provided only as an example to demonstrate the premise of using cookies while interacting with Jamf APIs. Many other tools and languages have libraries or features for managing and interacting with cookies, be sure to reference the documentation for your preferred tool of choice when interacting with Jamf Cloud hosted APIs.