The goal is straightforward. You’d like a system that would 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 holy grail of identity management for a couple of decades now, and several 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 to which end-users want 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 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.
SAML 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 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, 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 via SSO on their first login, 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 using the 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 are out of sync with those stored with the IdP, it will prompt the user to resync them. 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.
Extensible Enterprise SSO
Some years ago, Apple tried to provide a solution that would unite the Mac login with IdP credentials, in the form of something called 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.
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.
This article was substantially revised February 11, 2022.