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

Okta Device Trust for iOS allows you to prevent unmanaged iOS devices from accessing enterprise services through browsers and native applications.



  • iOS devices running Okta-supported versions of iOS
  • MDM provider support:
    • Minimum – any Mobile Device Management (MDM) provider that supports managed app 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.0+ for iOS, managed by your MDM provider

  • 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 users 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.
    • Sign On policy rules with the Trusted or Not trusted condition — When processing a Sign On policy rule for an app configured with the Trust or Not trusted condition, Okta suspends normal rule processing and uses Okta Mobile to assess whether or not the device is trusted. If Okta assesses the device to be untrusted, one of the following occurs:
      • If you configure a Sign On policy rule to deny untrusted devices, users are prompted to enroll in your MDM provider.
      • If you configure a Sign On policy rule to issue an MFA challenge to users with untrusted devices, such users are presented an MFA challenge.
  • 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 don't 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:
    1. Open the Notes app.
    2. Create a new note containing this URL: https://login.okta.com/auth/oktamobile
    3. Click Done. This is necessary to make the URL a hyperlink.
    4. Long press on the link https://login.okta.com/auth/oktamobile.

  • 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 icons if all of the following are true:

    • Device Trust is enabled for the org .
    • The device is not trusted.
    • 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.


This procedure has three main steps:

  1. In the Admin Console, go to Security > Device Trust
  2. In the iOS Device Trust section, click Edit.
  3. Select Enable iOS Device Trust.
  4. Select the option(s) that correspond to your MDM provider:

    5. MDM Options
    Workspace ONE UEM

    (formerly AirWatch)
    • Trust is established by: VMware
    • Integration type: Okta client-based (Workspace ONE UEM)
    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: Okta client-based.

    Important: Don't select the SAML-based option. It doesn't apply to this Device Trust solution.
  5. Click Next.

  6. Copy the provided Secret Key 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 STEP 2.

    Important Note

    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.

  7. In the Mobile device management provider field, add or modify the name of your MDM provider. The content of this field is displayed to end users when they enroll their device.
  8. In the Enrollment link field, enter a web address for redirecting end users with unenrolled devices. For example, you may want to redirect these users to a page with enrollment instructions or the enrollment page of your selected MDM (assuming the MDM provider supports web-based enrollment).
  9. Click Save.

  10. Proceed to STEP 2.

Recommended MDM capabilities

At minimum, your MDM must support managed app configuration. For best results, we recommend that you integrate with an MDM that can do the following:

  • Set Okta Mobile to be a managed app
  • Set Okta Mobile to install on end-user devices silently and automatically when they enroll in your chosen MDM
  • Set the MDM to convert end user-installed Okta Mobile app instances to a managed app
  • Use the managed app configuration to configure the key-value pair

Ensure the best end user experience

Your end users will have a better experience when accessing your managed corporate resources if their iOS device is already enrolled in your MDM provider and Okta Mobile was already installed silently on the device through the MDM provider's app store. If Okta Mobile isn't installed already, end users are guided to install it through the MDM app store. If Okta Mobile is installed but not already managed by the MDM provider, end users are guided through the app management process before they can access device trust-secured apps.

  1. Configure your MDM provider to manage Okta Mobile and to install it on end user devices if it isn't installed already.
  2. Configure the key/value pair through your MDM provider's managed app configuration as described in their documentation:
    • Domain: Enter the URL of your Okta org
    • Key:managementHint
    • Value: Use the Secret Key value that you saved in STEP 1.

      • Note: The Key/Value pair is case sensitive.

  3. Click Next.
  4. Proceed to STEP 3.

About App sign on policy rules

By default, all Client options in the App Sign On Rule dialog box are pre-selected. To configure more granular access to the app, create rules that reflect:

  • Who users are and/or the groups to which they belong
  • Whether they are on or off network or within a defined network zone
  • The type of client running on their device (Office 365 apps only)
  • The platform of their mobile or desktop device
  • Whether or not their devices are Trusted

Taking a whitelist approach to Sign On policy rules

Procedure

Note: This example shows Device Trust rules for managing access to Office 365. For other apps, note that the section If the user's client is any of these isn't present.

  1. In Okta, go to Applications and click the SAML or WS-Fed-enabled app that you want to protect with Device Trust.
  2. Click the Sign On tab, scroll down to the Sign On Policy, and click Add Rule.
  3. Configure one or more rules using the following examples as a guide.

This example illustrates how you can design an app sign on policy that allows access to web browsers and Modern Auth clients, requires MFA for all access, and denies access to untrusted iOS devices.

