What’s New in Managing Apple Devices

Guys! Guys! I just got is a meeting with Vivian. What? How? I just bumped into her.

And what, you just asked for a meeting? Yeah. Is anything I can do? Actually -- When? Just now. No, when's the meeting? Oh, Thursday, 8 a.m. Next Thursday? Yes.

No, this Thursday. What? That's impossible. We can do this. Okay, Round Box is back. It's just a sketch. That's all we have. Two days? We need two weeks. This is how we get off this floor. Dave, can you get the sales figures on pizza boxes? I feel sick.

It's so simple. Round pizza, round box. Perfect. Hey, who's hungry. We have to prove what's wrong with pizza boxes. They're square. Waste of space. Yeah. Do I really have to go see Mike in finance? Yep.

Hey, Mike, I was wondering if you could send the -- Shh, inbox.

We have this idea. I need some sort of 3D prototype. I've got to pick up the kids. I just want to get you all together. We need to find a name for the box. Roundabout. A Quircle? Circle Box? Who's that? Hey, Siri, turn on Do Not Disturb.

Brian? Brian! I'm awake. Hey, Siri, tell Bridget I'm running late. No, no, no. This is wrong. This is all wrong. Dave, can you please double-check those figures for us? Did anyone hear from Adam Warehouse. He's putting together the prototype now. What do you guys want to hit on? Nothing.

Nothing.

Move that over there. Make that title bigger. Do a dash. Guys! We're almost there. I don't know if it works. I mean, I don't even -- What are you doing, Bud? Hey, can I have that back? No! I'll email you the video. Just AirDrop it to me. Sweet! You guys, I just got the prototype. Whoa. This is going to look so good in the presentation. Awesome.

Wow! Jump up! I'm awake. Agh! It's time. Did anyone press the button? We did it. We made a round pizza box. Never let it be said that Apple does not take the enterprise very seriously.

Good morning and welcome to Session 303, What's New in Managing Apple Devices. I'm Todd Fernandez. I manage Apple's Device Management Engineering Teams. I'm very happy to be here with you this morning.

Now that video's a lot of fun, but now I'd like to turn to the more serious considerations that we keep in mind while building the tools needed to bring all of those Apple devices into organizations like that fictional company, your company, or a school. We've been working hard to fill our goal of enabling you to manage all of your Apple devices with the same tools and technologies, empowering your users and your organizations to choose the best devices for them, because your users care a lot about the privacy of their personal information, and your organizations care a lot about the security of their intellectual property.

Apple cares deeply about both privacy and security, as well as mitigating the impacts they can sometimes have on the manageability of Apple devices.

We strive to strike the right balance between these values, which can sometimes come into conflict as we add new device management capabilities.

Because we want our devices to fit well into your organization's diverse ecosystem of devices, allowing you to continue using the services you already use, while also taking full advantage of the Apple services that make them stand out.

So, let's begin our tour with an update on Apple School Manager and Apple Business Manager, or as they're known to their friends, ABM and ASM. Now these tools, of course, are how you manage all of your Apple devices, accounts, and apps and books.

And speaking of apps, the custom apps feature, formally known as BW apps, was expanded earlier this spring to allow organizations to distribute those apps to their own employees, as well as other companies.

And this fall, we're bringing custom apps to ASM, as well. Speaking -- yes, thank you. And speaking of accounts, earlier this spring, we added Federated authentication with Microsoft Azure Active Directory to ASM, and this fall, we're bringing that feature to ABM. I am -- okay. I love you guys. This is a great audience.

I'm also very pleased to announce that as of this week, both ABM and ASM are now fully supported on iPad on the shipping iOS. We love iPad, too.

Again, making sure that you can use these services and apps on all of our platforms.

In fact, ABM and ASM have been so successful that we are ending support for their predecessor, Apple Deployment Programs, at the end of this year. It's time to get on board with ABM and ASM.

Because, in fact, you're getting even more benefits now with the same Managed Apple ID you use to sign in to ABM and ASM, you get access to the AppleSeed for IT, so that you can get all of the new beta software releases, like everything we seeded this week, including documentation and test plans, to help you ensure that those new software releases will work well in your organization, and when you find some things you don't particularly like, use Feedback Assistant built into all of our OSs now to file suggestions to us, so that we can associate those with your organization and more accurately track them in engineering. That concludes our update on ABM and ASM, and now I'd like to turn to another great example of how we provide you with the same tools on every platform and allow you to choose the best devices for you. And that's Classroom.

In March, we released the latest update to Classroom for iPad and Mac, but now it enables teachers to manage student Macs with the same great feature set that they've grown to love while managing student iPads. On the left, you can see that students can manage their classes with a new classroom pane in system preferences, just like they do in settings on iPad. And we also brought all of the settings that configure certain classroom behaviors that you have on iOS back to macOS, including the ones that control Classroom's Screensview feature. But we didn't stop there. We also made all of the other screen viewing features that you know and love in macOS from screen sharing, screenshot, and Apple Note desktop respect those restrictions, as well. Earlier this week, we seeded our fall release of Classroom, which of course, support Dark Mode on iOS 13. And we've and a great new feature that will help teachers regain student attention without needing to lock the device, we call it Hide Apps, and it works like this. When the teacher taps the new Hide button in the toolbar, the student is returned to home screen on their iPad.

