Leverage enterprise identity and authentication

Hello and welcome to WWDC.

Hi. My name is Mike Boylan and I'm a senior consulting engineer supporting enterprise and education. I'm excited to be here with you today alongside my colleague Sudhakar to discuss enterprise identity and authentication. Apple's focus on security extends beyond just our software, hardware and services. For organizations that deploy Apple devices at any scale, identity has become the centerpiece of how users authenticate to devices, Web sites, apps and services. And it's a critical part of ensuring security across our platform. It's no surprise that identity and authentication have been getting more and more complicated. All enterprise apps or Web sites need to authenticate a user in order to function. These apps connect to systems of record either in the cloud, on premise, or both. So how do organizations deal with these challenges? To help with what's out there, Apple has built a number of tools and technologies that streamline how organizations can leverage identity across devices, Web sites, apps and services. We view identity as something that needs to be tightly integrated into our operating systems in order to provide a seamless, nearly invisible experience for our users. This empowers users to work from anywhere while giving IT the visibility and control that they need to feel comfortable enabling that.

This session will focus on three different technologies and how they can be used together in practice, along with what's new this year. We'll cover device authentication and macOS account types, single sign-on extensions, and Managed Apple IDs and federated authentication.

Let's start by talking about device authentication. Identity on our devices often starts at the lock or log-in screen. Here's an example of a Shared iPad and a shared Mac where users can select their account, enter their credentials, and see this personalized experience. On iPadOS, this is enabled by Managed Apple ID, and on macOS, accounts can be local, or come from the network.

On this Mac, we can see identity playing a role even during the initial deployment process when a device is getting assigned to one specific user. Last year, we added a new feature called enrollment customization which allows a web page, like you see here, to load during setup, and can allow for a user to authenticate using modern authentication methods. User information from the authentication process can then be used to pre-populate the local account name and short name for the user in the macOS setup assistant, optionally locking them into place. So that assumes the user is using a local account. On the Mac, there are two primary types of accounts: local accounts and network, or mobile, accounts. Mobile accounts are a specific type of network account. Depending on different deployment scenarios over the years, organizations have used either type of these accounts, or sometimes both depending on use case. Mobile accounts and network accounts are where organizational identity first started on the Mac, years before mobile devices like iPhone and iPad were around or as prevalent as they are today. They existed primarily to help with shared devices in settings like computer labs, but they make much less sense to be used today, especially in 1:1 deployment scenarios. Using local accounts on macOS is our recommendation whenever possible for 1:1 deployments. The user record is stored locally on the Mac, and the source of truth for the authentication is the local macOS directory services. This helps ensure that there are no unnecessary log-in delays, and password management happens locally on the Mac. Now, we get a lot of questions about when to bind a Mac to a directory service and when not to do so, especially for 1:1 deployments. So for organizations who have traditionally bound their Macs to Active Directory or another directory service for 1:1 deployments, they should consider not binding the machines. Instead, consider using the built-in Kerberos extension, other SSO extensions, or additional third-party value-adds often provided by MDM vendors to provide directory connectivity. We'll discuss the built-in Kerberos extension and SSO extensions more later in this session.

Using the built-in Kerberos extension with on-premise Active Directory environments allows the user to obtain a Kerberos ticket-granting ticket, otherwise known as TGT, and access directory resources like file servers and printers. The extension can also help keep the user's password in sync with what is in the directory, and can help ensure when changing their password, that the new password meets the organizational complexity requirements.

Note that to traverse Active Directory DFS, or Distributed File System, or to be able to acquire an Active Directory machine certificate using the AD Certificate payload delivered via MDM, the Mac itself does need to be bound to Active Directory. However, just because the Mac itself is bound and has an AD machine record does not mean that the user needs to use a domain account to log in to the Mac. Ideally, a local account, as was just described, would be used instead. Local accounts offer the best, most reliable experience on macOS, and we recommend that they be used whenever possible. Another type of account is a network account. With these accounts, the source of truth for authentication is a directory server. Home folders are optionally on a network volume, and when logged in to macOS, the contents of the home folder can be accessed directly over the network. Modern apps, file sizes and file types including the fact that many applications now use databases for storing content, and the inherent concept of mobility present immense challenges for network accounts and network home folders. We really view accounts of this type as legacy and do not recommend their use. However, they're not deprecated and can be used if absolutely necessary.

