I’m developing a macOS application that contains an embedded User Service Login Item:
Outer app bundle ID: com.xxx.app
Embedded User Service bundle ID: com.xxx.app.service
Team ID: DE8Y96K9QP
The User Service is embedded at: OuterApp.app/Contents/Library/LoginItems/UserService.app
I deployed a com.apple.configuration.app.managed declaration through an MDM server, with an asset declaration of type: com.apple.asset.credential.identity, the declaration uses: "AppComposedIdentifier": "com.xxx.app (DE8Y96K9QP)"
When the ManagedApp APIs are called from the outer ZTA app, the app successfully receives the identity.
However, when the same ManagedApp APIs are called from the embedded User Service, the identity list is empty. When I instead use the embedded service’s identifier: "AppComposedIdentifier": "com.xxx.app.service (DE8Y96K9QP)", macOS reports either Error.InvalidCodeSignature or Error.NotPresent.
My questions are:
- Can an embedded Login Item or embedded subsystem be the target of an app.managed declaration and access managed identities through ManagedAppIdentitiesProvider?
- Or must AppComposedIdentifier always identify the top-level application that contains the embedded Login Item?
- If the declaration targets the outer application, is there a supported way for the embedded User Service to access the same managed identity—for example, through XPC communication with the outer application?
The outer application and embedded User Service are signed by the same Team ID, and both signatures validate successfully when checked with codesign.
Thanks,
Ying
AFAICT this wasn’t a case considered in the ManagedApp design, and I encourage you to file a bug (or is it an enhancement request :-) for such support.
Please post your bug number, because I want to add my own internal comments to your bug.
is there a supported way for the embedded User Service to access the same managed identity
Possibly, but it kinda depends on the details of your setup.
XPC is unlikely to work here, for reasons I explain in XPC and App-to-App Communication. However, the container app could store the digital identity in a keychain access group that it shares with the login item.
IMPORTANT Keychain access groups are a feature of the data protection keychain. If you’re not familiar with that term, review TN3137 On Mac keychain APIs and implementations.
This approach certainly has some drawbacks:
- You’d have to run the main app at least once in order for it to copy the digital identity from ManagedApp to the keychain.
- And similarly if the device manager pushes a new digital identity.
You could potentially add some mitigations for this. For example, if the login item finds that the digital identity isn’t present, it could itself launch the container app. However, that presents some usability challenges, and whether you can make it work is gonna depend on your specific circumstances.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"