That concludes our Classroom update. Now I'd like to turn to a couple of other announcements that impact device management.

We all saw on Monday the announcement of desktop-class browsing on iPad.

This may impact your MDM product if you are using the UserAgent string to distinguish between iPad and Mac to customize your UI or your enrollment flow. You're going to need to stop doing that, because iPad now identifies as Mac.

For more about this great new feature for iPad, check out the session from earlier this week. We've also brought a number of great device management features custom to on iOS and macOS to AppleTV, we now allow organizations to control when software updates appear in the tvOS UI and allow you to configure date and time automatically.

Hopefully, you're all using content caching in your organization, and now tvOS screensavers are also cashed, saving you a lot of bandwidth.

That concludes our first section of content, and now I'd like to turn to some features that help us strike that right balance between security, privacy, and manageability. And the first one is a really big deal that Craig highlighted in the keynote on Monday, I'd like to ask Bob Whiteman to come on stage and tell you all about user enrollment.

Hi, I'm Bob Whiteman, Senior Device Management Engineer at Apple. Until now, there have been two ways to manage iOS devices. Device enrollments provide many device-wide management capabilities, and for institutionally owned devices that are supervised, automated device enrollment provides all of the device management capabilities as well as automated set up.

When users bring their personal devices to work or school, they don't really want the admin to manage the entire device, and BYOD admins don't really want to manage the entire device either. They just want to provide the apps, data, and configuration that users need in order to be productive. Today, I'm presenting a new way to manage BYOD devices called User Enrollments.

This is a new MDM enrollment option that provides a better balance for BYOD. It protects the privacy of personal data, while still securing corporate data.

When users and admins achieve this better balance, there is greater acceptance of BYOD programs, and more productive users. Everyone wins.

User enrollments are built on three pillars. The first is a Managed Apple ID, alongside the Personal Apple ID. The second is cryptographic separation of personal and work data, and the third is a limited set of device-wide management capabilities. A Managed Apple ID is required for user enrollment. This is the anchor for the user's work identity on the device. Now this is not a multiuser system. It's a multi- persona system. It's the same user wearing different hats.

The admin creates the Managed Apple ID in Apple School Manager or Apple Business Manager, and the user must sign into the Managed Apple ID during the enrollment process.

Federated off means that this works very well for the user, since they are challenged for credentials that they already know from the organization. And when the enrollment ends, the Managed Apple ID is removed from the device. Managed Apps and Accounts use the Managed Apple ID's iCloud account and Personal Apps and Accounts use the personal Apple ID's iCloud account, if there is one signed in.

Third-party apps are always entirely either managed or unmanaged. They can't change mode, and you can't run them in both modes at the same time.

Some of the built-in apps like Notes, our account based, which means they can handle both managed accounts and unmanaged accounts, and these apps will use the appropriate Apple ID, depending on which account they are operating on at the time. The next pillar is data separation. When the enrollment starts, iOS creates a managed APFS volume, and it uses separate cryptographic keys for this. When enrollment ends, iOS destroys the cryptographic keys and the volume. So, the data is gone. Now it's always been the case that iOS removes managed data when enrollment ends appropriately. So, this is a cryptographic backstop to make sure that the data is provably gone, just in case something goes wrong during the unenrollment process.

The managed APFS volume contains the managed versions of all of these items. App containers are any local data stored by third-party apps.

The Notes app stores local data for managed Notes accounts on the managed APFS volume and for personal notes accounts on the personal or system APFS volume.

When iOS creates this managed APFS volume, it also creates a managed keychain. This stores any secure items that are saved by third-party apps like passwords and certificates, and it also stores the authentication credentials for managed accounts.

Mail attachments and full email bodies are stored on the managed APFS partition, although there is a central database for mail that lives on the system partition that contains some metadata and five-line previews. Rest assured, this data is removed when the enrollment ends.

Once the data is separated, the management of this data must be separated, as well. User enrollments have a few limited capabilities for managing the entire device, but they have no capabilities for managing personal apps and data.

User enrollment management is based upon a modified version of the MDM protocol. And it starts the same way as device enrollments, with the enrollment profile. The Managed Apple ID key is what signifies this as a user enrollment. And the value of this is the user name of the managed Apple ID that the user must sign into.

There's also a payload organization key. This is an existing key for device enrollments, but becomes particularly useful for user enrollments, because this identifies the managed accounts on the device. It will appear in Settings and in the Notes app and some other places.

And also note that there's no access rights key here. Device enrollments use access rights to gate certain management capabilities for device enrollments, but these simply don't apply to the user enrollments. So, they're not specified.