We recommend using local accounts whenever possible, and if absolutely needed, at least consider mobile accounts, which we'll discuss next.

Mobile accounts are a type of network account and are far more commonly used than true network accounts. The source of truth for authentication is still a directory server, but the credentials are also cached locally. A home folder is also created locally on the Mac. The locally cached credentials and the local home folder helps ensure a user can use their Mac even if the directory server is unavailable. However, because the source of truth for the user's authentication is the directory server, there can be log-in delays that exist as a result of trying to access the directory server. This can happen for a variety of reasons, but most often, it's a result of a DNS misconfiguration or unexpected redirect-- for example, on a public Wi-Fi network.

Additional complexities also exist in synchronizing the password, as the password can be changed externally and then needs to be updated on the Mac. This is especially true when using FileVault.

Mobile accounts are supported in macOS for 1:1 deployments, but are not recommended.

For shared lab environments, however, mobile accounts are often appropriate to use, and they can even be configured to expire after a certain period of time if desired.

So that's a recap of device authentication, and how we manage different types of accounts and authentication between shared and individual devices, both during and after deployment. Now let's talk about single sign-on extensions.

As a quick recap, SSO extensions were introduced last year in iPadOS, iOS 13 and macOS Catalina. They enable native apps and WebKit to provide a more seamless single sign-on experience. We use an SSO extension internally for our own single sign-on against our own identity management system, and we've seen large identity providers like Microsoft and Okta bring offerings to market as well.

SSO extensions allow organizations to leverage existing credentials. They're configured via Mobile Device Management, or MDM, for short, and can provide a native UI, Web UI, or a totally transparent authentication experience to the user.

Here's a graphic depicting how both Safari and WebKit as well as native apps can call into a single sign-on extension to authenticate against an organization's identity provider.

This year, we're introducing a number of new features and enhancements to SSO extensions. First is the ability to configure SSO extensions on the user channel on both macOS and iPadOS with Shared iPad.

We've improved the way that SSO extensions interact with per-app VPN configurations.

We've added the ability for SSO extension apps to include wild cards in the list of matching URLs that are embedded inside of the app.

We now provide additional information to the extension about the calling app that's requesting authentication.

And when the MDM profile that configures an extension is removed, there is now an operation that is called to allow for any cleanup tasks needed by the extension. And finally, we've made some great enhancements to our first-party built-in Kerberos extension. Let's take a deeper look at all of these changes, starting with user-channel profile delivery.

This year, we're introducing the ability to configure SSO extensions on the user channel on both macOS and iPadOS with Shared iPad. This will allow MDM developers to more easily integrate configurations of SSO extensions into their products. This feature is enabled for all SSO extensions. Settings configured on the user channel take priority over any settings configured at the system level.

This improvement will also allow for easier per-user settings for SSO, such as setting the user name.

We've also significantly improved how an SSO extensions work with per-app VPN. New this year, associated domains now work with per-app VPN.

As a result, SSO redirect extensions can now redirect traffic for identity providers that are on-premise. The on-premise IdPs have the same certificate restrictions as Internet-based IdPs, meaning that the certificate needs to be issued by a pre-installed, system-trusted CA.

To use this feature, you will need to add the associated domains to your per-app VPN payload and enable the new direct downloads feature for the domains via the Managed App attribute on iOS or the Managed Associated Domains payload on macOS. We'll recap associated domains and discuss some changes to them shortly.

Let's look at how the extension can use per-app VPN for on-premise identity providers. When the app is installed, the OS will request the site association file through the per-app VPN when the associated domains are present. A native app can send an operation to an extension, such as "Login".

That request then goes through the per-app VPN to the on-premise network to the on-premise identity provider.

The response then goes back to the extension, still through the per-app VPN. And then the response and tokens are sent back to the native app SSO Extensions inherit the per-app VPN settings of their host app. If the host app is assigned a per-app VPN, then all of the host and extension traffic will use the per-app VPN. This can impact performance of the extension because all of the traffic has to be routed through the VPN, even though some resources may be in the cloud. New this year, you can use the "per-app VPN Excluded Domains list" to allow your cloud IdP traffic go do direct from the device to the IdP to take advantage of load balancing and regional instances. This is useful when an app needs simultaneous access to both trusted cloud and on-premise resources. The exclusion list is global for the device. Previously, to connect to a cloud resource, an SSO Extension or app had to send the traffic through the per-app VPN to the on-premise network. Then it would be routed to the Internet from there. This can be inefficient and can reduce the advantage of global CDN or regional load balancing for Internet resources.

