WWDC2019 Session 303

Transcript

[ Music ]
[ Elevator Dings ]
[ Approaching Footsteps ]
>> Guys! Guys!
I just got is a meeting with
Vivian.
>> What? How?
>> I just bumped into her.
[ Car Door Slams ]
[ Approaching Footsteps ]
>> 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.
[ Music ]
>> We have this idea.
I need some sort of 3D
prototype.
>> I've got to pick up the kids.
[ Music ]
>> 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.
[ Music ]
[ Knocking ]
>> Brian?
[ Phone Chimes ]
[ Water Running ]
[ Knocking ]
>> 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.
[ Music ]
>> What do you guys want to hit
on?
>> Nothing.
[ Music ]
>> Move that over there.
>> Make that title bigger.
>> Do a dash.
>> Guys!
[ Music ]
>> 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!
[ Music ]
>> 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!
[ Music ]
[ Devices Chiming ]
>> I'm awake.
>> Agh!
[ Watch Chimes ]
>> It's time.
[ Music ]
>> Did anyone press the button?
[ Music ]
[ Applause ]
>> We did it.
We made a round pizza box.
[ Applause ]
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.
[ Applause ]
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.
[ Applause ]
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.
[ Applause and Cheers ]
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.
[ Applause ]
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.
[ Applause ]
>> 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.
[ Applause ]
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?
[ Applause ]
>> 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.
[ Applause ]
>> 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.
[ Applause ]
>> 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.
[ Applause ]
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.
[ Applause ]
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?
[ Applause ]
>> 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.
[ Applause ]
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?
[ Applause ]
>> 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.
[ Applause ]
Thank you.
[ Applause ]
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.
[ Applause ]
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.
[ Applause ]
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.
[ Applause ]
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.
[ Applause ]
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?
[ Applause ]
>> 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.
[ Applause ]
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.
[ Applause ]
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 ]