Post

Replies

Boosts

Views

Activity

SSO extension and NFC tag
Hi, We are developing an Enterprise SSO extension for use by our customers. It is working well for username/password. We would like to use external security tokens such as Yubikey, via NFC. This works well inside the container app. However, it looks like NFC might not be available to the SSO extension? The container app is signed with an NFC entitlement, and has the relevant key in the plist for a prompt to show the user. We use a 3rd party package called Yubikit to communicate with the Yubikey in the container app... all good. In the trial I did, I had the SSO appex configured as a Credential extension. I have a demo/sample host app that uses this service, that mirrors what our customer's apps will do. Currently, due to limitations in the server we are connecting to, instead of relying on a 401 authentication challenge, I am "manually" activating the enterprise SSO credential appex using ASAuthorizationSingleSignOnProvider, then our customer's host app will use the token the SSO appex returns for authenticating its API calls. This is working perfectly for the username/password scenario. However some of our customers are very security conscious and require hardware tokens. When I drive the same code in the contained SSO Enterprise app extension, and attempt to activate the NFC reader the same way, it seems like it doesn't have access to NFC? I attempted to add the entitlement to the appex as well but it wasn't even available on the list of entitlements! This leads me to suspect that iOS doesn't allow the SSO appex process to have access to the NFC reader, and there's no way to do what I'm attempting? Note: it is easy for us to move to using a Redirect extension instead if this is the answer, but it doesn't seem that it's likely to help? What is the recommended approach here? Regards, Carl
0
0
50
1d
Unable to access shared memory in a sandboxed XPC service
Hi, I'm trying to upgrade my app ready for the mac app store. After a lot of battles with fitting command line tools into the code signing frameworks required (inside out code signing, etc.) I finally found a way forward. It has literally taken me two years. Now I'm trying to get the app to run in sandbox. I'm having trouble accessing shared memory. The architecture is this: a mac app, with a bundled XPC service (the "build engine") and that has bundled (signed) command line tools it runs. The tools are in <XPC bundle>/Contents/MacOS as they should be and are code signed manually by a script I wrote with the hardened runtime option and with entitlements like this: <?xml version="1.0" encoding="UTF-8"?> <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>DELETED FOR PRIVACY</string> </array> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> <key>com.apple.security.device.serial</key> <true/> <key>com.apple.security.device.usb</key> <true/> <key>com.apple.security.get-task-allow</key> <true/> <key>com.apple.security.inherit</key> <true/> </dict> </plist> The same entitlements for both the XPC and it's bundled command line tools. The XPC service passes data to the command line tools using shared memory. This should be possible in a sandboxed app with the use of application groups? The error in the log is like this...
1
0
672
Jan ’21