Bifröst

MDM-Provisioned Connections

Problem

Admin tools that talk to Jamf Pro, Intune or other services need connection details: a URL, a client ID, a secret. When every user types these in by hand, teams end up with typos, with API clients that have the wrong privileges, and with nobody knowing which Mac talks to which server.

Context & forces

• The organisation wants to decide centrally which servers a team uses, and with which API role.
• Individual users still need their own test or lab servers, unless policy forbids it.
• Profile updates must not break what is attached to a connection (schedules, history, playbooks).
• Secrets must not be readable in the profile (see Fáfnir).

Solution

The tool reads an array of connections from its managed preferences domain, for example ManagedInstances or ManagedOrganizations. Each entry has a name, URL, client ID and an encrypted secret. Managed connections appear with a lock, cannot be edited or deleted, and sit next to the user's own connections. A boolean such as AllowUserInstances hides "Add…" when only managed connections may exist.

 MDM profile                           Tool
 ManagedOrganizations ─┐        ┌─────────────────────────────┐
   Production          ├──────▶ │ 🔒 Production   (managed)    │
   Staging             ┘        │ 🔒 Staging      (managed)    │
 AllowUserOrganizations = true  │    My lab server (user)      │
                                └─────────────────────────────┘

For developers

• Identity: a connection's ID is derived from URL + client ID (case-insensitive). The same entry always maps to the same connection, so anything attached to it survives profile updates and reorderings.
• Validation: required fields (URL, client ID, secret), https only. Invalid entries are skipped and the warning is shown in a "Managed by your administrator" section, not hidden in a log.
• Lifecycle: a connection removed from the profile is removed from the tool on the next launch or activation. Connections users added themselves are never touched.
• Secrets: a managed secret is never copied into the user's keychain. It is read from the profile and unsealed only when a token is requested.
• Other policy switches live in the same domain (e.g. "view-only on this Mac").

Consequences

• Onboarding a new team member is a scope change in MDM, nothing else.
• The organisation controls which API clients, and therefore which privileges, are in use.
• Users keep the freedom to add their own servers unless the admin turns it off.
• The tool must handle connections appearing and disappearing at runtime.
• Without sealed secrets, this pattern would leak credentials to everyone on the Mac.

Known uses

• Gimle reads ManagedInstances, each optionally with a file-share mount path, and AllowUserInstances. Instances found in a shared backup folder are offered with URL and client ID pre-filled.
• Jarl reads ManagedOrganizations, with an optional client name for grouping in the sidebar, and AllowUserOrganizations, which also hides "Duplicate…".
• Lynceus reads ManagedInstances in Gimle's format, marks them "Configured by MDM" and doesn't let users edit them; AllowUserInstances = false hides the user's own instances.

Name

Bifröst, the guarded bridge between worlds: only the paths the gatekeeper allows lead to the servers.