Hi, I am working on Authorisation Plugin for Mac OS X and able to get going for most of the parts and taking inspiration from Jamf Authorisation Plugin repo https://github.com/jamf/NoMADLogin-AD. I have seen in project they are implementing logic for following. Connecting to Wifi Power management (Sleep, Restart, Power Off) Question: I was wondering these things need to be implemented or is there a way some components from Mac OS X could be integrated calling some API and I don't have to implement them and I see say a top bar where these items are viable as we see in default login screen. I have developed my own login screen and I do see it is all blank everything I have to implement from scratch. Trying luck here if any API is out there to reduce work, else no option but to implement all logic. I'll really appreciate if someone just could help me know such API's are present or not. In case there are will save lot of effort. Thanks,

I am developing a custom authorization plugin for macOS, and I’ve encountered an issue where the auth plugin view remains visible on the home screen for a few seconds after login. Issue Details: After entering valid credentials, I call setResult(.allow) in my plugin to proceed with login. The authentication succeeds, and macOS starts transitioning to the home screen. However, for a few seconds after login, the authorization plugin view is still visible on the home screen before it disappears. I have observed this issue even when using Apple's sample authorization plugin. Observation: This issue occurs without an external monitor (on a single built-in display). If I manually close the plugin window inside Destroy(AuthPlugin.mechanism), then the auth plugin views do not appear on the home screen, which seems to fix the issue. However, when I do this, a gray screen appears for about a second before the desktop environment fully loads. I suspect that the gray screen appears due to the time macOS takes to fully load the home screen environment after login. Questions: Why does the authorization plugin view persist on the home screen for a few seconds after login? Is manually closing the plugin window in Destroy(AuthPlugin.mechanism) the correct way to prevent this, or is there a better approach? Is my assumption that the gray screen appears due to the home screen not being fully loaded correct? If the gray screen is caused by home screen loading, is there a system notification or event I can listen to in order to know when the home screen has fully loaded?

Hello -- I am developing an Authentication Plug-in for the purpose of invoking login with no user interaction (headless). There seems to be sufficient documentation and sample code on how to implement a plug-in and mechanism, and debug the same, which is great. What I am trying to understand is exactly how to modify the login right (system.login.console) in order to accomplish my goal. Question 1: I had the idea of installing my mechanism as the first mechanism of the login right, and when invoked to set the username and password into the engine’s context, in the belief that this would negate the system from needing to display the login screen. I didn’t modify or remove any other mechanisms. This did not work, in the sense that the login screen was still shown. Should this work in theory? Question 2: I then tried modifying the login right to remove anything that interacted with the user, leaving only the following: <array> <string>builtin:prelogin</string> <string>builtin:login-begin</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>MyAuthPlugin:customauth,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> </array> The mechanisms I removed were: <string>builtin:policy-banner</string> <string>loginwindow:login</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:authenticate,privileged</string> <string>loginwindow:success</string> <string>loginwindow:done</string> In place of builtin:authenticate I supplied my own mechanism to verify the user’s password using OD and then set the username and password in the context. This attempt appears to have failed quite badly, as authd reported an error almost immediately (I believe it was related to the AuthEngine failing to init). There’s very little information to go on as to what each of these mechanisms do, and which are required, etc. Am I on the wrong track in attempting this? What would be the correct approach?

I have developed framework and want to use this framework in authplugin which added on same project in different target That plugin target is working fine without framework, once I am adding framework the authplugin is not working Auth-plugin I am using to change in screen-saver plist

I'm building a tool for admins in the enterprise context. The app needs to do some things as root, such as executing a script. I was hoping to implement a workflow where the user clicks a button, then will be shown the authentication prompt, enter the credentials and then execute the desired action. However, I couldn't find a way to implement this. AuthorizationExecuteWithPrivileges looked promising, but that's deprecated since 10.7. I've now tried to use a launch daemon that's contained in the app bundle with XPC, but that seems overly complicated and has several downsides (daemon with global machservice and the approval of a launch daemon suggests to the user that something's always running in the background). Also I'd like to stream the output of the executed scripts in real time back to the UI which seems very complicated to implement in this fashion. Is there a better way to enable an app to perform authorized privilege escalation for certain actions? What about privileged helper tools? I couldn't find any documentation about them. I know privilege escalation is not allowed in the App Store, but that's not relevant for us.

