I'm trying to find a working scenario how to implement 802.1X authentication for Wi-Fi enterprise with a custom authorization plug-in. The problem is I don't fully understand what mechanism, in the scope of the system.login.console authorization right, is responsible for 802.1X authentication. The system.login.console authorization right has the following mechanism: builtin:policy-banner (displays Login Window banner, if set). loginwindow:login (prompts for credentials). builtin:login-begin builtin:reset-password,privileged (performs password reset using Apple ID). builtin:forward-login,privileged (forwards credentials from EFI on boot). builtin:auto-login,privileged (applies auto-login credentials on boot). builtin:authenticate,privileged (invokes`` pam_authenticate(3) for authorization service; sets "uid" context value). PKINITMechanism:auth,privileged (initialises Kerberos by obtaining a TGT). builtin:login-success loginwindow:success (secures the login session from unauthorized remote access; records the login in the system’s utmp and utmpx databases; sets the owner and permissions for the console terminal). HomeDirMechanism:login,privileged (mounts the user's home directory). HomeDirMechanism:status (displays progress of home directory mounting). MCXMechanism:login (applies configuration profiles). loginwindow:done  Since the second stage of that authentication is handled by the pam_opendirectory.so module and is dependent on the network being present, the first stage (authenticating via 802.1X to the network) must necessarily occur prior to that. That is, it must occur before the builtin:authenticate mechanism. Am I correct in thinking that the loginwindow:login mechanism not only displays the login prompt, but then also attempts 802.1X authentication? If so, it makes impossible to implement the same functionality in a custom plug-in. I tried to use the CoreWLAN framework, but that didn't work. I even filed a bug, but got a reply from Apple saying that CoreWLAN only works from application context. As the result, I cannot switch a WI-Fi network using CoreWLAN, while staying in Login Window, even from a daemon. As soon as I leave the Login Window screen, CoreWLAN methods (Wi-Fi enterprise related) start working. Or does 802.1X authentication occur in a different mechanism (lower in the call chain)? And it's possible somehow to pass credentials and selected wifi network parameters as a hint or a context value from the custom plugin mechanism to the system built-in mechanism that is responded to 802.1X authentication?

With the native Login Window client (UI) it was possible to authenticate to a Wi-Fi Enterprise network from the login window screen. If a profile with Login Window Mode ( 802.1X authentication) is applied via MDM or manually, there is shown a special pop-up menu right above the user name field. But how can I implement similar functionality in a custom authorization plugin? I tried to add my own Wi-Fi selector calling the associateToEnterpriseNetwork method of the CoreWLAN framework, but from the login window context it always returns the error: code -3903 . I called associateToEnterpriseNetwork without specifing the indentity like this: [interface associateToEnterpriseNetwork:network identity:nil username:myUsername password:myPassword error:&error]; Are there any other ways to add Wi-Fi enterprise support to authorization plugins? Maybe there're some standard ways to implement. Thanks in advance!

When an authorization plug-in (like NameAndPassword or so on) is enabled for the system authorization right "authenticate", FileVault cannot be enabled from UI. Clicking on the button "Turn on FileVault..." has no effect. In the system logs I see the error that SecureToken was not found. Without an authorization plug-in, the button "Turn on FileVault..." works as expected, and I see no complaints in the logs regarding the SecureToken. If to do the following: Disable a custom authorization plug-in. Unlock the "FileVault" tab in "Security&Privacy", by clicking on the "lock" icon, using the native authenticaion UI. Enable a custom authorization plug-in again. Hit the button "Turn on FileVault..." In this case the button works as expected. Thisobservation makes me think that the native UI client passes the SecureToken and maybe something else as a part of the authorization process, but a custom authorization plug-in does nothing like that. The question is how to pass the SecureToken or maybe something else what's needed from a custom authorization plug-in? Maybe there is a special undocumented authorization hint for that? Or the observed behavior is a bug?

In macOS Catalina and earlier, I could invoke Touch ID (calling evaluatePolicy) from a launch agent while being on the lock screen. It worked a little bit different though, not like for a standard app, without showing the native Touch ID prompt, just like in the LoginWindow app. Unfortunately, this scenario absolutely doesn't work in Bir Sur giving the error: coreauthd MechanismUI[39] has finished with Error Domain=com.apple.LocalAuthentication Code=-1004 "Can't show UI while not in a console session" UserInfo={NSLocalizedDescription=Can't show UI while not in a console session} My questions are: What is the "console session" in the evaluatePolicy context? Can I emulate the previous behaviour somehow? Are there any workarounds? I noticed that the native macOS apps like LoginWindow and so on work with Touch ID as usual even from the lock screen. The only difference I noticed is that these apps use the private version of the method evaluatePolicy with a specified uiDelegate.

I have a launch daemon (via launchd) that requires access to the macOS built-in camera to do some video processing using OpenCV. Since macOS Catalina (I believe in Mojave also), my launch daemon has no access to the camera at all. No security prompts - nothing at all. I tried the same trick as I did for "Input Monitoring": Pack the daemon in an app-like structure, whitelist the camera in harden runtime, and run the daemon's code as an application. In that case, I do have a security prompt as expected and my code works with the camera. Also, I get my application listed under "Privacy" - "Camera". Unfortunately, whenever I try to launch the same binary as a daemon using launchd, I get no access to the camera. No matter whether my daemon-application was added before under "Privacy" - "Camera" or not. The approach above worked with "Input Monitoring" but not with the camera (for "Input Monitoring" I launched the daemon as an app to whitelist it first and launched it later via launchd). Is that a bug? Or launch daemons are not allowed to access the camera in macOS Catalina in any case? Any ideas?

As a part of our macOS solution, we have an auxiliary launch agent that generates a private key with a custom access control attribute (kSecAttrAccessControl) to request user presence, using SecAccessControlCreateWithFlags (or using Security Enclave). Generation fails with errSecMissingEntitlementwithout Keychain Access Groups Entitlement. To make it working, we packed the daemon into an app like structure and added the entitlement, but required for a provision profile. That works well for development, but how are we supposed to distribute our daemon now? There are only two types of distribution provision profiles: App Store Distribution Profile and Ad Hoc Distribution profile. Both doesn't suit for our case. The first one is for applications, but we have a daemon, I don't think Apple will allow auxilary daemons or agents there, the second one is for testers. That looks really ridiculous, the code works, but we cannot distribute it.Are there any ways to generate the keys with access control, preferably with Security Enclave, and distribute the code for our case?We used the guide: https://forums.developer.apple.com/message/408009#408009With App Store Distribution profile the agent crashes on the client's devices with:Exception Type: EXC_CRASH (Code Signature Invalid)Exception Codes: 0x0000000000000000, 0x0000000000000000Exception Note: EXC_CORPSE_NOTIFYBut it's still unclear how to distribute our launch agent as a part of our solution, since we cannot user Apple Store?

If to call evaluatePolicy with or without biometry, it doesn't matter, the first call always fails after logon. LAContext *context = [[LAContext alloc] init]; [context evaluatePolicy : LAPolicyDeviceOwnerAuthentication localizedReason:@"Test" reply: ^(BOOL success, NSError *error) { if (success) { } else { NSLog(@"error = %@, %@", [error userInfo], [error localizedDescription]); } }];My steps are:1) Log in as a user with by password ( the user must be logged off before the attemp)2) Run the code as above from an app.3) the first call fails with the "UI activation timed out." error.4) any futher calls work as expected.The only workaround for me is to call evaluatePolicy twice, but that's too ugly )Is that a known issue? Maybe there are some other workarounds?Observing this on macOS 10.15.4 and macbook pro 16"

