Meet declarative device management

♪ Bass music playing ♪ ♪ Melissa Nierle: I'm Melissa Nierle, a software engineer on the Enterprise and Education Technologies team.

At Apple, we're always working to create the best device management features and functionality to equip our enterprise partners and education organizations with the tools they need to connect their team members and students.

The backbone of all of these management features is the MDM protocol itself.

The protocol is a well-established, heavily used solution provided directly within iOS, macOS, and tvOS and has become a standard across mobile device management.

And while we add features to it each year, we also continually evaluate the protocol against our device management goals and evolve it to meet the dynamic needs of MDM solution developers, admins, and users.

Today, our MDM protocol can be described as an imperative and reactive protocol.

Each management workflow takes time and multiple round trips between the device and server.

Then any performance challenge is compounded when you manage a large number of devices across an organization.

This is an example of where we want to ensure our protocol is as performant and scalable as possible.

And to achieve optimal performance and scalability, we've reenvisioned the MDM protocol itself.

The future of device management is declarative management; a transformative update to the protocol which brings policy management to the device.

Declarative management allows the device to be autonomous and proactive, freeing up the server to be lightweight, reactive, and subscribe to updates without constant polling.

An autonomous device reacts to its own state changes and then applies management logic to itself without prompting from the server.

A proactive device has a status channel asynchronously reporting to the server when important state changes occur, avoiding the need for servers to poll devices.

Enabling devices to be both autonomous and proactive is the foundation of declarative management and allows for increased performance and scalability.

And the best part is, while it's a new paradigm, it's not a new protocol.

We've built this new declarative functionality right into our existing MDM protocol, starting with iOS devices.

We'll take a deep dive into the data model that powers the new declarative paradigm.

Then later, we'll talk about integration with MDM.

We'll go through a specific example and learn how to get yourself started.

Let's begin with the declarative data model.

There are three pillars to the declarative data model.

Declarations, which are payloads that the server defines and sends to devices; the status channel, which is a new channel of communication where the device proactively updates the server with new information about itself; and extensibility, so that, as Apple introduces new features to declarative management, your devices and servers handle it seamlessly.

Understanding these three pillars will prepare you to incorporate declarative management into your MDM solution.

Let's start with declarations.

Declarations represent the policy an organization wants to enforce on devices -- for example, accounts, settings, and restrictions.

Declarations can be created for policy that is common to all users, as well as policy that is specific to a single user or device.

Let's examine the makeup of declarations.

The data representation for declarations is similar to profiles, where a declaration is also a dictionary with a set of keys and standard types for values.

Declarations, however, are serialized as JSON objects when sent over the network, instead of plists.

All declarations have three required properties: Type, Identifier and ServerToken.

Type defines which policy a configuration represents.

The Identifier key has a value that uniquely identifies the declaration within the set of all declarations sent to the device.

Typically, this will be a UUID represented as a string.

The device uses this value when synchronizing declarations with the server.

The ServerToken key represents a unique revision of the declaration based on the Identifier key.

This key is also used when synchronizing declarations with the server.

The value is a string that must be different for each revision.

It could be a simple counter or a UUID string, as shown in the example.

The payload is a data-specific piece of the declaration, containing the keys and values pertinent to the declaration type.

Just like with profile payloads, some keys may be required, and others may be optional.

Values can be strings, numbers, booleans, arrays, or dictionaries and may be constrained in range -- like numbers one through ten -- or to a specific set of values like a string enumeration.

There are four types of declarations: configurations, assets, activations, and management.

The first type of declaration is a configuration.

Configurations represent the policies to be applied to the device -- for example, accounts, settings, and restrictions.

Configurations are similar to MDM's existing profile payloads.

Here is an example of a configuration declaration that applies restrictions to the device passcode.

The standard keys -- Type, Identifier, and ServerToken -- are present, as required for all declarations.

The value of the Type identifies this as a passcode configuration type of declaration.

The Payload key contains the passcode policy data for the configuration.

The next type of declaration is an asset.

Assets represent references to ancillary data needed by configurations.

This can be a shared item of large data or a personalized one.

For large data items, the asset declaration contains a URL that the device uses to fetch the actual asset data from a server.

This server could be your MDM server, or it could be a separate content delivery network server.

Serving assets from a separate content delivery network shifts the burden of supporting large network bandwidth to a service better suited for it.

Assets can also be used to represent data specific to a user, such as their name, email address, passwords for accounts, and certificates.

This takes the per-user customized data out of configurations and moves it into smaller, dedicated asset-type declarations.

Assets have a one-to-many relationship with configurations.

For example, one credential asset can be referenced by several account configurations, avoiding the need to replicate the same user information in each account configuration.

Then, if the user credential needs to be updated, only that asset needs to be updated.

All the configurations referencing that asset remain unchanged, and the device updates the policy accordingly.

