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, instead 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 Active Directory on your corporate network and then seamlessly access your enterprise apps and websites without entering your password again. All of the apps and systems are configured to trust Active Directory to identify users and provide group membership; together they form a security domain.
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 must 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 must 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 must 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.
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. SAML2 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, the MDM solution must implement server-side support for OAuth 2.0 with any identity provider (IdP) they want to support for use with User Enrollment.
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 1.1 through the use of single sign-on extensions. These extensions allow IdPs to implement modern authentication protocols for their users.
Supported apps
iOS, iPadOS, and visionOS 1.1 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, as well as services like file sharing, screen sharing, and secure shell (SSH). Many third-party apps, such as Microsoft Outlook, support Kerberos as well.
Configure single sign-on
You configure SSO using configuration profiles, which can be either manually installed or managed with MDM. The SSO payload allows flexible configuration. SSO can be open to all apps, or restricted by app identifier, service URL, or both.
Simple string pattern matching is used when comparing a pattern against the prefix of a requested URL. As such, patterns must 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/.
Mac users can view and manage their Kerberos ticket information by using the Ticket Viewer app, located in /System/Library/CoreServices/. You can see additional information by clicking the Ticket menu and choosing Diagnostic Information. If permitted by the configuration profile, users can also request, view, and destroy Kerberos tickets by using the command-line tools kinit, klist, and kdestroy, respectively.