Hi,I've been trying to use Touch ID SDK (using evaluatePolicy) within a custom SFAuthorizationPluginView in my AuthorizationPlug-in.But the Touch ID never works over the login screen (the Touch ID popup is also not shown), even for the users who logged in before with a password. To test this, I've just slightly modified the NameAndPassword sample, by adding the evaluatePolicy call on a button click.Is that a bug or just a missing feature?As for other cases like unlock, the SFAuthorizationPluginView's parent window overlaps the Touch ID popup. It doesn't look user-friendly. Is there any other way to use Touch ID from SFAuthorizationPluginView?Or has Apple any plans to add Touch ID support to the AuthorizationPlug-in API?

I'm testing Touch ID API within a custom Authorization Plug-in (LAContext stuff).All I need, it would be nice to have this, is to use Touch ID as an additional authentication factor for logging into the system.But in order to use Touch ID, the user must log in at least one time using his existing username and password.As soons as the user logged in, Touch ID works as expected.Is it possible to avoid this somehow, and to use Touch ID with entering user credentials for the first time?I understand this is for a security reason. But is there any way to override the default behaviour from the API ?Thanks in advance.

I'm trying to generate a private key with and without the Security Enclave like this: CFErrorRef error = NULL; SecAccessControlRef sacObject = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenUnlocked, kSecAccessControlDevicePasscode, &error); NSDictionary *attributes = @{ // (__bridge id)kSecAttrTokenID: (__bridge id)kSecAttrTokenIDSecureEnclave, (__bridge id)kSecAttrKeyType: (__bridge id)kSecAttrKeyTypeEC, (__bridge id)kSecAttrKeySizeInBits: @256, (__bridge id)kSecPrivateKeyAttrs: @{ (__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacObject, (__bridge id)kSecAttrIsPermanent: @YES, (__bridge id)kSecAttrLabel: @"TestKey", }, }; SecKeyRef privateKey = SecKeyCreateRandomKey((__bridge CFDictionaryRef)attributes, &error); if (!privateKey) { NSError *err = CFBridgingRelease(error); // ARC takes ownership // Handle the error. . . }SecKeyCreateRandomKey succeeds only when when I set the proper entitlement (Keychain Access Groups) for both cases, which works perfectly for an UI app.The problem is that I need to generate the key from a service-console application. Thus, when I add the entitlement (Keychain Access Groups) to my console app, it simply doesn't start.Any ideas how to fix that? Thanks!

