Enforce Okta Device Trust for Native Apps and Safari on MDM-managed iOS devices

Diagram — Device Trust flow

Key benefits

Ensures that only iOS devices managed by your chosen Mobile Device Management (MDM) provider can access SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. and WS-Fed cloud apps.
Provides a frictionless end user experience by utilizing Okta Mobile for iOS

Requirements

iOS devices running Okta-supported versions of iOS
MDM provider support:
- Minimum – any Mobile Device Management (MDM) provider that supports managed appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. configuration
- Recommended – MDM providers that support (1) managed app configuration and (2) the ability to convert an end user-installed Okta Mobile app instance to a managed app
Apps:

Any iOS SAML or WS-Fed cloud app
Okta Mobile 5.12 or later, managed by your MDM provider

(Necessary only during the Early Access phase of this Device Trust solution) Make sure that Okta Customer Support has enabled this Device Trust solution for your orgThe Okta container that represents a real-world organization.. This is in addition to the global Device Trust setting that you enable as described in Part A.

Caveats

Device Trust does not apply to apps accessed via chicletsThe "buttons" that appear on an end user's Home page and represent each application they wish to access through Okta. Clicking the chiclet allows the end user to instantly sign in and authenticate themselves into their chosen app. within Okta Mobile.
Securing access to Box — To secure access to the Box app, we recommend that you use Box for EMM. If you want to use this Okta Device Trust solution instead of Box for EMM, you must contact Box Support and ask them to enable Safari View Controller (SVC) for your Box tenant
If Device Trust and Okta Mobile Connect are both enabled — End usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. trying to access an app enabled for Okta Mobile Connect (OMC) and secured by Device Trust go through the Device Trust authentication flow if the app has been configured with any Device Trust Sign On policy rule. Otherwise, they go through the OMC flow.
End users are not redirected to the app sign-in page under some circumstances — When this Device Trust solution is enabled, if end users sign into an Okta-federated Gmail or Salesforce account and later delete the account, they are redirected to the Okta Home page instead of the app's sign out page.
Okta supports password-less authentication only for Office 365 apps (assumes that Okta Mobile is installed) — For all other apps, end users are presented the Okta Sign In page to enter credentials. Users are then prompted to let Okta Mobile assess the trust status of their device. If the device is trusted (MDM-enrolled), end users can access the app. If Okta Mobile assesses the device to be untrusted, one of the following occurs:
- If you configured a Sign On policy rule to deny untrusted devices, users with such devices are prompted to enroll in your MDM provider.
- If you configured a Sign On policy rule to present an MFA challenge to users with untrusted devices, such users are challenged with MFA.
Web-based MDM enrollment fails for SVC-enabled apps — For customers integrated with an MDM provider that supports web-based enrollment (such as MobileIron), the automatic enrollment flow designed to occur in this device trust solution fails if end users try to access a Safari View Controller-enabled native app (SVC). This happens because SVC apps do not support opening the device’s Settings page, which is required to complete MDM enrollment. If the app includes a button to launch Safari, end users can tap the button and complete MDM enrollment.
End users might disable Universal Links inadvertently and be prevented from accessing Device Trust-secured apps — If Okta Mobile is installed on the device and an end user taps the upper right corner of the screen (where breadcrumbs are typically located), the user is prompted to install Okta Mobile even though it's already installed. This happens because tapping that part of the screen inadvertently disables the Universal Link configured to open Okta Mobile. An Okta Mobile session is required in order for the user to be authenticated into the app. Advise affected end users that they can open Okta Mobile in this case by performing the following workaround:

Open the Notes app.
Create a new note containing this URL: https://login.okta.com/auth/oktamobile
Click Done. This is necessary to make the URL a hyperlink.
Long press on the link https://login.okta.com/auth/oktamobile.
In the list that opens, tap Open in "Okta Mobile" to launch Okta Mobile. Screenshot

Securing an Okta-federated MDM application with this Device Trust solution — Okta recommends that you not apply a Not Trusted - Deny app sign policy to your Okta-federated MDM application. Doing so will prevent new users from enrolling their device in your MDM application and accessing other device trust-secured apps.
Device Trust-secured apps are shown as locked on end-user Okta Home pages — End-user Okta Home pages viewed on desktop and mobile browsers (but not in Okta Mobile) display a lock icon on all Device Trust-secured app chiclets if (1) Device Trust is enabled for the org, (2) the device is not trusted, and (3) the end user tried to access any Device Trust-secured app from their Home page. The lock icon remains for the duration of the session.

Procedures

This procedure has three main parts:

Part Ⓐ — Enable the global Device Trust setting for your org

From the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. console, go to Security > Device Trust.
In the iOS Device Trust section, click Edit.
Select Enable iOS Device Trust.
Select the option(s) that correspond to your MDM provider:

MDM	Options
AirWatch (UEM)	Trust is established by: VMware Integration type: AirWatch
Microsoft Intune	Trust is established by: Microsoft Intune
MobileIron	Trust is established by: MobileIron
None of the above	Trust is established by: Other Integration type: Managed app configuration provider -or- SAML device identity provider

Click Next.
Copy the provided Secret Key Value to your clipboard by clicking the copy icon adjacent to the field. You'll enter the Secret Key later in your MDM provider's app configuration as described in Part B.

Important: Make a note of the provided Secret Key Value, as this is the only time it will appear in Okta. If you generate a new Secret Key by clicking the Reset iOS secret Key button, make sure to also update your MDM configuration with the new key.
(Optional) In the Mobile device management provider field, you can modify the provided name of your MDM provider. Your entry is displayed to end users during device enrollment

If you selected Other in a previous step, the field is pre-populated with generic text. Otherwise, the field is pre-populated with the name of your chosen MDM provider.

In the Enrollment link field, enter a web address where end users with unmanaged devices will be redirected. For example, you may want to send these users to a page with enrollment instructions, or the enrollment page of your selected MDM if the MDM provider supports web-based enrollment.
Click Save. Screenshot

Proceed to Part B.

Part Ⓑ — Integrate Okta into your third party MDM provider

Obtain Okta Mobile from the App Store.
Configure your MDM provider to manage Okta Mobile and to install it on end user devices if it is not installed already.
Configure the key/value pair through your MDM provider's managed app configuration:
- Key: managementHint
- Value: Use the Secret Key value that you saved in Part A.
  Note: The Key/Value pair is case sensitive.
Proceed to Part C.

Known Issue

If Microsoft Intune is your MDM provider and is federated to Okta, applying a Not Trusted --> Deny app sign-on policy to an Okta-federated O365 app will block end users with unmanaged iOS devices from enrolling their device in Intune. This happens because your O365 app sign-on policy is applied to Intune as well. Okta is investigating this issue. In the mean time, Okta recommends that you use Microsoft Intune MAMMobile Application Management, software and services responsible for provisioning and controlling access to internally developed and commercially available mobile apps used in business settings on both company-provided and “bring your own” smartphones and tablet computers. to manage access to O365 apps and this Okta Device Trust solution to manage access to other sensitive apps