There's more differences between the device enrollment protocol and the user enrollment protocol than I go to can go through here, but I will cover the most important points. First of all, profile service profiles and user enrollments do not mix. You cannot use them to enroll, and you can install one via a user enrollment.

Device enrollments use the UDID as the primary identifier of the device that is communicating.

User enrollments do not provide UDID or any other persistent identifier to the MDM server. This includes serial number, IMEI, MEID. Instead, when enrollment starts, iOS creates and enrollment ID, and this is communicated to the MDM server in all MDM communications.

The MDM server can use this as its primary identifier for the enrollment.

And when the enrollment ends, iOS destroys this enrollment ID. So, if the same device enrolls again, it will get a different enrollment ID.

There's something similar for ActiveSync.

When a user enrollment installs an exchange account, that goes into a user enrollment mode.

It uses a EAS device identifier that was generated at the start of the enrollment, and it communicates it both to the exchange server and to the MDM server in the device information query, so, they can use that to correlate as they usually do. And again, this is destroyed when the enrollment ends.

And the token update command does not include the unlock token. This means that the MDM server cannot clear the device passcode.

One of the top reasons why users reject BYOD programs is because they are concerned that the admin may erase the entire device, and they will lose their personal data on their own device. User enrollments do not the support Erase Device command.

And there's a similar thing for ActiveSync. If the exchange account is in user enrollment mode, the exchange server cannot send the RemoteWipe command. Instead, the MDM server can end the enrollment, and the exchange server can send the Account-only RemoteWipe, which only remove managed data in leave personal data untouched. Some queries will only return the managed results. So, for instance, the MDM server cannot find out what personal apps are installed on the device.

This is one place where we've added a new feature for device enrollments. They have a new managed-only key that filters the results in the same way.

When installing applications, user enrollments cannot take over or abandon management of an app.

The app is always removed when the enrollment ends. User enrollments support enterprise app distribution, and user-based VPP with PurchaseMethod 1. This ensures that the purchase goes on the managed Apple ID, not the personal Apple ID.

For VPN, user enrollments support the Per-app VPN, and we've expanded it with some new keys. These keys help guide the traffic for the related protocols through the Per-app VPN. These are also available for device enrollments, but for user enrollments, there's a very important limitation on these, which is that the second-level domain of the VPN server must match the second-level domain in the values for these keys. So, for instance, if the VPN server is VPN.acme.com, the mail domains can include mail.acme.com, but they cannot include mail.aol.com. This ensures that only the managed accounts are guided through the Per-app VPN.

If a user enrollment installs a passcode policy, iOS will enforce a six-digit not simple passcode.

And it does not support more complex passcode requirements. The main reason for this is because a more complex passcode requirement increases the risk that the user will forget the passcode, and the MDM server can't help out the user in this case by clearing the passcode. So, it would be unfair to require this.

For more information on why this is the sweet spot for passcode policies, I suggest reading the latest edition of iOS security document.

If you need proxying for Wi-Fi, use WPAD configured on the access points. The Wi-Fi payload does not support any of the proxy keys.

And defaults in logging payloads are not supported. Now these are very useful for troubleshooting or for reporting issues to Apple, and they can be installed, but it must be done by the user. So that they have a chance to accept the changes that these will make to their personal device. User enrollments do support some restrictions. Managed Open In is available, and the allowLockScreen restrictions are there, so that managed data does not appear on the lock screen. But it doesn't support any of the supervised-only restrictions, and it doesn't support any of the restrictions that really have nothing to do with managed data like content ratings or ones that turn off major features like iCloud.

These also apply to their ActiveSync equivalents when an exchange account is in user enrollment mode.

And I have an important warning for MDM server developers.

Make sure that your server is resilient to unexpected or absent keys and the results, as these capabilities are going to change over time.

Now I'd like to welcome my colleague Ren to the stage to demonstrate the user enrollment. Ren? Thanks Bob.

All right, hi everyone. My name is Ren, and today, I'm going to demo the user enrollment flow. Just like device enrollment, user enrollment starts with the profile, as well. To get that profile, today I'm going to go to an actual website of a company called Acme Inc.

This is the website, and please be aware that this is just a demo website. In the real world, you might have to authenticate first to download anything. But we skipped that step in this demo.

And as Bob has said, user enrollment works very closely with the Managed Apple ID. So, I will have to provide this ID information to this website to have it download, or generate, a profile for me.

Let me paste in the username and type on the enroll button. Read the warning carefully, and now, the profile has been downloaded to my phone. Let's go to Settings to check it out. After opening Settings, who will notice that a new cell with text, "Enroll in Acme Inc.," has been added to this page. And that is the shortcut to start user enrollment, and I'm going to take it now. This is a new UI we made for user enrollment. We merged the profile's basic information, the warning, and consent all into one page. We hope this will make your profile installation experience much smoother.