The ability to do incremental updates like this, for many configurations at a time, will improve the overall responsiveness of the device management system.

Let's examine the makeup of an asset declaration.

Here is an example of an asset declaration that defines a user identity -- essentially the contact information for a user.

The three required standard keys are present, and the value of Type defines this as a user identity asset declaration.

The Payload key contains the user identity properties of this asset.

The next type of declaration is an activation.

Activations represent sets of configurations that the device will atomically apply.

This means all configurations in the set, along with any referenced assets, must be valid in order for all of them to be applied.

If any are invalid, the activation will fail to apply the associated policy.

Here is an example of a simple activation that contains two configurations.

The three required declaration keys are present, and the payload contains the set of configurations to be atomically applied by the activation.

Configurations are referenced by their identifier key.

There is a many-to-many relationship between activations and configurations.

Activations can refer to multiple configurations, and a configuration can have multiple activations reference it.

This many-to-many relationship allows for complex business logic to be handled autonomously by the device.

Activations can include a predicate that determines when the activation state is active or inactive on a device.

The device will only process the configurations referenced by an activation if the predicate evaluates to true.

As an example, a predicate can declare that the particular activation is only active on a specific device type, such as an iPad.

Another example is wanting a set of policies to apply only to a particular version of the OS.

This allows the server to send all the declarations for any device states and lets the device itself determine which ones to apply, making the device even more autonomous.

As the device state changes, the activation predicates are reevaluated without intervention from the server.

Policy associated with the new device state will be applied and any outdated policy removed.

The device here becomes increasingly proactive.

In the absence of a predicate, the device will always process the configurations referenced by the activation.

Here we have the activation example from before, but now there's a predicate present, indicating that this activation should only have its policy applied when the device is an iPad.

The last type of declaration is a management declaration.

Management declarations are used to convey overall management state to the device.

This includes a declaration describing details about the organization as well as a declaration that describes the capabilities of the server.

These declarations are helpful for conveying static information to the device.

And those are the four types of declarations for applying organization policy to your devices.

The second pillar of the new declarative management data model is the status channel.

Given the way that declarations work, the declared state of the device may not match the actual state of the device at any point in time.

For instance, any declaration that requires user interaction will not apply until that action is taken.

A good example of this is a passcode policy, where the user has to take action to create a new policy-compliant passcode for the device.

To add visibility into this device state transition, we've created the status channel.

Updates of the device state are sent in a status report to the server.

The server can subscribe to specific status items, so it only receives updates for the changes it cares about.

Status items are identified by key-paths, which consist of period-separated string tokens.

Status items can be used as expressions in activation predicates, as shown in the earlier activation predicate example.

The server subscribes to specific status items using status subscription configurations.

Upon receiving this configuration, the device will send an initial status report for the subscribed status items, and then send a report if a subscribed item changes.

The status reports are incremental, so only the changed items are reported.

The status of declarations -- whether they are applied or not -- is always reported to the server when changed, without the need for the server to subscribe.

Let's inspect a configuration that subscribes to specific status item updates.

This configuration subscribes to three status items representing the device's operating system version, type, and model.

When this configuration is activated on the device, it will send the initial status report for each of the newly subscribed status items.

Status items are represented as a JSON object, nested by the hierarchical components of that corresponding key-path.

In this case, the device reports it is on iOS 14.5.

When the user updates the software to the latest iOS version, the device will report the status change for the operating-system version item.

The server now detects that the device has been upgraded to iOS 15.

The third pillar of the declarative data model is extensibility.

Given the long life cycle of Apple products, it is essential to maintain compatibility between different versions of your MDM solution with Apple devices, especially as software updates and new hardware models are released.

With declarative management, both the device and server now advertise supported capabilities to each other.

Each knows when it can start taking advantage of new features without having to hardcode software version or hardware dependencies.

The capabilities that the server and client both advertise includes a list of supported features representing both minor and major protocol updates.

The client also advertises supported payloads, which lists the full set of declarations and status items supported by the client.

The server's capabilities are sent to the device via a management declaration.

When the server is upgraded, it synchronizes all new capabilities to the device just as it would any other type of declaration.

The device is immediately able to take advantage of the server's new features.

The client's capabilities are sent to the server as a specific status item any time capabilities change.

This way, the server can immediately start taking advantage of the device's new features and payloads.

Building extensibility into the declarative data model ensures that declarative management is built for the present and the future.

Now that you understand the data model, let's dig into how declarative management is seamlessly integrated within the MDM protocol.

Existing MDM vendors can use declarative management features starting today.

Declarative management is integrated into the MDM protocol and utilizes it for managing the enrollment and unenrollment process and for handling the HTTP transport and device and user authentication.

Existing and mature MDM products can smoothly transition to declarative management without a disruptive change to adopt a new protocol or server infrastructure.

