Backbone of management for Apple devices is the MDM protocol, used to manage macOS, iOS, iPadOS and tvOS. Apple regularly evaluates the MDM protocol against their device management goals and update it to meet the needs of MDM solution developers, admins and end users. Today the MDM protocol can be described as an imperative and reactive protocol. - Each management workflow takes time and multiple round trips between the MDM server and the managed device - Performance challenges grow larger as the number of devices being managed increases across the organization Meanwhile, Apple wants to ensure that the MDM protocol remains responsive and scales to meet a growing population of devices. - Apple has reworked the MDM protocol and updated it - New management option - declarative management Declarative management brings policy management to MDM-managed devices - Allows devices to be autonomous and proactive. - Lessens load on MDM server and removes need for constant polling Autonomous devices: - React to their own state changes and applies management logic to itself - These reactions and logic applications occur without prompting from the server Proactive devices: - Has a status channel which reports asynchronously back to the MDM server when important state changes occur on the device. - This avoids the need for MDM servers to poll devices Enabling devices to be autonomous and proactive is the foundation of declarative management. This allows for increase performance and stability While it is a new way to manage devices, it still uses the MDM protocol. The declarative management functionality is built into the existing MDM protocol and is coming first to iOS devices. Declarative data model: Three pillars to the declarative data model Declarations: Payloads which the MDM server defines and sends to devices Status channel: New channel of communication, used by the device to proactively update the server with new information about itself Extensibility: Enables new features to be added to declarative management without causing disruption to existing MDM servers and devices First Pillar - Declarations: - Represent the policy that an organization wants to enforce on its devices - Used for accounts, settings and restrictions - Can be used for policies which apply to all users and/or devices, a subset of users and/or devices or a specific user or device. An example declaration structure can be seen at 3:41 in the session video The data representation for declarations is similar to management profiles, where a declaration is also a dictionary with a set of keys and standard types for values. Instead of XML plists, declarations are serialized as JSON objects when sent over the network. All declarations have three required properties: 1. Type: Defines which policy a configuration represents 2. Identifier: Typically has a UUID represented as a string which uniquely identifies the declaration within the set of all declarations sent to the device - The device uses this value when synchronizing declarations with the MDM server 3. ServerToken: Represents a unique revision of the declaration based on the Identifier key - This key is also used when synchronizing declarations with the MDM server - The value is a string which must be different for each revision - It could be a numeric counter or a UUID string A non-required property though almost always present is the Payload property - Payload is a data-specific piece of the declaration, containing the keys and values pertinent to the declaration's Type. Just like with profile payloads, some keys in a declaration payload may be required and others may be optional. Values can be: * Strings * Numbers * Booleans * Arrays * Dictionaries The values may be constrained in range (like numbers 1 through 10) or to a specific set of values like a string enumeration. Four declaration types: * Configurations * Assets * Activations * Management Configuration - represent the policies to be applied to the device Examples: * Accounts * Settings * Restrictions Configurations are similar to MDM's existing profile payloads An example configuration can be seen at 5:27 in the session video Assets - represent references to ancillary data needed by configurations This can be a shared area of large data or a personalized one. For large data items, the asset declaration contains a URL which is used by the device to fetch the actual asset data. This data can be fetched from either the device's MDM server or from a separate Content Delivery Network (CDN) server. Serving assets from a CDN shifts the burden of supporting large network bandwidth from your MDM server to a service better suited for carrying that load. Assets can also be used to represent data to an end user, such as their name, email address, passwords for accounts and digital 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, where multiple configurations can reference the same asset. This avoids the need to replicate the same asset information multiple times for each configuration. This also allows information updates to be applied to one asset instead of needing to update multiple configurations. The ability to do incremental updates like this for many configurations at a time cuts down on overhead and improves overall the responsiveness of the MDM management system. An example asset declaration can be seen at 7:20 in the session video Activations - represent sets of configurations atomically applied to a device All configurations along with all applied 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. An example activation can be seen at 8:02 in the session video Activations have a many-to-many relationship with configurations. Activations can refer to multiple configurations and a configuration can have multiple activations referencing it. This many-to-many relationship allows for complex logic to be handled autonomously by the individual managed devices. Activation can include a predicate which determines the activation state (if active or not) on a device. - The device will only process the activation if the predicate evaluates to TRUE. For example, a predicate can determine that the activation is only active on a particular device type, such as an iPad. Another example is wanting to have a set of policies only apply to iOS versions greater than iOS 14. This capability allows the server to send all the declarations for any device states and let the devices themselves determine which ones they need to apply. This adds to the autonomy of the individual devices. As the activation state changes, the predicates are automatically re-evaluated by the devices without intervention from the MDM server. Policy associated with the new device state will be applied and any outdated policies removed. This allows the device to act proactively. In the absence of a predicate, the device will always process the configurations referenced by the activation(s). An example activation with a predicate can be seen at 9:42 in the session video Management The final kind of declaration is a management declaration. Management declarations are used to send 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 MDM server. These declarations are helpful for conveying static data to the device which shouldn't change. - Represent properties of the overall management state - Organization information - MDM server capabilities - Conveys static information to the device. Second Pillar - Status Channel Given how declarations work, the declared state of the device may not match the actual state of the device at any one point in time. As an example, any declaration which requires human interaction will not apply until that action has been taken. To add visibility for the MDM server, the status channel allows devices to update the MDM server with their actual state. - Client sends reports to the MDM server using the status channel - MDM server can subscribe to specific status items, allowing it to only receive updates to the changes it cares about - Status items are identified by key-paths, which consist of period-separated string tokens - device.operating-system.family - device.operating-system.version - device.model.family - device.model.identifier Status items can be used in activation predicates. An example activation with a predicate can be seen at 9:42 in the session video. MDM servers subscribe to status items using status subscription configurations. Upon receiving this subscription configuration, the device will send an initial status report for the subscribed status items, then send follow-up reports if a subscribed item changes. No change, no report aside from the initial report. The status reports are incremental, so only the changed items are reported. The status of declarations, applied or not applied, is always reported to the MDM server when changed. - Use status subscription configurations - Device sends initial and subsequent status reports to MDM server - Status reports are always incremental; only changes are sent - Declaration status always reported to MDM server when changed An example status subscription configuration can be seen at 12:04 in the session video An example initial report can be seen at 12:14 in the session video Status items are JSON objects which are nested by the hierarchical components of that corresponding key-path (see example at 12:25 in the session video) Third Pillar - Extensibility Apple's products have a long life cycle and it is essential to maintain compatibility between different versions of your MDM solution with Apple devices of varying ages and capabilities. Declarative management means that both the device and the MDM server now advertised supported capabilities to each other. Each side of the management system is now aware of what the other side supports because each side advertises their supported capabilities to each other. Each side knows when it can start taking advantage of new features. These advertisements include a list of supported features, representing both major and minor protocol updates. The client also advertises supported payloads, including the full set of declarations and status items supported by that device. Meanwhile, the MDM server advertises its capabilities to the device via a management declaration. When the MDM server is upgraded, it synchronizes all new capabilities with the device like it would any other declaration, which allows the device to start working with the MDM server's new features. Likewise, the client sends new capabilities to the MDM server as a specific status item when that device's capabilities change. - Compatibility over time - Device and MDM server advertise what they support - Supported features - Supported payloads - MDM server indicates support in management declaration. - Client indicates support as specific status item Integration with MDM Declarative management is integrated into the MDM protocol, so existing MDM vendors can use declarative management features starting today. Declarative management utilizes the MDM protocol for managing the enrollment / unenrollment process, for handling the HTTP transport and for device and user authentication. Existing MDM products should be able to smoothly transition to declarative management. Declarations and the status channel should coexist with already-used MDM commands and profiles, allowing MDM vendors to gradually adopt declarative management without having to update all MDM workflows at once. When devices are unenrolled from an MDM server, all declarations are removed from the device and device state is adjusted accordingly. Declarative management should not interfere with existing MDM behavior. Declarations in fact leverage existing MDM behaviors using an MDM command for activation and and MDM CheckIn request for synchronization and status reports. - Integrated into the MDM protocol for enrollment, transport and authentication - Not disruptive - Declarations and MDM commands / profiles coexist - Gradual adoption of declarations - MDM unenrollment removes all declarative management - Does not interfere with existing MDM behavior Activate declarative management New DeclarativeManagement MDM command - Activates declarative management on the device - Once turned on, declarative management can't be turned off on the device (without unenrolling, which as previously mentioned removes all declarations.) - However, the MDM server can remove all declarations which effectively disables declarative management - Synchronization of declarations - Can include a payload of synchronization tokens which will initiate a synchronization flow if needed New DeclarativeManagement CheckIn request type - Used by the device when synchronizing declarations and to send status reports to the MDM server. An example CheckIn request can be seen at 16:29 in the session video. Using the CheckIn request - Synchronizes declarations - Response from the MDM server: - Declaration Manifest, which lists the identifier and server token properties of all declarations which the MDM server defines. - Single declarations, which apply to the device. Migrate to declarative management - Declaration type designed to send and install existing profiles as configurations - Allows you to use profiles with declarative management - Shifts profile-based logic to device An example configuration referencing a profile can be seen at 17:41 in the session video. Profile is referenced in the configuration by the profile's URL (i.e. https://mdm.server.here/profiles/profilename.mobileconfig) These capabilities are available today with the iOS 15 beta