Also, if you want to dig more into the details of this profile, you can do that by tapping on the Details button at the top right. Let's take a look at the MDM payload of this profile. And you will notice that the managed Apple ID I provided at the website has been added to this payload, and this is the key to trigger user enrollment. Also, we removed the Access Rights section from this payload, because it's not needed with user enrollment.

Something that you might not have noticed is if you go back to the top-level page of this profile, you won't find any warning talking about the things the company can do to the employee's -- this device. And that is because, as Bob has mentioned, we carefully restricted the capability of the MDM server. So, it won't be able to disturb your personal user experience using your personal device.

Everything seems fine so far. Let's continue profile installation by tapping on the big rounded corner button on the bottom. I will provide my device password, and now I'm prompted to sign in this Managed Apple ID. So, depend on whether this account is Federated or not, the UI you see here might be slightly different. Here I'm just using a non-Federated regular account. So, I just have to type in my password for this account, and tap on sign in to continue. Now, a bunch of things are happening on the background. We have created a separate disk volume on this device for enterprise usage. We are signing in this Managed Apple ID to this device and enrolling this device into the MDM server.

All these steps are tied together, so if either of them failed, they will revert everything and pretend like nothing has happened.

Now the user enrollment has completed successfully. The MDM server can start sending MDM commands like install application, curate device information, etc., to this device. The pop-up you see now, it actually came from the MDM server asking me to install an app called Slack. Let's approve it, and the installation shall start shortly. Another tip about user enrollment is, if you want to check out the account we just signed in, you can do that by going to Settings, Account and Password -- Password and Accounts, and you will find that interface account there. The same account has also been added to apps like Files and Notes, and it's ready for you to use. Let's take a look at the Files, for example. After opening files, you will notice that a new iCloud drive with tag Enterprise has been added to Files, and all your enterprise data will be sent through this iCloud drive.

All right that's it for demo. Thanks for watching, and back to you, Bob.

User enrollments are also supported on macOS. They work with a Managed Apple ID. It creates a managed APFS volume. Notes data is fully separated between the volumes, depending on the account, and the management capabilities are similar to what I described for iOS, although there are some platform-specific differences.

This allows users to access the same Managed Apple ID on their personal iOS device and on their Mac. user enrollments provide a better balance for BYOD. It's time to set a new agreement between admins and their users. Admins should evaluate user enrollments, and they should reevaluate their security policies and shed some of these outdated requirements that don't make sense on modern devices.

Admins should provide a privacy policy to protect and reassure their users. We think this is the best way to bring BYOD devices into an organization. Thank you. Thank you very much, Bob and Ren, and now I'd like to take us through a couple of other topics related to balancing these values. The first, Certificate Transparency, an important new security enhancement that we brought to all of our OSs last December.

However, this can sometimes leak internal host names to public logs that enterprises might be concerned about. So, at the same time, we added a new payload, enabling them to opt out specifically sensitive certificates or domains, and they can install as many payloads as they need to manage all of those sensitive items.

We also added support for WPA3 security type to the Wi-Fi payload, including both personal and enterprise authentication. We also wanted to make it much easier for MDM servers to use the newer, more efficient push API to communicate with all of their enrolled devices. So, we now support token-based authentication for APNS. Now this is not new. We talked about this last year, but this year, we're actually enforcing that if you're using a device enrollment, those devices will be supervised and enrollment will be mandatory.

And this year, we're taking the opportunity to further deprecate the allow pairing key, because that sets that value permanently at enrollment time. Instead, we recommend using the existing configuration profile restriction, which can be changed at any time. Now I'd like to turn to a number of macOS-specific topics related to, again, mitigating the impacts of various security improvements on manageability. The first, a security improvement introduced in Mojave that made it more difficult to enable remote management when configuring new Macs. In macOS X.14.4, we added a pair of new commands that enable you to enable remote desktop management via two MDM commands, and they also configure the most common options that you'll need for ongoing management of those Macs, using Remote Desktop.

We also wanted to allow you to use your mobile accounts with Macs using FileVault. So, there's a new capability that MDM servers can manage a new bootstrap token. They asked the client Mac for that token, and then escrow it themselves. Then whenever a new user signs in on that Mac, it will request the bootstrap token from the MDM server and use it to generate the SecureToken needed to mount the file systems and boot the Mac.

We think this will great for helping with password changes in your organization. Now the privacy policy payload is not new in Catalina, though it's also a great example of a way that we help you mitigate the impact of important security enhancements on your ability to manage Apple devices, and there's some new security enhancements in macOS Catalina that are now also configurable using this policy. For example, enabling keyloggers or screen recording in the background, or whitelisting your internal apps that you don't want to notarize, so that they continue to run, even though macOS Catalina requires that apps and text be notarized.

