What is Platform Single Sign On

[rabbitt]

Platform Single Sign On extension (PSSOe) is a framework built into macOS introduced in 2022 with the release of macOS Ventura.  Intended as an extension of the Extensible Single Sign-On extension (SSOe) for cloud resources, it adds the optional functionality of syncing a local macOS UNIX user account password with a cloud identity provider password.

Version 2 of the specification introduced with macOS Sonoma in 2023 extended the ability to use the cloud identity provider password at the login window and certain authorization prompts.  It also introduced two additional authentication methods that allow for paired SmartCards (also known as PIV or CAC cards) for passwordless authentication and a Secure Enclave backed key that has no effect on the local account password but offers a non-phishable authentication factor for accessing cloud resources.

The goal of Platform Single Sign-On is to allow users to easily access their organization resources that are gated by a cloud identity provider.  Certain features also allow for the cloud identity provider password to be synced to the local macOS UNIX user account password.

What Platform Single Sign-on is NOT

PSSOe is NOT a replacement for a password on a Mac.  The Apple Platform Security guide clearly states, “Passcodes and passwords are essential to the security of Apple devices.”

PSSOe does NOT enable the option to use FIDO2 authenticators at the login or FileVault screen.

PSSOe does NOT automatically deploy via a zero touch onboarding workflow and requires an administrator user to register the device with an interactive login to enable just in time account creation.

PSSOe is NOT “Windows Hello for Business” for Macs.  macOS and Windows run on completely different architectures.

PSSOe does NOT replace the FileVault authentication screen in any way.  A password or a SecureCard paired to a local user account (Apple Silicon based devices only) is the only method of decrypting the FileVault encrypted volumes.

PSSOe does NOT use or enforce any form of Multifactor Authentication (MFA) for macOS.  This includes FileVault decryption, macOS login, or authorization prompts like wake from screen saver or administrator authorization like when installing software, printers, drivers, or changing system settings.

PSSOe is NOT a passwordless solution for macOS.  A SmartCard remains the only “passwordless” login solution offered by macOS.  PSSOe does extend the ability to use a SmartCard tied to a cloud identity provider account to create new user accounts in macOS Sonoma.

PSSOe does NOT work on any platform other than macOS.  It is not designed for VisionOS, iOS, iPadOS, or tvOS.  

PSSOe does NOT create “MDM enabled users” or allow for user level configuration profiles.  For more details, visit https://community.jamf.com/t5/tech-thoughts/mdm-capable-mdm-enabled-or-mdm-managed-users-why-to-not-...

Flavors and Benefits of Platform Single Sign-On

PSSOe requires support from a cloud identity provider.  At this time, organizations using Okta Identity Engine and Microsoft Entra ID can use PSSOe.  No other identity provider at this time has enabled support for this framework.

Okta supports the V1 version of the PSSOe standard with limited support for the V2 standard using only the Password authentication flow.  For additional information, visit https://help.okta.com/oie/en-us/content/topics/oda/macos-pw-sync/macos-pw-sync.htm

Microsoft Entra ID supports the V2 version of the PSSOe standard and has support for Password, SmartCard, and Secure Enclave authentication methods.  The recommended method for all deployments is the most secure and non-phishable credential storage of Secure Enclave.

This ability to create a non-phishable, non-exportable, hardware backed authentication method is the primary and best benefit of PSSOe, and organizations are encouraged to improve their security with this resource.

Platform Single Sign-On authentication method support

Feature	Password	SmartCard	Secure Enclave
Phishing resistant cloud identity provider credential		✅	✅
Phishing resistant Mac local login		✅
Local macOS password synced with cloud identity provider	✅
“Passwordless” login to macOS		✅
Create additional user accounts with cloud identity provider credentials*	✅	✅	✅
macOS 13 Big Sur Support	✅		✅
macOS 14 Sonoma Support	✅	✅	✅

* Requires that the device be registered by a user on the device.  Cannot be enabled without user interaction.

Microsoft Entra ID also allows the user to enable the creation of a Passkey with its PSSOe implementation.  This Passkey support allows for enforcement of the FIDO2 standard and requires user interaction before authentication, assuring the expected user of the device is actually using the device.

Platform Single Sign-On features added by macOS Sequoia

macOS Sequoia beta has included the ability to enforce, attempt, or ignore a cloud identity provider password sync at the FileVault decryption screen, macOS login screen, and certain authorization prompts like wake from screen saver and wake from sleep.