Now you can connect directly to trusted Internet resources using excluded domains. So here, you can see the SSO extension sending some traffic through the per-app VPN to the on-premise network. But now, using the excluded domains list, the extension can also send traffic directly to trusted cloud resources for the domains you specify. Also new this year, we'll also trigger per-app VPN for auth-only requests such as a log-in event or a password change. It no longer requires a separate http or similar request to trigger the VPN. And this applies to all platforms.

For a quick recap of associated domains, we introduced these last year to go alongside SSO extensions. On iOS, these are configured via the Managed App configuration alongside the app providing the SSO extension, and on macOS, they're installed via the separate managed associated domains configuration payload from MDM.

When used with SSO extensions, these allow identity providers that have different host names per tenant to specify the hosts for a customer via MDM rather than trying to add every customer into the app's embedded set of URLs before submitting the app to the App Store. To have an app be able to be used together with associated domains, it requires an entitlement. The entitlement allows MDM to supplement the associated domains that are included with the app. New this year is that com.apple.developer.associated-domains.mdm -managed entitlement is now public and no longer requires approval from Developer Technical Support.

Associated domains included in inside of an application must be paired with an Apple App Site Association file on the related Web site.

This file contains app IDs and app keys specifying the application identifiers for the apps that are available for use on the Web site and with the given service type.

New this year is that the Apple App Site Association file is no longer directly accessed by the device itself by default.

Instead, the file is accessed by an Apple-operated content delivery network that's dedicated to associated domains. This reduces load on servers and routes devices to a known-good, known-fast connection.

For managed devices where an app may have an associated domain that's not available on the public Internet for Apple's CDN to access, an additional parameter can be added to the domain inside of the app to specify that it is a domain for a managed app on a managed device.

For more information, see this related session from this year's WWDC. This year, we're providing more information about the app that is trying to use an SSO extension. Specifically, we added the Calling App Name, which is localized, the Calling App Team Identifier, and an Is-Caller-Managed flag. SSO extensions can use this information to both improve the user experience by providing a more user-friendly name of the app to the user, and they can also use the Team Identifier and the "is managed" flag to make more informed security decisions about the calling app.

Now, to operations. We included some standard operations last year for typical uses of the extensions, including log-in, refresh, and log-out. Developers should have already adopted these in their extensions.

This year we added a new configuration-Removed operation. This operation will be called when the profile configuring an SSO extension is removed from the device. This will give extension developers a short window of time to log out, clean up files or Keychain entries, revoke tokens, or perform other cleanup actions as necessary. Using this feature requires the SSO extension be built with the iOS 14 or macOS Big Sur SDK.

We've added the ability for SSO extension developers to include embedded wild cards in the list of matching URLs for which their extension is used. This allows for a much easier setup for large identity providers that use a common URL scheme with slightly different URLs to identify specific customers or tenants. So, for example, if an identities provider log-in URL is auth.pretendco.com/CUSTOMER NAME/login, they could include auth.pretendco.com/*/login in their embedded list of URLs. This is different from an associated domain where the entire domain may be different.

These embedded wild card URLs work together with associated domains and aren't meant to replace them. This improvement is focused on extension developers being able to more easily match a large number of customers when the URLs are similar and often the host names themselves are the same. Also new this year is a number of improvements to our built-in Kerberos extension. First, the menu extra on macOS now more accurately represents the state of the extension. The extension requires a credential, an active network connection, functioning DNS, and an unexpired Kerberos ticket to work correctly.

The menu extra will show solid if all of these are in place, or now, when something is missing, it will indicate to the user what the problem is. We realize not all organizations use the same names for their identities. Some call it the Associate ID, some call it their AD Account, or even the PretendCo ID, where PretendCo is the name of the organization.

This year, we're adding the ability to customize the label that is shown in the Kerberos extension so that it can match the name of your identity in your organization. You can also now add help text to let your users know where they can get help if they have trouble logging in. This text is shown at the bottom of the sign-in window.

So, here's an example of the identity name being customized alongside the custom help text.