Next, there is a new change that is new in macOS, Catalina, where, again, we're tweaking the balance between security manageability. Enabling FileVault via MDM now requires user-approved MDM enrollments, which means you can no longer pass off credentials on the command line's fdesetup. So, you should review your scripts and MDM agents if you have one in your MDM product, to be prepared for this change. Next, I think I heard there's been a lot of excitement about Activation Lock coming to T2 Macs and macOS Catalina. So, of course, we made this manageable via MDM, just like iOS.

In fact, your MDM servers will use the same endpoint in API as iOS. Those APIs will be available soon, and service fully available later this summer. So, you can test your implementation and have it ready when that kept a Catalina ships later this fall.

It's a big deal. Again, a couple of changes to tweak that balance. We're deprecating in macOS Catalina, although all of these capabilities will continue to work in Catalina, starting with silent profile installation from the command line.

With Screen Time coming to macOS and Catalina, we are deprecating path-based app black and whitelists that are currently configured using the parental controls application access payload.

And if your MDM server is still using the outdated user channel only enrollments, you should move to the modern macOS-specific enrollments that are required for user enrollments and also will be for any future enhancements to macOS device management.

Can we get a finely for the slide? I've been showing a version of this for I don't want to say how many years, but this year, in iOS 13 we will stop honoring the list of restrictions created before supervision existed, which really should be supervised only, but there'll be some grandfathering to make the transition a bit easier for organizations relying on these restrictions. For unsupervised devices with these restrictions enforced on iOS 12, when they're upgraded to iOS 13, they will remain in force, but they will not be honored on those unsupervised devices if you backup and then restore to that device or another unsupervised device.

This means that MDM servers need to stop sending these restrictions to unsupervised devices, because they will no longer be honored.

Bob explained that user enrollment does not support the unlock token, and we're also making some changes device enrollment related to it. Specifically, though, this is not new best practice. I always advise that you get the unlock token as soon as you need it and remember it. It will now only be available in the first successful token update after enrollment.

Similarly, devices which have been paired and supervised with Apple Configurator, you still need to get the unlock token before you set a passcode on that device. So, that brings us to the end of our second section of content, and I'd like to now turn to some new device capabilities that allow you to continue using services you're already using while adding some great new Apple services to help Apple devices stand out in your organization. The first one is another really big deal that Craig highlighted in Monday's keynote, and I'd like to ask Matt Chanda to come on stage and tell you all about Single Sign-On. Matt? Thanks, Todd. Good morning, my name's Matt Chanda, and I am a consulting engineer and part of the team that created Single Sign-On.

As you know, almost all enterprise apps and websites need to authenticate in order to function.

These apps connect the systems of record either in the cloud, on premise, and sometimes both.

Recently though, authentication has been getting more complicated. You have to handle multiple authentication protocols such as Kerberos, OpenID Connect, and SAML. You're now federated to the cloud, and you need to trust your devices and use more than just passwords for authentication. So, how do organizations deal with these challenges? Well, they use Single Sign-On to help. When they use Single Sign-On, they have a suite of apps and websites that they log in once too, and is reused across all of them.

Organizations will also use this to improve the user experience of authentication, avoid the user friction of signing in over and over again.

Some organizations just don't have passwords. So, they have to use Single Sign-On to authenticate, and the challenge is that not every application supports their authentication stack.

And, with all the risks these days, you want to supplement your authentication processes with trust score data and other information about the device that you're running on.

So, today I'd like to tell you about the powerful new Single Sign-On capabilities we added to both iOS 13 and macOS Catalina.

It's enabled by the extensible SSO MDM profile, as well as associated domains, and it works great with user enrollment, as well.

The extension has the option to show UI, load a webpage, or just handle the request silently. We think these changes will help you use and create SSO solutions that are both secure and user-friendly. So, in our session today, I will provide a summary of Single Sign-On and how it works. For more detail, look for a recorded session after the conference with code samples and more information. Earlier this week, you heard about an awesome new feature for consumer apps called Sign in with Apple. This is going to be great for consumer apps, but they don't support all the complex scenarios that are needed for enterprise applications.

So, Single Sign-On is different, and it's intended for third-party identity providers, such as Microsoft, Okta, Ping, and others.

In addition, you should know that managed Apple IDs will not work with Sign In with Apple. Okay, so, in order to make Single Sign-On work, you need to have a set of apps and websites, and you have to have an identity provider that they're set up to use. And then, what glues it together will be the new Single Sign-On extension.

So, we'll focus on the Single Sign-On extension today. All right, so how does it work? There are two types of extensions, redirect and credential.

So, let's start with redirect extensions. Redirect extensions are intended for modern authentication protocols, such as OpenIDConnect, OAuth 2, or SAML.

They will run on top of web technologies, and they frequently are paired with Federation to on-premise or cloud systems for authentication. Let's check out an example of the flow. With Safari, we will route a request to the Single Sign-On extension instead of loading the webpage.

The extension will receive the headers, the body, and the URL of the request.

It's now up to the extension to complete the authentication process with the identity provider.