This allows for the traditional “directory bound account” behavior of the past.  If the PSSOe authentication method is set to Password or Secure Enclave mode, and the user is at the macOS login screen, a user could connect to a network and type in their cloud identity provider password and log in to the account.  If a user has forgotten their local macOS UNIX user account password., an administrator could change the user’s cloud identity provider password and allow local device login.

Use of these options is limited to Apple Silicon based devices at the FileVault decryption screen.

macOS Sequoia also allowed for the TouchID or Apple Watch unlock feature to be disabled for the unlock of the screen saver, wake from sleep, and certain authentication requests in place of the identity provider credentials.  Additional keys allow for a grace period for PSSOe registration and offline authentication.

Limitations

FileVault decryption happens in a pre-boot sequence of starting macOS on Apple Silicon devices.  As such, macOS does not have access to network secrets until the drive is decrypted.  

To enforce or attempt the password sync at the FileVault screen, a device must connect to a network.

WiFi Limitations

• WiFi Security - Open or WPA2 Personal password are the only methods allowed.  
• The device must have connected to the network in the past as there is no network selection option available at the FileVault decryption screen.
• Captive Portal Networks of any form, WEP, WPA3 Personal, and any form of WPA/WPA2/WPA3 Enterprise networks (aka RADIUS 802.1x authentication) will not work as these secrets are stored in the system or device keychain, unaccessible until the drive is decrypted.

Ethernet Limitations

• Open network access required.  RADIUS 802.1x authentication is not supported.
• If the device uses a USB ethernet adapter, the user must have connected the device to the specific USB port and accepted the device as able to connect to the Mac.  See https://support.apple.com/guide/mac-help/allow-accessories-to-connect-mchlf779ae93/mac for additional details.
• If an MDM profile has been sent to the device that allows for unrestricted USB access before the device has reached the current state of being at the FileVault decryption screen, any USB based ethernet adapter should be able to connect.

If the FileVaultPolicy is set to RequireAuthentication, there is a highly likely chance the user will be locked out of their machine if the network requirements above are not met.  Testers are recommended to us the optional AttemptAuthentication method instead.  If a network is not present, the existing local UNIX user password will decrypt FileVault.

Creating local user accounts

An initial local macOS user account is required to enable Platform Single Sign-On in any of its authentication methods.  Administrators have several options.

macOS Setup Assistant

A new Mac out of the box can use the native Setup Assistant to create the first user account.  If the device is enrolled with Apple Automated Device Enrollment, an MDM can do several things to control this account creation.

• Enforce creation of a Standard or Administrator account
• Require authentication to the MDM via LDAP or identity provider SSO solutions and create the first user account with that user’s real name and IDP user name
• Lock the first user account created to the identity provider user name and user real name

After the first user account has been created, a user will be prompted to register the device and user account with the PSSOe application.  Administrators via the PSSOe configuration profile can enable or disable the ability to create additional user accounts with the cloud identity provider credentials.

Jamf Connect

Devices with Automated Device Enrollment can deploy Jamf Connect as part of the onboarding process.  (Reference:https://www.jamf.com/blog/zero-touch-deployment-with-jamf-pro-and-jamf-connect/).  Jamf Connect allows for extensive customization of the onboarding and account creation experience including the ability to create user accounts with additional claims sent in the identity provider tokens.  

Possible scenarios include creating local UNIX user accounts with a format other than the UPN (an on-premises account name, for example), use different claims for the user’s real name, assign a specific UID to the user on creation, and use group membership to determine if a user should be a standard or administrator account.

Once the local account is created, the user will be prompted by macOS to register the account with the identity provider for PSSOe.

If the PSSOe authentication is set to Password, disable the Jamf Connect local password sync feature.  Local password sync will be handled by the PSSOe application and macOS.  Features like privilege elevation and custom actions are still available in the menu bar application.

If the PSSOe authentication is set to Secure Enclave, Jamf Connect can still continue to sync the local account password with the cloud identity provider.  Administrators can continue using Jamf Connect at the login window to restrict which identity provider accounts can create additional local user accounts, or administrators can use PSSOe to create additional user accounts if no restrictions are needed after the first account was created.

[Jordy-Thery]

One question I have is what benefit does Platform SSO combined with Jamf Connect offer that the 'normal' SSO extension with Jamf Connect doesn't?

I understand why Jamf Connect is still better than PSSO for many reasons. We currently set up our customers with Connect + the Microsoft SSO extension. Does using the PSSO extension offer any benefits?