I have been trying to integrate Touch ID into a non-UI service that comes as a part of our authentication solution. The best approach would be to get a raw fingerprint image or some other biometric data that can be linked somehow with the user identity.But as I understood, all biometrics, including fingerprints, are hidden deep inside the Security Enclave, and there are no ways to get them.Please correct me if I am wrong.Also, the only Touch ID API that I found is LAContext's evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics from the LocalAuthentication framework. The framework is pretty 'high level' one and returns generally speaking 'authenticated' or not 'not authenticated' status and doesn't provide any useful user-specific data that can be checked to verify the user identity on our side.Thus, the general idea of the integration now is to use Touch ID's API (evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics) to generate a key pair located in the Security Enclave and use it later for getting signatures. But is there a way to hide the standard authentication UI for Touch ID? I don't need it because of the custom UI implementation.Or is there any other low level Touch ID API?Thanks!

Hello,We have a service (daemon) that requires keystroke monitoring and runs under the new "Input Monitoring" policy ( starting from Catalina) .The problem is when I run the daemon from Xcode I do receive the standard "keystroke receiving" prompt.When the service runs as a daemon or as a console application there is no "keystroke receiving" prompt at all.Also, when there are no apps added in the "Input monitoring" list, the button add ("+") is not even shown.Thus, it's even impossible to add manually our service (daemon) to that policy.As the result, the service is not functioning at all with the "TCC deny IOHIDDeviceOpen" error.But I never got any prompts neither for a console app nor for a daemon.The question is how we must ship the service (daemon) the get the proper "keystroke receiving" prompt?Our service ships without a bundle, just as a console application with a daemon plist.As for a test, I tried to create an application bundle doing some IOHIDDeviceOpen requests, and I got the "keystroke receiving" prompt.But I don't think it will be good to ship the daemon within an application bundle.Any ideas how get the prompt for a daemon case?Thanks in advance!