Guide for Apple IT: Identity and Single Sign-On (SSO)

The goal is straightforward. You want a system that will let your users present their credentials once and then have access to everything they need: their user accounts on computers, phones, or tablets; native applications on those devices; local network resources; and cloud apps and services. 

That’s been the goal for decades, and several identity-management technologies have emerged that get us close. Single sign-on (SSO) is one of them. But while SSO can absolutely help you create a smoother authentication experience for users, it still doesn’t deliver that sign-in-once/get-access-to-everything experience that the name might imply.

Here’s a high-level guide to what SSO can—and can’t—do now and how it’s evolved on Apple platforms.

What Is Single Sign-on?

Just so we’re on the same page to start: Single sign-on is a system of communications between (a) services that end-users want to access and (b) identity providers (IdPs) that can confirm whether or not those end-users are who they say they are. Once enabled, SSO lets those users access multiple services after providing their credentials just once—rather than requiring them to sign in to each service individually. This means that they don’t have to memorize multiple passwords or slow down to fill out their credentials every time they want to get work done.

Here’s one generalized scenario: A user points their browser to a web app they want to use. That web app checks to see if that user is authorized, generally by asking the user’s browser for a piece of data—usually a token— indicating that the user has been authenticated. If not, the web app redirects the user’s browser to a sign-in page.

There, 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—other services that have been configured to consult the same IdP.

It’s important to note that 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 has not extended to the user’s local device account or to native apps on the Mac, iPad, or iPhone. A user would log in to their account on a device with a password or passphrase, and then sign in separately with SSO to access cloud services. 

In the context of Apple device management, it’s important to note that there are two distinct applications for SSO, which is to say two types of cloud apps: One enables end-users to log in to their cloud-based apps using their IdP credentials; the other lets IT admins log into the company’s MDM solution.

SAML and OIDC

For end-users, SSO appears seamless: They request a service, provide their credentials once, and get on with their work, accessing multiple services without interruption. But there’s a lot going on behind the scenes to make that possible. In particular, SSO requires that different systems—the service provider and the identity provider—trust each other.

Security Assertion Markup Language, or SAML (sam-el) for short, is one way they establish that trust. At a high level, you can think of SAML as a language that disparate services can use to share information about identity, authentication, and authorization, and that enables SSO.

SAML uses XML (Extensible Markup Language) to facilitate communications between an IdP and a service provider. This is accomplished with SAML assertions—XML documents that communicate information about authentication (such as when a user signs in and how they were authenticated), attributes (such as a user’s role, department, or email), or authorization (such as the approval or denial of requests). 

When a user first requests access to a service provider that uses single sign-on for authorization, that service sends a SAML request to the IdP’s SSO endpoint. The IdP validates the SAML request and presents a sign-in form to the user. The user provides their credentials, which the IdP evaluates. Assuming those credentials pass muster, the IdP sends SAML tokens to the user’s web browser, which forwards them to the service provider. The service provider checks those tokens and, if they look OK, provides access to the requested services.

But SAML is not the only way different services can establish trust. There’s also OIDC (OpenID Connect). Like SAML, OIDC redirects user requests from the service provider to the IdP, which then securely authenticates the user and authorizes them to access the service. There are differences in implementation—OIDC uses JSON web tokens (JWT), for example, instead of XML assertions—but in effect they do much the same thing.

What Single Sign-on Is Not

Sometimes you’ll see the terms “SSO” and “IdP” used interchangeably, but they don’t mean the same thing. Credentials stored with an IdP can indeed be used to authenticate with multiple web apps, as outlined above. But those same IdP credentials can be used for things that aren’t SSO per se. It’s important to keep that distinction clear.

For example, when you configure Automated Device Enrollment in Kandji, you can have users authenticate with their IdP credentials during Setup Assistant when they are setting up their device for the first time, before continuing with the enrollment process. (For more on that, see our support article Require Authentication with Automated Device Enrollment.) But they aren’t then getting access to all their web services from that first login—the system is simply allowing the user to use their existing IdP credentials for another purpose.