Here are a few examples of the menu extra showing different states to the user. For example, on the left, the user is not signed in, and there is no network available. In the middle, they are signed in, but now the network is not available. And on the right, the user is signed in, and both the network and credential are available, and notice that the key icon is solid in the menu bar.

The extension will now trigger per-app VPN for an authentication-only requests on iOS, iPadOS and macOS. This will enable you to log in without having a separate network request or manually triggering the VPN. The Kerberos extension also now fully supports app-to-per-app VPN on macOS. You'll need to add the App-SSO-Agent and the Kerberos-Menu-Extra to the app-to-per-app VPN payload. We discussed user channel profile delivery being supported earlier for all SSO extensions, and this includes the built-in Kerberos extension. A large driver for the development of this feature was the request to be able to more easily reference user-level certificate identities delivered via MDM and to use them for certificate-based Kerberos or PKINIT.

It's important to mention that referencing a user-level certificate identity in a system-level scoped profile has always been supported in the context of configuring the Kerberos extension, but this improvement will make it significantly easier for MDM vendors to bundle the configurations and the certificates together. We're also providing more control for administrators regarding when a user is prompted to log in to the extension for the first time on macOS. For example, previously, the app SSO agent would listen for network state changes and prompt for credentials. Using this new option will delay the first log-in prompt until an administrator runs a command to enable it or the first authentication challenge is received.

We've also added an optional Managed App Access Control on iOS. If set, if the source app trying to access the credential is unmanaged, then it won't be able to do so. So that's a recap of single-sign-on extensions and the built-in Kerberos extension. Now I'd like to turn it over to Sudhakar to talk about Managed Apple IDs. Thanks, Mike. Hi. I am Sudhakar Mambakkam. I'm a senior engineering manager in Apple's Identity Management team.

Today, I'll be talking about Managed Apple IDs and federated authentication. The features I cover today are applicable to both Apple Business Manager and Apple School Manager. To keep it simple, I may refer only to Apple Business Manager at times. If there are actual feature differences, I will call those out specifically.

Let's start with what Managed Apple IDs are. They are Apple user accounts owned and managed by an organization.

Account management tasks such as creation, deletion and password management are done by IT administrators or automated systems for these accounts.

Managed Apple IDs are used to personalize a device and to access Apple applications and services. Certain applications can be tailored for their use, and other applications are available only for Managed Apple IDs.

IT teams use them to sign into Apple Business Manager for carrying out tasks such as device management and app purchase for their organization.

Features such as User Enrollment and Shared iPad are available for use only with Managed Apple IDs.

Managed Apple IDs for education support features such as Schoolwork and come with 200 GB free iCloud storage.

Most importantly, Managed Apple IDs have the capability for federated authentication. Let's see what that is and why it's important for enterprise identity.

Federated authentication is a simple and secure identity management architecture that spans organization boundaries.

It allows organizations in Apple Business Manager to connect to their existing identity systems based on Microsoft Azure Active Directory. This automatically sets up users with access to Apple Services.

No new sign-in credential is created, and Apple Services can be accessed using the same credentials a user would use normally within the organization for other applications.

This is the core objective of the federation feature, where organizations can determine the authentication policy for their users.

When a user signs in to an Apple device for the first time using federated authentication, the Managed Apple ID needed to access the Apple service is created automatically.

Federated authentication reduces account-related overheads for both IT teams and end users. It ensures that identity policies are consistently enforced across all applications and services used within the organization.

Now, let us see how federated authentication works.

First, federation needs to be set up between Azure Active Directory and Apple. This is done using Apple Business Manager or Apple School Manager.

Once federation is set up, organization users can access all Apple applications using their organization sign-in credentials.

Federation is configured for each domain individually. In this example, the domain acme.com has been set up for federation.

After this, when a user in the acme.com domain attempts to access an Apple service, Apple will recognize the user as federated and redirect their device to Azure AD for authentication.

After the user authenticates in Azure AD, the device will be redirected back to Apple with an authentication token.

The federation protocol used here is SAML, and the authentication token is the SAML response signed by Azure AD.

Apple will verify the token signature using information exchanged during the setup process and will allow the user to access the service.

Federated authentication works even if the identity system is not natively on Azure AD but is behind it on another system such as on-premise ADFS or another identity provider. Azure AD's integration with the other identity provider is transparent to the Apple service which still receives the authentication token via Azure AD.

