This year, Apple’s Worldwide Developers Conference brought many innovative goodies to the table. Amongst them, the declarative device management model seems like one of the super goodies which could create a lasting impact on the device management industry. Before we familiarise ourselves with the topic at hand, here’s a little backstory.
Apple has always prioritized providing the best device management features and functionalities to organizations relying on their tools. Apple’s heavily used MDM protocol is what makes it all happen. This protocol which is already provided within iOS, macOS and tvOS devices, is updated every year.
MDM Protocol
Image source: Apple WWDC 2021
The current MDM protocol is described as ‘imperative and reactive.’ Any management process involves multiple round trips between the device and the server. This raises some serious performance challenges if we increase the number of devices. To make the MDM protocol more scalable, Apple has introduced a new paradigm on the existing protocol called declarative device management.
What is declarative device management?
Declarative device management makes the whole device management process more autonomous and proactive, which lightens the load on the server. How does that work? An autonomous device can make management decisions based on its status changes without relying on the server. The proactive bit refers to the device updating the server on significant status changes without having to ask. Declarations, status channels and extensibility are the three components of the declarative management model.
Declarations
A declaration is pretty much what you call the policies pushed onto a device by an organization. They can also act like dictionaries containing keys and values. These policies can be pushed on multiple or single devices. There are four types of declarations; Configurations, assets, activations and management.
The polices which are on the device are represented by configurations such as accounts, settings and restrictions.
Assets represent the references to support data that are required by the configurations. Assets can also represent the information specific to a user. Multiple configurations can rely upon a single asset that eliminates unnecessary copies of the same asset. If we were to update an asset, all the configurations linked to that asset would be automatically updated.
Configurations will be applied automatically in sets that are represented by activations. However, all the configurations have to be valid for the activation to succeed. If one configuration or a reference asset is invalid, the activation fails.
Management declarations are a great way to convey static information such as organization details or the capabilities to the device.
Declarations Structure
Structure of an activation declaration
Image source: Apple WWDC 2021
Declarations are arranged as JSON objects rather than plists when sent over the network. A declaration is structured with three sections.
Standard keys
Standard keys provide information on a declaration and uniquely marks them for easy identification and synchronization by the server.
Type: The type can be used to identify the type of policy represented by the declaration.
Identifier: Identifier is a unique value that represents the current declaration. All declarations have their Identifier key, which the device uses while syncing declarations with the server. This is usually a UUID represented as a string.
ServerToken: Server token is also a unique value allotted to a declaration, but this value changes with each revision.
Payload
The payload contains the content, which varies based on the type of declaration. For a configuration, it carries the data of the policy. The payload for an asset contains ancillary data for a configuration. Activation declarations will input the identifier keys of the referenced configurations in the payload. And in management declaration, static information is conveyed through the payload.
Predicate
Activation can also include a predicate that acts as a condition. If the predicate is true, then the configurations under an activation is processed.
Status channel
The device state need not be the same as the declared state. Let’s take the case of a password policy as an example. The new password criteria declared, is not fulfilled by the device until the user heeds to the declaration. Only after user intervention will the device state change. The status channel was established to keep track of this status change. If the server were to get updates on every status change, it would be unnecessarily loaded. We can utilize subscription configurations to subscribe to specific status updates and avoid crowding the server with unnecessary information. The updated status of declarations is always reported to the server regardless of subscription.
Structure of a subscription declaration
Image source: Apple WWDC 2021
The above subscription declaration is used to subscribe to the device operating system version, type and model. First, the initial status of the three status items would be sent to the server. Only the status of items that underwent an update will be sent in the consecutive reports. Let’s say that the status of the OS version changed; then, only the updated OS version will be included in the report.
Extensibility
It is vital to maintain the compatibility of various versions of the MDM with MDM protocol. The capabilities of both the server and the client are advertised to each other to achieve this. Each would know when it can start utilizing the capabilities of the other without relying on any software or hardware updates.
The shared details include supported payloads, protocol updates and server capabilities. The client capability changes are sent to the server as status updates to take advantage of them immediately.
Integration with MDM
Declarative device management is already integrated with the MDM protocol so that it can be used by MDM vendors right now! Since the protocol did not undergo a complete change, it can be integrated into an MDM solution without disrupting its server infrastructure. The declarations in the status channel are already present in the policies and MDM commands. The integration will not affect the current behavior of the MDM solution.
We can adopt the various features of declarative management at our own pace. For example, it is possible to integrate only the status channel from this model to support subscription declarations. Disenrolling the device will remove the declarative management features.
A declarative management command can be used to enable this model. Once enabled, it is not possible to turn it off. We can effectively disable declarative management by removing all the declarations. A new type of Check-in request is available, which the device uses for declaration synchronization and sending status reports.
After using a Check-in request, the server sends two types of responses; A manifest, which contains information of the standard keys of all the declarations and a single declaration.
Referencing a policy in a configuration
Image source: Apple WWDC 2021
You can install a profile to a device by using a profile URL within the configuration. This features ensures that we can use the entire set of profiles in an MDM to use declarative management properly.
The last say
Declarative device management could be a new milestone in the device management industry. One of its many key takeaways is its non-disruptive nature which is quite convenient. Everyone would appreciate an integration that could be done at any pace. With the freedom to adopt the only features which we need, it would be easy to facilitate a seamless transition to declarative device management. It’ll take a while for any potential faults or drawbacks of this model to come up if any exist that is. Personally, I feel like declarative device management has the potential to bring about a change in the overall concept of device management. In the end, we can only wait and see what it has in store for us in the not-so-distant future.
Share your thoughts