The goal is straightforward. You’d like a system that would let your users sign in once to get access to everything: their user accounts on computers, phones, or tablets; native applications on those devices; local network resources; and cloud apps and services. Unfortunately, the reality of identity management today isn’t straightforward at all.
Single Sign-on (SSO) solutions might appear to be the answer. But while they can currently help you create a smoother authentication experience for your users, they don’t necessarily enable users to access everything after signing in just once. In this guide, we’ll explore what SSO can do now and how identity management is evolving on Apple platforms.
Here’s a quick look at what we’ll cover:
- Single Sign-on: Promise and Reality
- Extensible Enterprise SSO
- Redirect and Credential Extensions
- Enrollment Customization
- Federated Authentication
- Managed Apple IDs
Single Sign-on: Promise and Reality
Just so we’re on the same page to start: Single Sign-on is a system of communications between services that end-users want to access and identity providers (IdPs) that confirm those users are authorized to do so.
A typical scenario: A user navigates to a web app. That web app checks to see if the user’s browser has a piece of data, generally a token, that indicates that the user has been authenticated. If not, the web app redirects the user’s browser to a sign-in page. The user provides credentials (typically a username or email address and password), which the sign-in page then checks against those stored by an identity provider. If the IdP returns a message saying that the user is authenticated, the user is permitted to access the requested service and—crucially—any other services the SSO governs.
(An alternative scenario: Users go directly to a Single Sign-on portal, sign in there, then select from the company’s list of available apps. But the process is much the same.)
The trouble is, this sign-in sequence lets the user access only those cloud apps that your organization has configured to work with your IdP. Historically, that authorization didn’t extend to user accounts or to native apps on the Mac, iPad, or iPhone. A user would log in to one of these devices with a password or passphrase, and then need to sign in separately with SSO to access cloud services.
Extensible Enterprise SSO
Apple provides a partial solution to this problem in the form of Extensible Enterprise SSO. Introduced with iOS 13, iPadOS 13, and macOS Catalina 10.15, Extensible Enterprise SSO enables native apps to use Single Sign-on to authenticate users on their devices. (This isn’t the same as Sign in with Apple, which allows a user to use a personal Apple ID to access apps and services; that’s a consumer-level solution that doesn’t meet enterprise requirements.)
Extensible Enterprise SSO arrived at a time when many businesses were already moving from on-premises directory-based management (such as Active Directory) to cloud-based IdPs (such as Okta, OneLogin, Google Workspace, and Azure Active Directory). Although these IdPs work seamlessly with web-based apps, they can’t vouch for you when you open native ones on a local device.
And although those traditional on-premises directory solutions can synchronize local and network passwords, IdPs can’t do the same. When a user changes their Mac password, their IdP account password isn’t automatically updated. This leads to a fragmented experience for users and limited management capabilities for admins.
Apple’s Extensible Enterprise SSO could help heal this fragmentation by enabling native apps to authenticate against an organization's IdP.
Take, for example, the Kerberos SSO extension. Included in iOS 13, iPadOS 13, and macOS Catalina, it’s intended to replace Enterprise Connect—a solution that Apple Professional Services has offered to help synchronize Mac account passwords with Active Directory credentials. Apple now encourages customers to move from Enterprise Connect to the Kerberos SSO extension, which was significantly upgraded in MacOS Big Sur. For a full run-down, see our guide to the Big Sur Kerberos Extension. And to learn more about using Kandji to configure an SSO Profile, see our support page.
But here’s the big challenge: In order for Extensible Enterprise SSO to realize its potential, developers must include its functionality in their applications, and IdPs must support it too. So far, that implementation has been spotty.
Enrollment customization gets us another step closer to real SSO. When you use Apple Business Manager and an MDM solution, you can specify a customized web page that appears during Setup Assistant when a user first starts a new device. That web page can include custom branding, consent text, and—most importantly for this discussion—an SSO authentication screen. MDM solutions such as Kandji can require that new employees sign in with their SSO credentials as part of setting up their new Apple devices.
But signing in to SSO using enrollment customization does not bind your Mac login to your SSO login; it can only ensure that they start out the same. If users change their Mac passwords, that doesn’t update their IdP passwords.
Kandji just released support for enrollment customization: When you configure an Automated Device Enrollment Configuration Library Item, you can require users to authenticate via SSO before continuing with the enrollment process. For more on that, see our support article Require Authentication with Automated Device Enrollment.
Another important piece in the identity and SSO puzzle: Federated authentication.
In simple terms, Federated authentication lets you link your company’s Apple Business Manager account to Azure AD. (Generally this article refers to Apple Business Manager, but this functionality actually appeared first in Apple School Manager.) This allows employees to use their existing Azure AD login credentials as Managed Apple IDs, which they can then use to sign in to Apple products and services, including iCloud and Shared iPad.
If you’d like to federate with another IdP such as Okta or OneLogin, you can integrate Azure AD with those IdPs—and then federate Azure AD to Apple Business Manager. For example, if your organization uses Google Workspace (formerly G Suite), you can sync Azure AD with your Google Workspace. This allows you to use your Google credentials with Apple Business Manager Azure AD Federation. For more on that, see Federated Authentication in Apple Business Manager with Azure AD.
Managed Apple IDs
Managed Apple IDs are Apple ID accounts that your organization can create and control. When Managed Apple IDs first became available for business users, they were generally useful only for IT administrators, to accomplish tasks such as managing and enrolling devices in an MDM via Apple Business Manager; assigning app licenses to employees; and managing roles and privileges of Apple Business Manager users.
Managed Apple IDs are also at the heart of Apple’s User Enrollment feature, which makes BYOD (bring your own device) deployments practical for enterprises, by keeping employees’ personal and work data separate. You can read more about this in our guide to Managed Apple IDs and in our explanation of creating Managed Apple IDs with Azure AD.
Kandji supports Managed Apple IDs, as well as enrollment customization and a host of other identity-management features that can make life better for both you and your users. With a suite of features like zero-touch deployment, one-click compliance, and offline remediation, Kandji is already a great way to enroll, configure, and secure your devices, and we look forward to creating new functionality as the SSO landscape evolves.
April 9, 2021: This article has been updated from the original version, first published January 28, 2020.