Mastering Enrollment Single Sign-On with Jamf and Okta

Enrollment single sign-on (ESSO) supported by Jamf in partnership with Okta is here, but no matter what your identity provider is today, the road to success is paved with testing your existing single sign-on setup.

What is enrollment single sign-on?

Now available with the release of Jamf Pro 10.47 and if Okta is your cloud identity provider: when a user initiates an enrollment of their personal device into an MDM, a “helper application” will be pushed down to the device first without the need for an Apple ID or user effort. This helper app can be used to hold the user’s identity provider (IdP) credentials for the inevitable 27 different sign in requests that will come in for setting up MFA, Apple iCloud, e-mail, activating Jamf Connect ZTNA, access to cloud services like Office, Jira, Confluence, Salesforce…

Enrollment single sign-on is based on the single sign-on extension

The amount of time a user spends setting up their phone is about to get much, much quicker. The enrollment single sign-on extension (ESSOe) will make the onboarding experience easier and life with your BYOD device at your organization happier over time.

The single sign-on extension (SSOe) is so new that you may not have it set up in your environment yet. Okta has released functionality to all Okta Identity Engine tenants, and Microsoft just made SSOe available through general availability on Azure this month.

Single sign-on is enabled by an app installed on a device and a configuration profile pushed down to the device by the MDM.

Unlike ESSOe which is intended for personal devices enrolled through account-driven user enrollment, this standard extension to the Apple operating systems is available now for all devices managed by an MDM — institutionally owned through any method or personal through user enrollment.

The single sign-on extension is supported by Okta using the Okta Verify app on macOS, iOS and iPadOS. On Azure, the extension is supported by the Company Portal app on macOS and Microsoft Authenticator on iOS and iPadOS.

No matter your identity provider, the simple presence of the app on the device combined with a configuration profile you push via Jamf is all your user will ever really need. They won’t need to register a device with Okta nor will they need to enroll a device for Azure Conditional Access. The only thing a user will need to do is log into something gated by your identity provider once. After that, the SSOe informs the Apple device to use the helper app to automatically cache the user’s credentials and negotiate access tokens for services.

Modifying authentication policies to use single sign-on

To make enrollment single sign-on work, your authentication policies and conditional access policies need to adapt to take advantage of single sign-on. Take the time now to communicate with your identity team and discuss allowing Okta Verify as an authentication method. Discuss using biometrics as a non-phishable “second factor” for advanced security. For Azure users, even though ESSO isn’t available at this time, discuss using the new Authentication Strength grants and “Require MFA” grants in your conditional access policies.

The authentication policy or the conditional access policy will need to allow this new simplified login process for your end users to access cloud resources like email, iCloud, activating Jamf Connect ZTNA and others, otherwise the default will be the good ol’ password 27 times a day like the old days.

Use Jamf Pro to target test groups and devices

Unlike some apps or configurations you can test locally, the single sign-on extensions must be pushed down via an MDM like Jamf Pro or Jamf School. But we’re ready for that.

Once your identity team has set up authentication and conditional access policies, set up a group of test devices and a team of volunteers to try out the SSOe day to day. You can use a Static Device Group or Static Computer Group to pick a specific group of devices to receive the Okta Verify app via policy or via VPP automatic installation as well as the configuration profile.

Once your test group gets the app and the configuration, simply go through your day-to-day activities. Log into your cloud applications, hit your corporate websites gated with OAuth, SAML and OIDC logins, and see the magic happen.

Once your users are comfortable and you’ve tested that end users can access their mission critical resources, roll out the app and config to your fleet and listen for the sighs of “aaaah….” single sign-on is really single sign-on and not 27 times typing the same user name and password over and over and over and over again.