Declarations and the status channel coexist with your already in-use MDM commands and profiles in an extensible way.

This allows you to gradually adopt the different features of declarative management without having to update all of your MDM workflows at once.

For example, a server could choose to only implement status subscriptions, effectively adding a status channel to the MDM protocol without having to adopt all of declarative management.

When the device is unenrolled from MDM, all declarations are removed, and the device state is adjusted accordingly.

Importantly, declarative management does not impact existing MDM behavior at all.

Actually, declarative management leverages existing MDM behaviors using an MDM command for activation and an MDM CheckIn request for synchronization and status reports.

Let's zoom in on each of these next.

A DeclarativeManagement command has been added to MDM.

This command serves two purposes.

First, it activates the declarative management features on the device.

Please note, once turned on, declarative management cannot be turned off.

However, the server can remove all declarations to effectively disable declarative management.

Second, the command can include a payload containing synchronization tokens that will initiate a synchronization flow if needed.

There is also a new DeclarativeManagement CheckIn request type used by the device when synchronizing declarations and to send status reports to the server.

Here is an example of the new CheckIn request type.

The MessageType key is set to the new DeclarativeManagement value.

The endpoint key is set to a value indicating that the client is making a request to retrieve the declaration manifest data from the server.

Some requests -- such as this status report -- can also include Base64-encoded data.

When using the CheckIn request to synchronize declarations, there will be a response from the server.

There are two types of responses: a manifest, which lists the identifier and server token properties of all declarations that the server defines; and single declarations for the device to apply.

Now that you've learned how to activate declarative management and synchronize declarations with a CheckIn request, let's talk about how you can migrate your policies gradually from profiles to declarations.

There's a declaration type specifically for sending and installing profiles as configurations.

This enables you to utilize the full suite of MDM profiles to immediately take advantage of declarative management by shifting profile-based policy logic to the device.

Here is an example of a profile configuration.

The profile is referenced via URL.

When this configuration is activated, the profile is fetched from the URL and installed on the device.

We've taken these steps to make declarative management easy to adopt today with the iOS 15 beta.

Now let's go through an example of how declarative management interacts with the server.

First, we activate declarative management.

This starts with the device already enrolled in MDM.

The server sends a push notification to the device.

The device responds to the push in the usual way, by sending a ServerURL endpoint request with its status set to Idle.

The server then responds with the DeclarativeManagement command.

Upon receipt, the device activates declarative management.

After processing the DeclarativeManagement command, the device sends an Acknowledged status back to the server.

Then if the server has no more commands, it will return an empty response.

The device then starts its declarative management synchronization process; let's go through that next.

The device first sends a CheckIn request with the endpoint key set to declaration-items.

The server responds with a manifest containing declaration metadata.

The device then compares the items in the manifest to the set of declarations it previously received from the server.

Through this comparison, the device can tell which declarations are new, which have changed, and which have been removed.

For each new or changed declaration, the device sends a CheckIn request.

This request's EndPoint key is set to a path uniquely identifying the declaration resource.

The server then responds with the JSON object representing that declaration.

Once all declarations have been fetched from the server, the device starts applying the policy changes represented by this updated state of declarations.

Once the policy changes have been applied, the device will send a status report to the server, with the corresponding updated status items.

To help get you started, let's go through what we are shipping in iOS 15.

The declarative management feature is supported on devices with iOS 15 and iPadOS 15.

It's also only available when the MDM enrollment type is a user enrollment -- either the new onboarding flow introduced with iOS 15, or the flow from iOS 13.

For configurations, we have account and passcode configurations that cover the equivalent set of MDM account and passcode profile payloads.

We also support profile configurations enabling you to start installing the full suite of MDM-supported profiles to your devices declaratively.

Status subscription configurations are also available today and are used for the server to declare the specific status item updates it wants to receive.

There is one type of activation available today.

This simple activation defines a list of configurations that must be applied atomically and may include an optional predicate.

For asset declarations, there are two types available: user identity assets, which represent a user's contact information; and user credential assets, which contain user IDs and passwords for user accounts.

For management declarations, we are supporting two types: organization details and server capabilities.

Next, here are the status items available today.

Each declaration has its own status item that is automatically sent to the server from the device.

Also available are a set of status items that cover basic properties of the device, like details about a device's hardware model and its operating system.

For more detail on these declarations and status items, check out Apple's Device Management developer documentation.

Today we covered the new paradigm of declarative management and its functionality, discovering how declarative management empowers you to make devices more autonomous and proactive.

We learned how to integrate declarative management into your MDM solution.

We went through an example showing how declarative management works and reviewed how declarative management is ready for you to start using today.

We can't wait to find out how you'll reinvent MDM solutions with declarative management.

Thanks for joining me and have a great WWDC.

♪