And when ready, it will return a URL response back to Safari.

Please take note that this response should not be large. It's intended for a web form post of SAML response or other tokens back to the server. Don't try to load a giant, 1-meg webpage in it.

So, what can these extensions do? They can do a lot of things. I've listed a few of them here. They can choose to present a native screen for authentication instead of loading the webpage. The native screen could ask for the username and password if that applies, or it can ask for additional multi-factors, as your requirements dictate.

If you've generated keys with the secure enclave, perhaps they can sign attributes and send it along with the request to strongly pair the device with the user, so that you have that extra confidence in the request.

Other trust score values could be appended, such as the version of the operating system running on the device or whatever else you need to feel good about it.

It could simply load a webpage and follow the redirects for Federation, and that's going to be a very common scenario.

And with the new FIDO2 capabilities in macOS this year, it could use web authentication to authenticate the device, as well, if your identity provider supports it. For more information on web authentication, see the What's New in Authentication session in this year's conference. Redirect extensions will also work for native apps.

Native apps have an additional capability though. They can send operations to the extension.

These operations would be, or examples are login, refresh tokens, or logout.

This way, the app developers can decide when does authentication fit within the flow of my application? And hopefully, the extension will accommodate that. And for the enterprise developers in the audience, this means you can effectively use the extension as your identity library or authentication library.

It avoids the need to include a copy of the library in every app that you have and then subsequently maintaining it over time.

It'll be great.

So, let's check out the flow for native app.

The native app will send the operation to the extension instead of the URL request. In this example, it's login. The extension is still responsible for completing the authentication process with the identity provider, and when ready, it will return the URL response, but really, most importantly, the tokens that are needed by that application that they requested, in order to process and work correctly, think ID tokens and access tokens for consuming other services. Now that we know what it does, let's talk about what we need to do to make it work. It is enabled by the extensible SSO profile in iOS 13 and macOS Catalina.

Check out the example here. The identifier is com.apple.extensiblesso. It specifies the specific extension that you want to use in your environment, including the team identifier.

It lists the type, in this case, redirect, as well as the list of URLs that will be redirected to the extension.

And finally, an optional dictionary of extension-specific values from the MDM. In this example, I'm sending a user name, but you can put whatever you need in there.

The second requirement is to use associated domains. You're required to use associated domains because you can't just redirect any authentication traffic on the device to your extension.

You can only redirect traffic that is owned by you or your identity provider.

So, in order to set up associated domains, you need to use the offserve service type, followed by a colon, and then, each of the host names in the URL list that we saw in the previous slides. If your app has multiple hosts, then you need to list each one separately in the file.

Associated Domains also requires that the host app ID is in the Apple app site association file that on the destination server. The server must be accessible by the device and have a valid SSL cert.

User-approved or custom root certificates are not supported.

However, in some cases, the associated domains are not known at the time the app is developed.

A great example of this is when an identity provider develops an extension, but each customer's hostname is different. They can't list thousands of them in an entitlement file. It just won't happen. When this occurs, we can use the new Manage Associated Domains profile on macOS. In the example here, note that the payload value is the same as what would've been in the entitlement file that was on the app that was developed. On iOS, you can use a new associated domains application attribute, and again, note that the value of the attribute is the same as what would've been in the entitlements file in the host app that would happen. The last step for using managed associated domains is to include the managed associated domain's entitlement in the host apps file. This lets us know that you want to use the managed values, in addition to what you already have inside the entitlement file.

The associated domain's array has to be present and not empty, and you can even have other values in there already, and we will pin the ones from the MDM into the list there for you to use. For more details on associated domains, how to use them, check out the What's New in Universal Links session in this year's conference.

All right, and that completes redirect extensions.

So, now let's shift to credential extensions.

Credential extensions are intended for challenge-response-type authentication flows, and a great example of this is Kerberos.

These flows are different than redirects, because the client will request the data and then they are challenged for authentication.

Whereas redirect extensions, the client will proactively go out and retrieve tokens before they're needed and then use them.

We also support custom authentication challenges for this.

Credential extensions are different in redirect extensions, in that they receive HTTP challenge from the operating system and not the request.

The challenge will include the URL and the headers that were returned. The MDM profile will contain a list of hosts or host suffixes that applies to that extension.

So, for example, if you have .example.com, it'll be treated as a suffix.

Operations are also supported for credential-mode extensions, and there's not an associated domain requirement for them. Okay, so let's check out the flow.

In Safari, or your native app, it'll make a request to a server.

The server will return an authentication challenge back to the operating system, which we will route to the extension.

Just like the other extensions, it is required that it completes the authentication process with the identity provider or the authentication servers, whatever it may be. And when ready, the extension will return the headers back to the operating system, which will get sent back to the server, and assuming the server accepts it, the data will be returned back to the calling app that's needed. And that's the flow for credential extensions. And now for a demo of credential mode extensions, I'd like to call my colleague, Rick Lemmon. Rick? Hey, thanks a lot, Matt. Hi everybody, my name's Rick Lemmon, and I'm an engineer on the Apple Professional Services Team.

