Intro to Single Sign-on with Apple devices
Organizations often make use of Single Sign-on (SSO), which is designed to improve the users’ sign-in experience to apps and websites. With SSO, a common authentication process is used to access multiple apps or systems—without the user asserting their identity again. Rather than saving a user’s credentials (for example, their password) and reusing it for every app or system, SSO is using the token provided by the initial authentication, giving users the appearance of a one-time password concept.
For example, SSO takes place when you sign in to your identity provider (IdP) and then seamlessly access your proprietary in-house apps and websites without entering your password again. All of the apps and systems are configured to trust the IdP to identify users and provide group membership; together they form a security domain.
Modern authentication with SSO
Modern authentication refers to a set of web-based authentication protocols used by cloud applications. Examples include SAML 2.0, OAuth 2.0 (iOS 16, iPadOS 16.1, visionOS 1.1, or later), and Open ID Connect (OIDC). These protocols work well over the internet and encrypt their connections using HTTPS. SAML 2.0 is frequently used to federate between an organization’s networks and cloud applications. Federation is used when crossing trust domains—for example, when accessing a set of cloud applications from your on-premises domain.
Note: To take advantage of OAuth 2.0 for use with User Enrollment, the device management service needs to implement server-side support for OAuth 2.0 with any IdP they want to support.
Single sign-on with these protocols varies depending on the vendor and the environment. For example, when you’re using Active Directory Federation Services (AD FS) on an organization’s network, AD FS works with Kerberos for SSO, and when you’re authenticating clients through the internet, AD FS can use browser cookies. Modern authentication protocols don’t dictate how the user asserts their identity. Many of these protocols are used in combination with multifactor authentication such as an SMS code when authenticating from unknown clients. Some vendors provision certificates on the device to identify known devices to aid in the authentication process.
IdPs can support SSO in iOS, iPadOS, macOS, and visionOS through the use of Single Sign-on extensions. These extensions allow IdPs to implement modern authentication protocols for their users.
Kerberos
Kerberos is a popular authentication protocol used in large networks for SSO. It’s also the default protocol used by Active Directory. It works across platforms, uses encryption, and protects against replay attacks. It can use passwords, certificate identities, smart cards, NFC devices, or other hardware authentication products to authenticate the user. The server that performs Kerberos is known as the Key Distribution Center (KDC). To authenticate users, Apple devices need to contact the KDC over a network connection.
Kerberos works well on an organization’s internal or private network because all clients and servers have direct connectivity to the KDC. Clients that aren’t on the corporate network need to use a virtual private network (VPN) to connect and authenticate. Kerberos isn’t ideal for cloud- or internet-based apps. That’s because these applications don’t have direct connectivity into the corporate network. For the cloud- or internet-based apps, modern authentication (described below) is more appropriate.
macOS prioritizes Kerberos for all authentication activities when integrated into an Active Directory environment. When a user logs in to a Mac using an Active Directory account, a Kerberos ticket-granting ticket (TGT) is requested from an Active Directory domain controller. When the user attempts to use any service or app on the domain that supports Kerberos authentication, the TGT is used to request a ticket for that service without requiring the user to authenticate again. If a policy is set to require a password to dismiss the screen saver, macOS attempts to renew the TGT upon successful authentication.
For Kerberized servers to work correctly, both forward and reverse Domain Name System (DNS) records should be accurate. System clock time is also important, because clock skew needs to be less than 5 minutes for any servers and clients. The best practice is to set the date and time automatically using a Network Time Protocol (NTP) service, such as time.apple.com.
Supported apps
iOS, iPadOS, and visionOS provide flexible support for SSO to any app that uses the class NSURLSession or URLSession to manage network connections and authentication. Apple provides all developers with these classes to seamlessly integrate network connections within their apps.
Any Mac app that supports Kerberos authentication works with SSO. This includes many of the apps built in to macOS, such as Safari, Mail, and Calendar, and includes services like file sharing, screen sharing, and secure shell (SSH). Many third-party apps also support Kerberos.
Configure Single Sign-on
To configure SSO, you apply the necessary a configuration using a device management service. The configuration needs to include information about the Single Sign-on extension communicating with the IdP, as well as which apps and Safari web URLs are allowed to use SSO or restricted from using it. You can also use the Apple provided Kerberos Single Sign-on extension included in iOS, iPadOS, macOS, and visionOS.
Simple string pattern matching is used when comparing a pattern against the prefix of a requested URL. As such, patterns need to begin with either https:// or http:// and won’t match differing port numbers. If a URL matching pattern doesn’t end with a slash (/), one is appended.
For example, https://www.betterbag.com/ matches https://www.betterbag.com/index.html but won’t match http://www.betterbag.com or https://www.betterbag.com:443/.
A single wildcard may also be used to specify missing subdomains. For example, https://*.betterbag.com/ matches https://store.betterbag.com/.