I recently had cause to revisit this as part of a DTS incident. To start, I set up a test by creating an app that calls
AuthorizationCopyRights
to get the
system.privilege.admin
right. I then compared that UI to the UI presented by the following AppleScript, which internally requests the same right:
do shell script "true" with administrator privileges
These look very different. My app presents a user/password dialog, whereas the AppleScript presents a Touch ID dialog, with a Use Password button that leads to the same user/password dialog presented by my app.
So, we have two different apps that both request the same right, but one allows Touch ID and the other doesn’t. Why?
The answer is that the system authorisation plug-in that handles these requests [1] has a hard-coded check for Apple-signed code. If the requesting process’s main executable is signed by Apple, it allows the use of Touch ID. If not, it skips that option and always prompts for a password.
* * *
I also researched the possibility of installing a custom authorisation plug-in that uses the LocalAuthentication framework to authenticate the user, and then customising my authorisation rights to use that authorisation plug-in. However, this will not work. In talking with the LocalAuthentication team, they made it very clear that this API was designed for use by apps and it is not supported in non-app contexts, like from an authorisation plug-in.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
(s. 732256176)
[1] The
system.privilege.admin
right uses a
class
>
user
rule:
% security authorizationdb read system.privilege.admin
That redirects the authentication to the
authenticate
right:
% security authorizationdb read authenticate
That authenticates the user via the
builtin:authenticate
mechanism. It’s this mechanism that contains the hard-coded check for Apple-signed code.