Today, I'd like to demonstrate a credential mode extension to you that we've built. This extension makes it easy for users to use Single Sign-On with your apps and websites. If you develop a Single Sign-On extension, you'll probably deliver it to your users as part of an app. So, this app can be used to deliver functionality that might not make sense to deliver in your extension, such as displaying status information to the user or allowing them to change their password. In our extension, what we've done is use a menu extra to do this. So, that's a little great key that we see up here.

So, what I'd like to do now is go ahead and sign into the extension.

Let's go ahead and sign in. I'm going to go ahead and enter my username and password.

And click sign in. Great. Now we're signed in. So, let's go back and look at the menu extra.

You'll notice in the menu extra, we're now displaying some useful status information to the user, like the user that we're signed in as and when our password expires. We also exposed some useful functionality, like the ability to change your password and sign out.

But now that we're signed into the Single Sign-On extension, we can use Single Sign-On to access websites and apps. So, let's go ahead and try a sample website that we've built.

Let's go ahead and, well, load the sample website. And, excellent. You've seen that we've just used Single Sign-On to access this website, and you'll notice, I wasn't prompted to authenticate. We can see that I'm authenticated as the same user that I used to sign into the extension earlier.

Let's go ahead and quit Safari, and let's show you how this works from an app. I'm going to go ahead and launch an app called Image Retriever that we wrote for this demo. This app is really simple. All that it does is connect to a web server that typically requires authentication, download an image, and displays it.

Now normally, you'd have to implement some sort of authentication for this app to work, but since we have Single Sign-On and in place, we don't need to. Let me go ahead and click display.

Excellent. As you might guess, based on my last name, I have something of a soft spot for lemons. So, our app has gone out, connected to a web server, authenticated using our Single Sign-On extension, and downloaded this super-sweet image of lemons.

Thank you.

So, let me quit Image Retriever now, and I'm going to show you guys some ways that authentication to the extension can be triggered.

To do that, I'll need to sign out of the extension, which I'll do here in the menu extra. Now just a note, your users, if you make an extension, will need to sign out of the extension. We're just doing this purely for demonstration purposes. So, now that I signed out, let's go ahead and launch Safari.

I'll go ahead and click on our website.

You'll notice I was immediately prompted to authenticate, which I'll go ahead and do.

And we'll click sign in.

Excellent. You'll notice that as soon as I signed in, Safari was able to seamlessly authenticate and load my website. So, I'll go ahead and quit Safari.

I will sign out of the extension, and we'll try the image retriever app again.

Let's go ahead and click display to make the image load.

You'll notice I'm prompted again.

We'll sign in.

Excellent. Our image of lemons downloaded again. Thank you. Great. So, let's talk a little bit more about this particular extension. So, some of you might see this extension and say, you know what? This could be useful in my own organization. Well, we agree with you. One thing that we haven't told you yet is that this extension, behind the scenes, is using Kerberos and Active Directory.

And so, we're thrilled to announce that this extension will be included with macOS Catalina, iOS13, and iPadOS. Thank you. This extension is based on Enterprise Connect, an Active Directory integration solution that some of you may already be using. It provides an easy way to integrate your devices with Active Directory.

On top of providing Kerberos support, it helps you manage your Active Directory password, and on macOS, helps you keep your local and active directory passwords in sync. Also, on top of authenticating through the extension with the username and password, you can use the certificate-based identity, or on macOS, you can use a smart card. We think this extension will help many of you more easily use Kerberos and Active Directory in your organizations. And that concludes credential-based Single Sign-On extensions.

So, let's summarize. We're really looking forward to seeing what kind of extensions you built, out the Single Sign-On session for additional detail on making your own extensions. It will be posted to the WWDC site after the conference, and now I'll hand it back to Todd.

Thank you very much, Matt and Rick. Just have a few more words about associated domains, which, as Matt explained, can be managed via MDM, but they're not just for Single Sign On. Other service types, such as universal links and password autofill, are also supported by associated domains, and they're now also supported by custom apps, not just App Store apps. So again, if you'd like to learn more about them, check out the Universal Links session from earlier this week. Now I mentioned federated authentication earlier in the session, but I wanted to highlight it here again, because it, along with a number of the other things we've announced here this morning, come together is a great example of how we enable Apple devices to fit in while standing out in your organization.

Managed Apple IDs coming to ABM and User Enrollment requiring Managed Apple ID means that we've made it really easy for you to take advantage of user enrollment with the identities that you're already using.

Now we've spent a lot of time today talking about the new, hot user enrollment, and that's great, but of course, we haven't stopped improving device enrollment either.