Let's go over the details of the setup process. Setting up federation requires the user to have administration capability, both within Apple Business Manager and in Azure Active Directory.

Let's assume you are an administrator in both these systems for your organization and walk through the process step by step.

As federation is set up by domain, if your organization has multiple domains, you need to decide which of these domains to federate.

You get the most benefit when you federate all domains that have users who will be accessing Apple Services.

Domain verification is a new feature introduced this year in Apple Business Manager and Apple School Manager. Domains that are used to create Managed Apple IDs need to undergo ownership verification.

Let's start with that process. Enter the domain you want to federate and select "continue." The domain will be saved in an unverified state, and you can start the verification process now.

The domain verification feature uses a standard DNS TXT record-based verification method. Use the "verify" button to generate a verification code.

Then, create a TXT record in your domain using this code. The code is valid for 14 days from the time of generation, and you need to complete the process within this period. After updating the DNS record, you can trigger a DNS check manually or let the scheduled process do it automatically. Either way, keep in mind that DNS record propagation may take a few hours after you update it.

Once the TXT record is visible to Apple Business Manager, it will be checked against the code originally generated for the domain. If it matches, the domain is marked as verified and it's available for federation now.

Start the federation process using the "connect" button under "federated authentication." Sign into Azure AD as an administrator. This can be a user with one of the following roles: a global administrator, an application administrator or a cloud application administrator.

Approve the integration between Azure AD and Apple Business Manager. This allows your users to sign in to Apple Services with their Azure AD credentials. It also allows Azure AD to share user information, such as an employee's e-mail address and name, with Apple. This step is needed only once for an organization.

Read the agreement and accept it.

Once you have granted permission, sign in as a user belonging to the domain you are federating. This is a test sign-in that validates that the permission grant was successful and confirms that users can now use their Azure AD credentials to sign in to Apple Services.

If you federate a second domain later on, you will directly go to this step, as the permission for integration has already been granted.

Next, Apple will scan its database for username conflicts. These are existing accounts with usernames from your domain.

You will not be able to create new Managed Apple IDs with usernames that already exist in Apple ID database.

So there is a resolution process to remove these conflicts. Apple will notify users to select a new username in a different domain. After 60 days, any remaining usernames will be automatically updated to a temporary domain by Apple. Once that is done, you can create Managed Apple IDs with any username in the domain you are federating.

Even if there are conflicts, you do not have to wait 60 days to enable federation. Once the scan is complete and you have the conflict results, you can go ahead and enable federation anytime. Users without username conflicts can then use Apple Services with their organization credentials right away.

Let's do a quick recap on the steps needed to enable federation.

First, verify your domain. Then sign in as an administrator and provide consent.

Then sign in as a user in the domain.

Review username conflicts and initiate resolution steps if required.

Then turn federation on.

Federated authentication removes many of the account management challenges, particularly the hardest one of credential management.

But there are still a few important ones that need to be addressed.

What happens when a user leaves the organization? Their access must be revoked in a timely manner to meet security and regulatory needs.

Of course, with federation, the user will not be able to sign in after they leave, but what about the devices and applications they are already signed into? How can we ensure that those sessions are terminated? Over the life of an account, information such as the department a user works in or even their name, can change. What is the best way to ensure that the user's profile information is consistent across all services? Creating the Managed Apple ID automatically at the time of sign-in works for most users. But what if there are certain service-specific permissions required for a user? How do we avoid the manual work needed to pre-create the account so that permissions can be granted up-front? SCIM is a standard solution that addresses all these problems. We are very happy to share that we are introducing SCIM integration with Azure Active Directory later this year.

This integration will be available in both Apple Business Manager and Apple School Manager.

Let's see what SCIM is and how it will help.

SCIM is an automated process for exchanging information between an identity provider and a service provider. It allows the synchronization of account data between Azure AD and Apple.

It's a standards-based data exchange covering the full life cycle of the account. So account creations, modifications and deletions, all can be synchronized. It will be available for all federated organizations in Apple Business Manager and Apple School Manager. Education organizations that already have a process for importing account information into Apple School Manager via the SIS or SFTP process will now have SCIM as another option. Let's look at an overview of the SCIM process. Once a SCIM connection is set up for your organization, Azure AD monitors your user directory for changes and automatically publishes these changes to Apple Business Manager.

Over a period of time, users may be added.

