Configure Okta Device Trust for Native Apps and Safari on MDM-managed devices Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a0000005ujrsaa&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fconfigure-okta-device-trust-for-native-apps-and-safari-on-mdm-managed-devices-463669650
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Average Rating:
Configure Okta Device Trust for Native Apps and Safari on MDM-managed devices
Published: Jan 31, 2018   -   Updated: May 15, 2018

okta-doc-source

This is an Early Access feature. To enable it, please contact Okta Support.

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


Okta Device Trust for Native apps and Safari on MDM-managed iOS devices allows you to prevent unmanaged iOS devices from accessing enterprise services through browsers and native applications.


Diagram — Device Trust flow

DT_flow_3PiOSMDM_smaller



Key benefits
  • Ensures that only iOS devices managed by your chosen Mobile Device Management (MDM) provider can access SAML 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 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 or later, managed by your MDM provider

Caveats
  • Device Trust does not apply to apps accessed via chiclets 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 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.
  • 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.

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

Procedures

This procedure has three main parts:

Part Ⓐ — Enable the global Device Trust setting for your org
  1. (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 org. This is in addition to the global Device Trust setting that you enable in this procedure.
  2. From the Okta Admin dashboard, go to Security > Device Trust.
  3. In the Mobile Device Trust section, click Edit.
  4. In the dialog box that opens, select Enable Mobile Device Trust.
  5. In Trust is established by, select your Mobile Device Management (MDM) provider.
  6. Depending on the provider you select, unenrolled end users are shown either an MDM-specific or a generic enrollment prompt. Screenshot

    DT_SelectMDMuserSees_2

  7. 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.
  8. Click Save and generate secret keys. Screenshot
  9. DT_EnableMobileDT_80

  10. Copy the Secret Key value that displays in the Generate Secret Keys window. You'll enter it later in your MDM provider's app configuration as described in Part B. Screenshot
  11. DT_GenSecret_iOS

    Important: Make a note of the secret key, as this is the only time it will appear in Okta. If you generate a new key by clicking Reset iOS secret key, make sure to also update your MDM configuration with the new key.

  12. Proceed to Part B.

Part Ⓑ — Integrate Okta into your third party MDM provider

Click: Important to know before you begin

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 automatically upon enrollment to the 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 on the device through the MDM provider's app store. If Okta Mobile is not 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. Obtain Okta Mobile from the App Store.
  2. Configure your MDM provider to manage Okta Mobile and to install it on end user devices if it is not installed already.
  3. Configure the key/value pair through your MDM provider's managed app configuration:

    Note: The Key/Value pair is case sensitive.

  4. Proceed to Part C.

Part Ⓒ — Configure app Sign On policy rules in Okta

Click: Important to know before you begin
  • Only Super and App admins can configure app Sign On policies.
  • 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 or not the device is trusted. If Okta assesses the device to be untrusted, one of the following occurs:
    • If you configured a Sign On policy rule to deny untrusted devices, users are prompted to enroll in your MDM provider.
    • If you configured a Sign On policy rule to issue an MFA challenge to users with untrusted devices, such users are challenged with MFA.
  • (Applies only during the Early Access phase of this Device Trust solution) If you decide to ask Okta Support to disable this Device Trust solution for your org (which is separate from the global Device Trust setting that you enabled in Part B), make sure to first change the Device Trust setting in the app sign on policy rules to Any (Applications > app > Sign 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.

Overview

By default, all Client options in the App Sign On Rule dialog box are pre-selected. Notice that the Trusted and Not trusted options in the Device Trust section are not available unless you deselect all options in the Client section except the following, as applicable:

  • Web browser or Modern Auth client
  • iOS and/or Windows, as applicable

To configure more granular access to the app, selectively apply conditions as you create one or more prioritized rules based on:

  • Who users are and/or the groups to which they belong
  • Whether they are on or off network or within a defined network zone
  • Whether or not their devices are Trusted
Whitelist and blacklist approaches to creating Sign On policy rules

Typical approaches to creating and prioritizing rules often employ whitelist and blacklist concepts:

  • In a whitelist approach, you might do the following:
    1. Create one or more permissive 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 Okta's Default Rule. The Default Rule is applied to users who don't match any of the more restrictive rules that have higher priority.
  • In a blacklist approach, you create one or more restrictive rules designed to deny app access to — or increase the authentication requirements for (MFA, Device Trust) — everyone except certain users/groups connected to a specified network or network range from specified client(s) and platform(s). Users able to pass through the restrictive rule(s) are then subject to the Default policy, which is designed to allow access to everyone.

Procedure

Note: These examples show 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 is not 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.

These examples illustrate 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 1 – Blacklist

Example 1, Rule 1 — Web browser or Modern Auth; iOS; Not trusted; Deny access

Screenshot

E1_R1_Web_iOS_NoT_Denied

  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 both 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 needs to be the same for both the rules you create in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client is 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

  5. Configure Device Trust.
  6. ¨Any is unselected.

    ¨Trusted is unselected.

    þNot trusted is selected.

ACTIONS

  1. Configure Access:
  2. Denied is selected.

  3. Click Save.
  4. Create Rule 2.
Example 1, Rule 2 — Web browser or Modern Auth; All platforms; Any Trust; Allow access + MFA

Screenshot

E1_R2_Web_AllP_AnyT_MFA

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1 of this example. The People option needs to be the same for both rules in this example.
  2. Under Location, select the same Location option that you selected in Rule 1 of this example. The Location option needs to be the same for both rules in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client is selected.

    ¨Exchange ActiveSync client is unselected.

    Mobile:

    þiOS is selected.

    þAndroid is selected.

    þOther mobile is selected.

    Desktop:

    þWindows is selected.

    þmacOS is selected.

    þOther desktop is selected.

  5. Configure Device Trust.
  6. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access:
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.
Example 1, Rule 3: Default sign on rule – Any client, All platforms; Any Trust; Allow access

The Default sign on rule is already created for you; you do not need to duplicate it. This rule cannot be edited.

Screenshot

SignOnPolicies_DefaultRule


Example 2 – Whitelist

Example 2, Rule 1 – Web browser or Modern Auth; iOS; Trusted; Allow access + MFA

Screenshot

E2_R2_Web-iOS-Trust-Allow-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 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.

  5. Configure Device Trust.
  6. Note: In order for options in the Device Trust section to be available, you must deselect all options in the Client section except Web browser or Modern Auth client and iOS.

    ¨Any is unselected.

    þTrusted is selected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access:
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.
  4. Create Rule 2.
Example 2, Rule 2 – Web browser or Modern Auth; All platforms except iOS; Any Trust; Allow access + MFA

Screenshot

Web_AllButiOS_AnyT_Allow-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 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

  5. Configure Device Trust.
  6. Note: In order for options in the Device Trust section to be available, you must deselect all options in the Client section except Web browser or Modern Auth client and iOS.

    þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.
  4. Create Rule 3.
Example 2, Rule 3 – Web browser or Modern Auth; iOS; Not Trusted; Deny access

Screenshot

R3_Web_iOS_NoTrust_Denied

  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.

    ¨Android is unselected.

    ¨Other mobile is unselected.

    Desktop:

    ¨Windows is unselected.

    ¨macOS is unselected.

    ¨Other desktop is unselected.

  5. Configure Device Trust.
  6. Note: In order for options in the Device Trust section to be available, you must deselect all options in the Client section except Web browser or Modern Auth client and iOS.

    ¨Any is unselected.

    ¨Trusted is unselected.

    þNot trusted is selected.

ACTIONS

  1. Configure Access.
  2. Denied is selected.

  3. Click Save.
Example 2, Rule 4: Default sign on rule – Any client, All platforms; Any Trust; Allow access

The Default sign on rule is already created for you; you do not need to duplicate it. This rule cannot be edited.

Screenshot

SignOnPolicies_DefaultRule



Known Issue

If Intune is your MDM provider and also federated to Okta and you apply a Not Trusted - Deny sign-on policy to an Okta-federated O365 app, end users trying to access the app from unmanaged iOS devices become stuck in a redirect loop. This happens because your O365 app sign-on policy is applied also to Intune. Okta is investigating this issue.


Post a Comment