Configure Oka Device Trust for Native Apps and Safari on OMM-managed iOS devices Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a0000005udusaq&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fconfigure-oka-device-trust-for-native-apps-and-safari-on-omm-managed-ios-devices-849339898
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 Oka Device Trust for Native Apps and Safari on OMM-managed iOS 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 OMM-managed iOS devices


 

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.

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

Requirements
  • 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 app 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)

Procedure

This procedure has two parts:

Part Ⓐ — Enable the global Device Trust setting for your org
  1. Configure OMM for your org.
  2. From the Okta Admin dashboard, go to Security > Device Trust.
  3. Click Edit.
  4. In the Mobile section, click Enable Mobile Device Trust.
  5. In Trust is establish by..., make sure Okta Mobility Management is shown.
  6. Click Save.

Part Ⓑ — Configure app Sign On policy rules in Okta

By default, all Client options in the App Sign On Rule dialog box are pre-selected to allow users of all client types and platforms to access the app. 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
  • 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
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.

Note: Blacklist approaches currently are not supported with this Device Trust solution.


Procedure

Click: Important to know before you begin
  • Only Super and App admins can configure app Sign On policies.
  • The Sign On policy example below shows how to create Device Trust rules to manage access to Office 365. For other apps, the section If the user's client is any of these is not present.
  • 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.
  • While it is possible to create rules that include the Not trusted condition, Okta will not 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 our without the MFA action.

  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 example as a guide.

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.

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

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 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. 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. ¨Any is unselected.

    þTrusted is selected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access:
  2. Allowed is selected.

  3. þPrompt for factor is selected.

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

Screenshot

DT_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 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. 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. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Allowed is selected.

  3. þPrompt for factor is selected.

  4. Click Save.
Example 2, Rule 3 — Any client; All platforms; Any Trust; Deny access

Screenshot

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

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

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Denied is selected.

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

Screenshot

SignOnPolicies_DefaultRule



Known Issues
  • Box currently is not 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 Security > Device 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 (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.

Caveats
  • Device Trust does not apply to apps accessed via chiclets within Okta Mobile.

  • Okta supports password-less authentication only for Office 365 apps — 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 (OMM-enrolled), end users can access the app. If the device is not 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 are not OMM-enrolled use the iOS Settings app to add a Gmail account to the native Mail app, they are 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 screen, end users see the Okta MDM Configuration page. Advise affected end users to try to configure Gmail again.
  • 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.

Post a Comment