In a similar vein, Kandji Passport securely validates the credentials that a user provides during the first Mac login against the organization’s IdP (using OIDC to establish the necessary trust). If Passport detects that the local credentials and IdP password do not match, it will prompt the user to resync them, making the local password match the one stored with the IdP. But, again, while Passport uses IdP credentials, that isn’t SSO; it isn’t using that first Mac login to provide access to other services.

Setting up Apple Single Sign-On (SSO)

Implementing SSO in an organization is a complex undertaking that depends on several factors, and it is recommended that you consult with the IdP vendor about the specifics of your situation. But the general workflow is:

1) Choose an IdP

There are any number of identity providers to choose from, and they all provide a single place to create, store, and manage your user identities and the permissions they need in order to access company resources. 

One differentiating factor here is: Which authentication and authorization protocol(s) do they use: SAML? OpenID Connect? Active Directory? LDAP? Something else? Another factor to consider: Does the IdP support or integrate with the other services that you use? For example, can the IdP push user profiles to the service provider? 

2) Configure an Identity Provider

Once you’ve selected an IdP, you need to plan and configure your identity regime. That includes (but is not limited to) adding your users, setting up access and permissions, and specifying how users will authenticate. Will they need to use a username and password? Multifactor authentication? Some kind of passwordless workflow? Some combination of all the above? 

3) Connect your IdP and Service Providers

Once you’ve set up your IdP, you’ll need to establish a connection between the IdP and the service providers (cloud apps in particular) that you use in your environment so that end-users can leverage their IdP credentials when authenticating to those services.

4) Add Users

There are usually a number of ways to add users to your IdP. Typically, but depending on the IdP, you can do so manually, by importing them, or through Just in Time (JiT) provisioning.  

5) Assign Users

Now that the IdP is configured and users have been added, you can assign them to the resources that they need. For example, if you would like to provision Mac users JiT and use their IdP credentials to authenticate to their Mac, a tool like Kandji Passport can be integrated with your IdP to achieve this workflow. That way, the user only needs to remember one set of credentials. 

Apple has also made it possible to use IdP credentials when setting up a device for the first time. And there are tools that allow end-users to authenticate with their IdP credentials on their Mac.

How Apple Is Improving SSO

Over the years, Apple has tried to provide solutions that would unite the Mac login with IdP credentials. 

Extensible Enterprise SSO

Introduced with iOS 13, iPadOS 13, and macOS Catalina 10.15, Extensible Enterprise SSO enabled native apps to use single sign-on to authenticate users on their devices. The solution worked because, at the time, many businesses were still using on-premises, directory-based identity management, such as Active Directory. Extensible SSO allowed a user to log in to a Mac bound to Active Directory and then sign in to other apps—including web-based ones—that used Kerberos to authenticate. Because admins had control over both the service (the Mac) and the IdP (in this case, Active Directory), such integration made sense.

But as the world moved to the cloud, that model made less sense. Some cloud IdP vendors are now leveraging modern authentication protocols such as SAML and OIDC with the Extensible Enterprise SSO. Okta, for example, offers Extensible Enterprise SSO integrations with FastPass for macOS and iOS devices, providing users on managed devices with a seamless single sign-on experience.

Platform SSO

Continuing the modern authentication story in 2022, Apple announced support for Platform SSO in macOS Ventura 13. This allowed identity providers to build solutions that would allow end users to sign in to their Mac computers using their IdP credentials and enabled SSO authentication using those same credentials in native apps and Safari. 

At this year’s WWDC, Apple announced additional enhancements to Platform SSO on macOS. In macOS Sonoma, System Settings will show the status of Platform SSO, and users will have the ability to repair or reauthenticate to their IdP. Additionally, Platform SSO brings support for Just in Time local account creation when a new user authenticates to their Mac using their IdP credentials. In order for this to work, the Mac must be online, FileVault must be unlocked and at the login window, and using an MDM that supports bootstrap tokens. User permissions can be controlled from the Platform SSO configuration as well. 

About Kandji

The Kandji team is constantly working on solutions to streamline your workflow and secure your devices. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to bring your Apple fleet into the modern workplace.

Note: This article was substantially revised July 21, 2023.