Is there a way to unlock login keychain without using password and with any other authentication factor supported by 3rd party MFA options?

When we enable 3rd party authentication plugin using SFAuthorization window, and during unlock the screen, we have observed the widgets are not showing the content. Attaching the screenshot for reference. We are noticing this behavior from macOS 14.7.1 and macOS 15

I've got a few questions about device check, and would be grateful if anybody knows the answers: why is DC not reset when the device transfers between users? The canonical example of why an app might use DC is if it offers a promotion and to stop user's from getting that promotion multiple times. However, using the same example scenario yes you've stopped the first user from getting multiple promotions but then if that device is transferred to another user you've stopped them from getting any promotions at all? how can you test things when the bits can't be reset? If once you've set the bits on a device then you can no longer ever use that device again to test the apps behavior in the situation when the bits are unset. does the app have complete freedom to set the timestamp to whatever it wants? For example, could the app set a bit with a timestamp of epoch? if the bits are shared between all apps from the same developer, then supposing that developer have more apps in the App Store then there are bits? If they have 5 apps offering a promotion and a device has previously had 4 apps installed, then the user wants to install a 5th app, but with all 4 bits now then the user will be able to abuse the promotion on the 5th app because the app has no way of recording if the promo has been used or not as the collective bits have been used up?

Hi everyone, I’m working on building a passwordless login system on macOS using the NameAndPassword module. As part of the implementation, I’m verifying if the password provided by the user is correct before passing it to the macOS login window. Here’s the code snippet I’m using for authentication: // Create Authorization reference AuthorizationRef authorization = NULL; // Define Authorization items AuthorizationItem items[2]; items[0].name = kAuthorizationEnvironmentPassword; items[0].value = (void *)password; items[0].valueLength = (password != NULL) ? strlen(password) : 0; items[0].flags = 0; items[1].name = kAuthorizationEnvironmentUsername; items[1].value = (void *)userName; items[1].valueLength = (userName != NULL) ? strlen(userName) : 0; items[1].flags = 0; // Prepare AuthorizationRights and AuthorizationEnvironment AuthorizationRights rights = {2, items}; AuthorizationEnvironment environment = {2, items}; // Create the authorization reference [Logger debug:@"Authorization creation start"]; OSStatus createStatus = AuthorizationCreate(NULL, &amp;environment, kAuthorizationFlagDefaults, &amp;authorization); if (createStatus != errAuthorizationSuccess) { [Logger debug:@"Authorization creation failed"]; return false; } // Set authorization flags (disable interaction) AuthorizationFlags flags = kAuthorizationFlagDefaults | kAuthorizationFlagExtendRights; // Attempt to copy rights OSStatus status = AuthorizationCopyRights(authorization, &amp;rights, &amp;environment, flags, NULL); // Free the authorization reference if (authorization) { AuthorizationFree(authorization, kAuthorizationFlagDefaults); } // Log the result and return if (status == errAuthorizationSuccess) { [Logger debug:@"Authentication passed"]; return true; } else { [Logger debug:@"Authentication failed"]; return false; } } This implementation works perfectly when the password is correct. However, if the password is incorrect, it tries to re-call the macOS login window, which is already open. even i though i did not used the kAuthorizationFlagInteractionAllowed flag. This causes the process to get stuck and makes it impossible to proceed. I’ve tried logging the flow to debug where things go wrong, but I haven’t been able to figure out how to stop the system from re-calling the login window. Does anyone know how to prevent this looping behavior or gracefully handle an incorrect password in this scenario? I’d appreciate any advice or suggestions to resolve this issue. Thanks in advance for your help!

Hello developers, I'm currently working on an authorization plugin for macOS. I have a custom UI implemented using SFAuthorizationPluginView, which prompts the user to input their password. The plugin is running in non-privileged mode, and I want to store the password securely in the system keychain. However, I came across an article that states the system keychain can only be accessed in privileged mode. At the same time, I read that custom UIs, like mine, cannot be displayed in privileged mode. This presents a dilemma: In non-privileged mode: I can show my custom UI but can't access the system keychain. In privileged mode: I can access the system keychain but can't display my custom UI. Is there any workaround to achieve both? Can I securely store the password in the system keychain while still using my custom UI, or am I missing something here? Any advice or suggestions are highly appreciated! Thanks in advance! 😊