Some users' profiles may be updated, and some other users may be deleted.

Azure AD monitors for these changes and, using the SCIM interface, identifies the changes to be sent to Apple Business Manager.

Apple Business Manager consumes this data and applies it to its database, synchronizing it with Azure AD.

By keeping the two repositories in sync, SCIM enhances the security and usability of the federated architecture.

Now let's go over the SCIM setup process.

Similar to federated authentication, SCIM configuration also requires you to be an administrator in both Apple Business Manager and Azure AD.

Apple Business Manager will now have a new data source option to configure SCIM.

Apple School Manager already supports data source configuration for SIS and SFTP. It will now offer SCIM as an alternative option.

Select "connect" to start the configuration process.

This will generate a SCIM token that you need to upload to Azure Active Directory. Copy this token for later use. Once generated, the SCIM token must be used within four days, after which it will expire.

After you generate the token, a tenant URL will also be displayed in the user interface. Note the tenant URL, too, as both the token and the URL are needed for Azure AD configuration.

Sign into Azure AD as an administrator. Navigate to Enterprise Applications section and find the Apple Business Manager application.

Go to the Provisioning section for this application and enter the information you obtained from Apple Business Manager.

You can also choose to synchronize data for all users in your directory, or you can choose to synchronize data for just the subset of users you assign to Apple Business Manager.

Make your selection and click "save." Azure AD will automatically test the connection and start data synchronization.

You can verify the SCIM status in Apple Business Manager using the Activity sidebar. You can see the connection status and the count of accounts imported via SCIM. You can also see SCIM as a data source on the label on accounts that have been synchronized via the SCIM interface. From now on, account information will be automatically synchronized between Azure AD and Apple Business Manager.

Together, federation and SCIM will greatly simplify your account management processes and we are very excited to make SCIM integration available to you. Managed Apple IDs allow you to use Apple Services in a way that is tailored to your needs.

Federated authentication and SCIM automate and simplify identity management processes, provide a seamless experience to your users, and help you get the most value out of Apple Services. I'll now hand it back to Mike.

Thanks, Sudhakar. I'd like to briefly focus in a bit more on federation and SSO.

These are complementary technologies within our ecosystem. Identity providers support SSO extensions. As I mentioned in the beginning of the session, we've seen several large providers like Microsoft and Okta bring SSO extensions to market already. SSO extensions allow non-Apple applications and Web sites to use them to directly integrate with the identity provider for the SSO experience. On the other hand, Apple apps and services work only with Managed Apple IDs, meaning they do not use SSO extensions to integrate with your identity provider directly. Instead, they integrate with Apple for authentication, which can then use federation with Microsoft Azure Active Directory.

Whether Microsoft Azure Active Directory is the actual backing identity provider is up to you. As Sudhakar described earlier, Azure Active Directory also supports federating with other identity providers. So while Apple Business Manager needs to talk to Azure Active Directory, the backing source for the identities could be another identity provider.

I'd like to wrap up by summarizing what we discussed today and provide some calls to action.

Use local accounts on macOS whenever possible for 1:1 deployments and enable directory connectivity via the built-in Kerberos extension, other SSO extensions, or additional third-party value adds often provided by MDM vendors. Mobile accounts are supported in macOS but are not recommended for 1:1 deployments. For shared lab environments, mobile accounts are often appropriate to use, and they can even be configured to expire after a certain period of time if desired. This year we've brought a number of new improvements to SSO extensions and the built-in system Kerberos extension. We encourage you take advantage of these improvements to allow for an even better single-sign-on experience for your users. Use Managed Apple IDs in your institution, as they're purpose-built for enterprise and education. They are created and managed by your organization, built for data privacy, and provide access to Apple Services.

Verify domains in Apple School Manager and Apple Business Manager to enable the use of federation for easy account creation backed by an existing Microsoft Azure Active Directory credential.

SCIM support is new and will be launching in Apple School Manager and Apple Business Manager later this year. It provides a data feed directly from Microsoft Azure Active Directory back to Apple to help with account creation, modifications and deletions.

Please be sure to explore all the other WWDC 2020 Enterprise sessions which are dedicated to IT professionals. And also, look in this session's resources for last year's tech talk providing a deep dive on extensible SSO. Thank you, and we hope you enjoy all of the great content that WWDC 2020 has to offer.