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

Early Access release

This Okta Device Trust solution for Native Apps and Safari on OMM-managed iOS devices allows you to prevent unmanaged iOS devices from accessing enterprise services through browsers and native applications. Also, this solution:

  • Ensures that only users with OMM-enrolled iOS devices can access SAML and WS-Fed cloud apps.
  • Provides a frictionless end user experience by using Okta Mobile for iOS.

Prerequisites

  • Works with:
    • Any SAML or WS-Fed cloud app in the Okta Integration Network
    • iOS apps that support web-based federation to Okta, and the Safari mobile browser
  • Devices are running Okta-supported versions of iOS
  • Okta Mobility Management (OMM) is configured for the org
  • Okta Mobile is installed on end user devices (otherwise, end users are prompted to install it)
  • End user devices are OMM-enrolled (otherwise, end users are guided through the enrollment flow)

Before you begin

  • Device Trust doesn't apply to apps accessed from Okta Mobile.

  • Okta supports password-less authentication only for Office 365 apps. For all other apps, end users are shown the Okta Sign-In Widget to enter credentials. Users are then prompted to let Okta Mobile assess the trust status of their device. If the device is trusted (OMM-enrolled), end users can access the app. If the device isn't trusted, end users are prompted to enroll in Okta Mobility Management (OMM).
  • End users are not returned to the Settings app under some circumstances. When iOS end users who aren't OMM-enrolled use the iOS settings app to add a Gmail account to the native Mail app, they're prompted to enroll in OMM. Following enrollment, end users are prompted to tap the Home button to return to settings. Instead of being redirected to the Gmail sign-in page, end users see the Okta MDM Configuration page. Advise affected end users to try to configure Gmail again.
  • 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 redirects the user to Okta Mobile to assess whether the device is trusted or not (that is, OMM-enrolled). If Okta assesses the device to be untrusted, the user is prompted to enroll in OMM.
  • Not trusted condition isn't applied. While it's possible to create rules that include the Not trusted condition, Okta won't apply such a rule in this Early Access version of the feature. This is because end users with untrusted devices are forced to enroll their device in OMM to become trusted. Therefore, we recommend that you create a Trusted-Allow rule similar to Rule 2 below, with or without the MFA action.
  • End users aren't 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're redirected to the Okta Home page instead of the app's sign out page.

  • Apps secured by Device Trust are shown as locked on the Okta End-User Dashboard. A lock icon is shown beside apps secured by Device Trust under these conditions:

    • The end users accessed the dashboard in a desktop or mobile browser (not in Okta Mobile).
    • 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 dashboard.

Tasks

Enable the global Device Trust setting for your org

  1. Configure OMM for your org.
  2. In the Admin Console, go to SecurityDevice Trust.
  3. Click Edit.
  4. In the iOS Device Trust section, select Enable iOS Device Trust.
  5. In Trust is establish by, make sure Okta Mobility Management is selected.
  6. Click Save.

Configure app sign-on policy rules in Okta

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, 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 an allow-list approach to sign-on policy rules

    1. Create one or more Allow rules to support the scenarios that will allow access to the app, then assign those rules the highest priority.
    2. Create a Deny catch-all rule that will apply to users who don't match the permissive scenarios you created in Step 1. Assign the Deny catch-all rule the lowest priority, just above the default rule. In the allow-list approach described here, the default rule is never reached because it is effectively negated by the Deny catch-all rule.

    For important security information about creating app sign-on policy rules, see App sign-on policies.

Sign on Procedure

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 the Admin Console, go to ApplicationsApplications, and then click the SAML or WS-enabled app that you want to protect with Device Trust.
  2. Click the Sign On tab.
  3. Scroll down to the Sign On Policy, and click Add Rule.
  4. Configure one or more rules using the following example as a guide.

Example Rule 1: Web browser or Modern Auth; iOS; Trusted; Allow access + MFA

  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 needs to be the same for all rules you create for this example.
  2. Under LOCATION, specify the user location to which the rule will apply. The Location option you select needs to be the same for all rules you create for this example.
  3. Under CLIENT, configure the following settings:

    4. Web browser selected.

    Modern Auth client selected.

    Exchange ActiveSync client 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. Under DEVICE TRUST, configure the following:

    5. Any is unselected.

    Trusted is selected.

    Not trusted is unselected.

Actions

  1. Configure Access:

    2. Allowed is selected.

  2. Prompt for factor is selected.

  3. Click Save.
  4. Create Rule 2.

Example Rule 2: Web Browser or Modern Auth; All platforms except iOS; Any Trust; Allow access + MFA

  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 needs to 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 needs to be the same for all rules in this example.
  3. Under CLIENT, configure the following settings:

    4. Web browser selected.

    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. Under DEVICE TRUST, configure the following:

    5. Any is selected.

    Trusted is unselected.

    Not trusted is unselected.

Actions

  1. Configure Access.

    2. Allowed is selected.

  2. Prompt for factor is selected.

  3. Click Save.

Example Rule 3: Any client; All platforms; Any Trust; Deny access

  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 needs to be the same for all the 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 needs to be the same for all the rules you create for this example.
  3. Under CLIENT, configure the following settings:

    4. Web browser selected.

    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. Under DEVICE TRUST, configure the following:

    5. Any is selected.

    Trusted is unselected.

    Not trusted is unselected.

Actions

  1. Configure Access.

    2. Denied is selected.

  2. Click Save.

Example Rule 4: Default sign on rule – Any client, All platforms; Any Trust; Allow access

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 3.

Known issues

  • Box currently isn't supported with this Device Trust solution. We recommend using Box for EMM.
  • Trust message may cause confusion — In the Device Trust section of the Add/Edit Sign On Rule dialog box, the message '"Trusted" and "Not trusted" are available only after configuring Device Trust' displays in some circumstances when Device Trust is configured in SecurityDevice Trust, which may cause confusion. Make sure that you have selected the correct platforms in the Client section of the dialog box.
  • Change Device Trust settings to Any under some circumstances — If you decide to ask Okta Support to disable Device Trust capability for your org, make sure to first change the Device Trust setting in the app sign-on policy rules to Any (ApplicationsappSign On). If you do not make this change and then later have Okta Support re-enable Device Trust capability for your org, the Device Trust setting in app sign-on policy rules will take effect immediately, which you may not have expected.