So, I want to talk about a great new feature that allows organizations to customize the experience their users have right inside of Setup Assistant as they're enrolling their devices. This is great. You can now provide your own custom web UI that you can use for a number of important purposes from choosing the authentication type you want to use, something modern, multifactor, whatever works for your organization, custom organization branding, and whatever additional information you want users to have access to while they're enrolling, again, right in Setup Assistant, whether it's your privacy policy, additional consent text, or your acceptable use policy. And just to give you an idea, again, this should look very familiar, but instead of seeing our off UI on the next pane in Setup Assistant, you can see your UI.

Here's an example on the Mac of authentication.

This is really exciting.

And in the iPhone, an example, Acceptable Use Policy. Basically, this just gives you a way to give your users the exact right experience for them in your organization.

I mentioned content caching earlier. This is a great way to optimize how your organization uses its bandwidth, and to date, it's been a best-effort optimization. But now it's possible to configure it, as required infrastructure for all devices on your network, if that's what works for your organization. And you can also configure devices to prefer specific client caches.

Now, of course, there's lots of other things we've added this year, just like always, enabling you to configure the Setup Assistant and lots of other settings and restrictions, and that's really great, but I think we should really read the documentation together instead of hearing me talk about it. Because we are so excited about the giant leap forward we made in giving you what you deserve, comprehensive, up-to-date documentation, both because we've improved our internal processes, allowing us to import our new keys and values that we add to the profile payloads and MDM commands directly from our code into the documentation, and then showing that documentation to you just like all other Apple documentation, including a great way to highlight the changes introduced in a particular OS release. We think this will make it much easier for you to adopt everything we've talked about today and in the future more quickly for all of our joint customers to take advantage of. But instead of me talking about it anymore, I'd like to ask Graham McLuhan to come on stage and show it to you. Graham? Thank you, Todd. I'm really excited to be here today to show you the latest device management documentation.

Who's had a chance to check out the new documentation? Yeah, all right, it's really great. So, for those of you who haven't had a chance to check it out, let's take a look.

So, the first thing that you'll notice is that the device management documentation has a new home alongside the rest of the Apple developer documentation.

Clicking in, you'll see all of the things that you're used to seeing, configuration profiles, MDM protocol, and deployment services. So, let's take a look at the configuration profiles.

Here you'll see an easy-to-search list of all of the different profiles that are available on all of our platforms. Let's take a look at the ExchangeActiveSync payload.

The first thing I'd like to point out here is the Show API Changes option, where you'll be able to see the differences between the current OS release and the upcoming beta.

Yes, great. On the left-hand side, you can see there's been one modification to an existing key and 12 new keys added. As a note, to find out which Xcode versions relate to which OS releases, you can check the Xcode release notes.

Below that, in the property section, you can see all the keys, their types, and their default values that make up the payload.

As we scroll down, you can see that the keys are highlighted with purple tildes are modified keys, and the new keys that we've added are highlighted with the green plus sign.

Below that, we have a profile availability table that shows you all of the different platforms the payload is supported on, and below that, we have related objects, such as dictionaries, that make up the payload, as well as other related payloads you may be interested in.

So, let's jump back to the top-level device management page using the breadcrumbs at the top of the page.

Now, with the Show API Changes enabled, we can also see that there have been some changes to the MDM protocol. So, let's take a look.

Here you'll find it easy-to-search list of all of the different commands and queries that are available. Let's take a look at the install application command.

On the right-hand side, you'll notice that we list all of the platforms and the corresponding OS releases where this feature was added.

On the left-hand side, you can see that we document the command itself, as well as the response, and below that, on the command availability table, that shows you all the different ways that this command can be implemented.

So, let's take a look at the actual MDM command itself.

All right, here, you can see a list of all of the keys that make up the install application command. So finally, I'd like to talk a little bit about how we've documented the changes for user enrollments. The availability tables are a great way for you to see if a feature is supported in User Enrollment, but in some cases, we've had to change the way that specific keys behave, and the restrictions payload is a great example of this.

So here, you can see that we've added help text to each key to tell you how it can be used. The Allow Account Modification restriction, for example, can be used on a supervised device and is available on iOS 7 or later.

We know that for BYOD enrollments, Managed Open In is one of our most important restrictions. So, let's take a look how that's been implemented. Here you can see that this is available for iOS 7 or later and also available for user enrollments. Well, we're really excited for you take a look at all this new documentation, and with that, a hand it back to you, Todd.

Thank you very much, Graham.

Again, we're really excited for this and hope you will go check it out if you haven't already. It's been live since Monday. All right, will that brings us to the end of our content. So again, we hope that new documentation makes it much easier for you to support everything new, which of course, we want you to do, and stop relying on UserAgent string or installing supervised restrictions on unsupervised devices.

There's a lot of helpful links to that documentation, as well as many other resources at the session URL on-screen. Come see us in the lab after lunch, and check out those sessions that we referred to during the session on universal links and desktop browsing on iPad. I want to thank all of you for coming out this morning. I hope you enjoy the rest of this final day of WW2019. Thank you very much.

[ Applause ]