Example Whitelist

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, specify whether to apply the rule to individuals only or to individuals and groups. The People option you select must be the same for all the rules you create for this example.
  2. Under Location, specify the user location to which the rule will apply. The Location option you select must be the same for all the rules you create for this example.
  3. Configure client settings:

    4. Type:

    þ Web browser or Modern Auth client is selected.

    ¨ Exchange ActiveSync client is is unselected.

    Mobile:

    þ iOS is selected.

    ¨ Android is unselected.

    ¨ Other mobile is unselected.

    Desktop:

    ¨ Windows is unselected.

    ¨ macOS is unselected.

    ¨ Other desktop is unselected.

  4. Configure Device Trust.

    5. Trusted and Not trusted options in the Device Trust section are selectable only when all of the following options in the Client section are not selected:

    • Exchange ActiveSync or Legacy Auth client
    • Other mobile (for example, BlackBerry)
    • Other desktop (for example, Linux)

    ¨ Any is unselected.

    þ Trusted is selected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access:

    2. Allowed is selected.

    þ Prompt for factor is selected.

  2. Click Save.
  3. Create Rule 2.

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option must be the same for all rules in this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option must be the same for all rules in this example.
  3. Configure client settings:

    4. Type:

    þ Web browser or Modern Auth client selected.

    ¨ Exchange ActiveSync client is unselected.

    Mobile:

    ¨ iOS is unselected.

    þ Android is selected.

    þ Other mobile is selected.

    Desktop:

    þ Windows is selected

    þ macOS is selected

    þ Other desktop is selected

  4. Configure Device Trust.

    5. Trusted and Not trusted options in the Device Trust section are selectable only when all of the following options in the Client section are not selected:

    • Exchange ActiveSync or Legacy Auth client
    • Other mobile (for example, BlackBerry)
    • Other desktop (for example, Linux)

    þ Any is selected.

    ¨ Trusted is unselected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access.

    2. Allowed is selected.

    þ Prompt for factor is selected.

  2. Click Save.
  3. Create Rule 3.

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option you select must be the same for all rules you create for this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option you select must be the same for all rules you create for this example.
  3. Configure client settings:

    4. Type:

    þ Web browser or Modern Auth client selected.

    ¨ Exchange ActiveSync client is unselected.

    Mobile:

    þ iOS is selected.

    ¨ Androd is unselected.

    ¨ Other mobile is unselected.

    Desktop:

    ¨ Windows is unselected.

    ¨ macOS is unselected.

    ¨ Other desktop is unselected.

  4. Configure Device Trust.

    5. Trusted and Not trusted options in the Device Trust section are selectable only when all of the following options in the Client section are not selected:

    • Exchange ActiveSync or Legacy Auth client
    • Other mobile (for example, BlackBerry)
    • Other desktop (for example, Linux)

    ¨ Any is unselected.

    ¨ Trusted is unselected.

    þ Not trusted is selected.

ACTIONS

  1. Configure Access.

    2. Denied is selected.

  2. Click Save.

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option you select must be the same for all rules you create for this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option you select must be the same for all rules you create for this example.
  3. Configure client settings:

    4. Type:

    þ Web browser or Modern Auth client selected.

    þ Exchange ActiveSync client is selected.

    Mobile:

    þ iOS is selected.

    þ Android is selected.

    þ Other mobile is selected.

    Desktop:

    þ Windows is selected.

    þ macOS is selected.

    þ Other desktop is selected.

  4. Configure Device Trust.

    5. Trusted and Not trusted options in the Device Trust section are selectable only when all of the following options in the Client section are not selected:

    • Exchange ActiveSync or Legacy Auth client
    • Other mobile (for example, BlackBerry)
    • Other desktop (for example, Linux)

    þ Any is selected.

    ¨ Trusted is unselected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access.

    2. Denied is selected.

  2. Click Save.

The Default sign on rule is already created and can't be edited. In this example, the Default rule is never reached because it is effectively negated by Rule 4.



  • If Intune is your MDM provider, O365 isn't supported when using this Device Trust solution — 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 MAM to manage access to O365 apps and this Okta Device Trust solution to manage access to other sensitive apps.

From Okta

Device Trust

Office 365

Add Sign On policies for applications


External resources

VMware

Manage Applications Overview

Intune

What is Microsoft Intune app management?

App configuration policies for Microsoft Intune

How to add an app to Microsoft Intune

MobileIron

App Configuration

The AppConfig Community

Security and Configuration Framework for iOS

Apple

Introducing Safari View Controller (for best results, open this link in Safari)