Apple has introduced two big changes with macOS Catalina: Extensible Enterprise SSO (single sign-on) and Enrollment Customization. We’ll break these down throughout this guide, but for now, just know that optimizing them can create a seamless onboarding and login experience for your employees, letting them access all of their applications with one set of login credentials – all while taking a load off of IT’s back.
As you can imagine, these changes have some big implications for Mac identity management, workplace productivity, and device management, all of which we’ll explore in this guide.
Here’s a quick look at what we’ll cover:
- What’s Extensible Enterprise SSO?
- How Does it Work?
- How are SSO Extensions Deployed?
- What’s Enrollment Customization?
- Open Questions
What’s Extensible Enterprise SSO?
Apple introduced its new Extensible Enterprise single sign-on capability for iOS 13, iPadOS, and macOS Catalina. SSO is exactly what it sounds like – it’s a solution that lets users access multiple applications (both native and Safari-based) with a single set of login credentials.
Existing authentication solutions have struggled to give users secure and easy-to-use SSO functionality – but Apple’s new feature seems to have struck a powerful balance that could really streamline enterprise workflows, security, and Mac identity management. Extensible Enterprise SSO also acts as a framework for SSO extensions, which we’ll explain in depth in the next section.
We should make it clear that Extensible Enterprise SSO isn’t the same as “Sign in with Apple” – where Apple is the Identity Provider – which is intended for consumer apps and addresses a different set of problems. Extensible Enterprise SSO is a much more robust feature that has a lot of implications for the future of Apple devices in the workplace. Over the next few sections, we’ll look at the ins and outs of this new capability, discussing why it’s important, how it works, and how it’s deployed.
Why Use SSO Extensions?
Apple’s foray into SSO comes at a time when many businesses have moved from directory-based management to third-party identity management providers (IdPs), like Okta. While these IdPs work well in web browsers, they run into a couple of problems when it comes to Mac apps and password synchronization.
Let’s take a look at them here:
- Native App Limitations: While IdPs can seamlessly work with web-based apps, like Salesforce, they can’t seamlessly identify you when you open Mac apps like Jira or Dialpad. Because of this, users are not getting a true single sign-on experience.
- Password Synchronization: Compared to traditional binding with on-premise directory solutions such as Active Directory or Open Directory, IdPs and cloud directory solutions can fall short in their lack of password synchronization for local macOS accounts.
These problems lead to a fragmented experience and a very limited Mac identity management system, far from logging into your Mac once and being automatically authorized to access all of your applications. They can also become a burden for IT because a user has multiple identities and is more likely to need login support.
That’s where Apple’s new Extensible Enterprise SSO capability comes in, bypassing these problems and giving your workers a smoother login experience – one that actually only requires a single sign-on. SSO will let your workers spend less time trying to access their accounts and free up time for IT, who won’t have to respond to as many “forgot my password” requests.
This makes it possible to have a more streamlined workflow with fewer interruptions and, ultimately, more time to focus on the work that matters.
Maintaining Security with SSO
While maintaining an uninterrupted workflow is powerful in any workplace, because only one set of login credentials is needed to access all of the applications on the device, it’s important to leverage multiple factors of authentication – not just a username and password. This will enhance account security and thwart off malicious or unwanted access. Other factors of authentication include TOTP Codes, Certificates, Device Context, Fido/Hardware Keys, and more.
G Suite and Extensible Enterprise SSO
We’ve received a lot of questions about the feasibility of using the G Suite directory as an SSO provider for logging into Mac devices. The short answer is that it won’t work – at least not at the moment. In this section, we’ll break down why.
First, let’s get some background information on the G Suite directory. A directory service is essentially a database that keeps track of users and the devices and programs that they use – all in one place. This includes everything from phones and laptops to file stores, printers, applications, and everything in between.
In this regard, the G Suite directory has the basic functionality you need to manage users for Google services. IT administrators can perform expected functions like setting up domains, adding attributes to user profiles, assigning access permissions to other services that G Suite provides (like Google Drive or Hangouts), and grouping users based on their permissions.
While these features are sufficient for managing access to G Suite, advanced integration with Google’s secure LDAP service or OpenID Connect for SAML is only available to higher-priced product tiers or with the paid Google Cloud Identity add-on. These additional paid features enable IT admins to allow their users to sign in to other services with their G Suite account credentials.
Apple’s new extensible enterprise SSO framework brings the security and convenience of single sign-on from the web to native apps on macOS and iOS. When Google implements the extensible enterprise SSO for Apple platforms, your users will be able to authenticate to both web apps and native apps using their G Suite credentials. However, Apple’s SSO framework does not address the ability to create a new computer account or log in to a computer account with SSO credentials.
Instead, Apple’s preferred method is to create a local account and then leverage the SSO framework to keep the local account password and the directory service password in sync. This will be possible with G Suite as soon as Google completes integration with Apple’s framework.
In the meantime, keep an eye out for other IdPs, like Okta, which are more likely to build a login window solution that can still integrate with Google directory services on the back end.
How Does SSO Work?
Most enterprise apps and sites require authentication – which is achieved by connecting to cloud-based or on-premise resources – but as more authentication methods begin to crop up, the process has become increasingly complicated.
Organizations can use SSO to keep things simple, letting apps and websites seamlessly authenticate using a single set of login credentials. This is made possible by two types of Extensible Enterprise SSO extensions: redirect and credential. If you’ve used the Kerberos extension, you’re already familiar with a credential SSO extension, as we’ll cover later.
These extensions form Extensible Enterprise SSO framework that will let IdPs create compatible applications. Though none of them have built this into their products just yet, the framework is already there. They can also be deployed via User Enrollment.
Redirect extensions are used for modern authentication methods, such as OpenID Connect, OAuth, and SAML2. They can be used for Safari and native apps.
When used with Safari, rather than loading a login page, the OS redirects it to the SSO extension. The extension developer then completes the authentication process with the identity provider before returning the URL response to Safari.
Native apps have added functionality – they can send operations to the extensions, decide when to log in or refresh tokens silently, and act as an authentication client so enterprise app developers don’t need to include a copy of an authentication library in each app. The flow is similar to what we saw with Safari except that the native app sends a command (i.e., “Login”) to start the process. The extension is still responsible for the authentication process, and then returns a URL response along with any token needed by the app.
Credential extensions are intended for challenge/response authentication – which is a different type of flow than we saw with the redirect extension. While redirect extensions request credentials before requesting data, credential extensions request data and then get challenged for authentication.
Just like redirect, credential extensions can be used for Safari and native apps. In both cases, the flow is similar: a request is sent from an app to a web server, which returns an authentication challenge. If the host matches the profile, the OS sends a challenge to the extension, which can either handle or reject it. If handled, it returns the authorization header to complete the request, in which case the server returns the response to the caller.
There are three key differences between the two extension types:
- Credential extensions receive an authentication challenge from the server rather than a request.
- Credential extensions use a list of hosts in the MDM payload instead of URLs.
- Credential extensions do not require associated domains. (We’ll cover this later.)
As we mentioned before, the Kerberos Extension is a great example of a credential extension. Included in iOS 13, iPadOS, and macOS Catalina, Kerberos Extension is a modern replacement for Enterprise Connect, which integrates company devices with Microsoft’s Active Directory.
The Kerberos Extension was designed to manage Active Directory passwords, synchronize local and Active Directory passwords, and support authentication via username/password, MDM-provided certificate-based identity, or smartcards.
Deploying SSO Extensions in an Enterprise
Now that we know the basics of redirect and credential SSO extensions, let’s take a look at how they can be deployed in an enterprise setting.
Redirect Extension Deployment
Although no public redirect extensions exist today, the process of deploying a redirect extension would consist of the following (and in the meantime, please encourage your identity provider to develop their own SSO extension):
To deploy a redirect extension, you’ll need two things: an MDM payload and associated domains. The payload must be delivered using your MDM (Mobile Device Management) solution, and it’s redirect configuration includes:
- Team identifiers and extension bundle identifiers for the identity providers extension.
- Extension type (in this case, “redirect”).
- List of URL prefixes (determining which traffic to route to the extension).
- Dictionary of extension values from the MDM (optional).
The second requirement, associated domains, are used to ensure that you own the traffic being redirected. On Apple platforms, you can set up associated domains by configuring them in the host app that contains your extensions. You can learn more about this in the Apple documentation here.
Associated domains also require that the host app ID appears in the Apple App Site Association File on the server. Finally, you need to add the MDM managed entitlement and have an associated domain array to let the OS know to use the MDM value.
Credential Extension Deployment
To deploy the credential extension, associated domains are not necessary. However, you still need to deliver the credential payload using your MDM solution. This payload is similar to the one we described for redirect, but there are two differences.
- In the type section, “Credential” is used instead of “Redirect.”
- In the key section, a list of hosts is used for selection. This list is checked against the hostname of the server. Any MDM value that begins with a period is used to match the suffix of the hostname. If it doesn’t begin with a period, the entire hostname is matched.
When using Apple Business Manager and an MDM solution, like Kandji, Apple’s new Enrollment Customization feature lets IT provide custom branding, consent text, and modern authentication to their teams during enrollment.
These customized web pages appear during Setup Assistant and can be used to display an SSO provider to authenticate the user – such as a form or anything else that can be displayed on a webpage – so new employees are required to sign in with their SSO credentials to set up a new Mac.
This would be great for IT since they’ll know:
- Who signed into the device during Setup Assistant
- Who the device is assigned to
However, it’s important to know that signing into SSO using Enrollment Customization will not bind your Mac login to your SSO login. This broken bind/association remains a challenge for Mac identity management, but it is also where SSO extensions are taking steps toward a solution.
While Apple’s new Extensible Enterprise SSO capability has a lot of promise, there are still a few unanswered questions about its functionality. We’ll look at a couple of them here:
- How do Managed Apple IDs fit in? At the Worldwide Developers Conference (WWDC), Apple said that the new SSO extensions don’t support Managed Apple IDs. Understanding how Extensible Enterprise SSO will interact with Managed Apple IDs could give us a fuller picture of the nature of SSO in the workspace. You can read our guide to Managed Apple IDs for more information.
- What best practices should IT follow given the broken bind/association problem? In light of the broken bind/association problem between the Mac and SSO login, it’s important to know how IT should respond – and how their response might change in the future. We recommend reaching out to your IdP provider about building support for Apple’s new Extensible Enterprise SSO framework. This could create a more seamless Mac identity management experience in the years to come.
There’s a lot to be excited about with Apple’s announcement of Extensible Enterprise SSO, but there are still some questions that need to be answered before its implications are clear. Regardless, achieving true single sign-on at the enterprise level will save a lot of time and hassle, and Enrollment Customization will give businesses the ability to tailor a Setup Assistant screen to meet their enrollment needs.
Enrollment Customization also paves the way for new opportunities for MDM solutions, like our product Kandji. 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.