ステップ3：iOSおよびAndroidデバイス用にOktaでルーティングルール、Device Trust、クライアントアクセスポリシーを構成する

これは早期アクセス機能です。有効にするには、Okta Admin Consoleで設定（Settings） > 機能（Features）の順に移動して、モバイルプラットフォームのWorkspace1 Device Trustをオンにします。

前提条件

ステップ1：Okta でWorkspace ONE AccessをIDプロバイダーとして構成する

ステップ2：Workspace ONE Access でOktaアプリケーションソースを構成する

Okta Device Trust機能を使用すると、OktaとWorkspace™ ONE™の統合におけるiOSおよびAndroidデバイス用の条件付きアクセスポリシーの管理が簡素化されます。アプリのDevice Trustとアクセスポリシーは、Okta Admin Consoleでのみ構成できます。

OktaでiOSまたはAndroid向けDevice Trustが構成されている場合、ユーザーは、モバイルSSO（iOS）またはモバイルSSO（Android）の認証方法を使用した認証のために、Workspace ONE Accessにリダイレクトされます。Workspace ONE Accessにより、SAMLレスポンスでデバイスポスチャ情報がOktaに返されます。

次に、Oktaで構成したアクセスポリシーによって、アプリケーションにアクセスするためにデバイスを信頼する必要があるかどうかが決定されます。デバイスが信頼できない場合は、デバイス登録ページが表示されます。

この統合のために、Okta Admin ConsoleでDevice Trust機能を構成するには、次のタスクを実行する必要があります。

iOSおよびAndroidデバイス用にOkta IDプロバイダーのルーティングルールを構成します。
OktaでグローバルなDevice Trust設定を有効にします。
Oktaでアプリサインオンポリシールールを構成します。
Workspace ONE Accessでデフォルトのアクセスポリシーを構成します。

Workspace ONE AccessのOktaアプリケーションソースの構成で、［デバイスのSSO応答］、［強制認証リクエストを有効にする］、および［認証失敗通知を有効にする］のプロパティがはい（Yes）に設定されていることを確認します。iOSおよびAndroidデバイスのDevice Trustソリューションでは、これらのプロパティは要件です。詳細については、「ステップ2：Workspace ONE Access でOktaアプリケーションソースを構成する」を参照してください。

Oktaでモバイルデバイス用のIDプロバイダーのルーティングルールを構成する

このOktaとWorkspace ONEの統合専用に、iOSとAndroid用のOkta IdPルーティングルールを構成します。構成すると、これらのルーティングルールはアプリケーションのサインオンポリシーと連携して、iOSまたはAndroidデバイス、あるいはその両方のデバイスからの認証リクエストをWorkspace ONEにリダイレクトします。

OktaのAdmin Consoleで、セキュリティ（Security） > IDプロバイダー（Identity Providers）に移動します。
ルーティングルール（Routing Rules）タブをクリックします。
ルーティングルールを追加（Add Routing Rule）をクリックします。

以下を構成します。

設定	アクション
ルール名（Rule Name）	作成するルールの名前を入力します。
ユーザーのIP（IF ［User's IP is）］（IF User's IP is）	実装に適している場合は、ルーティングを適用するネットワークゾーンと適用しないネットワークゾーンを指定できます。ここでゾーンを指定するには、少なくとも1つのネットワークゾーンがすでにOktaで定義されている必要があります。詳細については、「ネットワークセキュリティ」を参照してください。
ユーザーのプラットフォーム（AND ［User's device platform is）］（AND User's device platform is）	実装に応じて、これらのデバイスのいずれか（Any of these devices）を選択してから、iOSまたはAndroid、あるいはその両方を選択します。
ユーザーがアクセスしています（AND［User is accessing）］（AND User is accessing）	次のアプリケーションのいずれか（Any of the following applications）を選択してから、ルーティングルールを適用するアプリケーションを入力します。
ユーザーが一致（AND［User matches）］（AND User matches）	適切なアクションを選択します。すべて（Anything）。任意のユーザーを指定します。これはデフォルトです。ログインに関する正規表現（Regex on login）。ユーザーのログインに基づいた、照合に使用する有効な正規表現を入力できます。これは、ドメインを指定する場合や、ユーザー属性では照合に不十分な場合に便利です。詳細については、「IDプロバイダーの検出」を参照してください。ログインに関するドメインリスト（Domain list on login）。一致するドメインの一覧を指定します（例：`example.com`）。ドメイン名に@記号を追加しないでください。複数のドメインを追加できます。文字をエスケープする必要はないことに注意してください。ユーザー属性（User attribute）。左側のリストで属性名を選択し、次から開始：（Starts with）リストで比較のタイプを選択して、右側のテキストフィールドに一致させる値を入力します。
このIDプロバイダーを使用（THEN［Use this identity provider）］（THEN Use this identity provider）	「ステップ1：Okta でWorkspace ONE AccessをIDプロバイダーとして構成する」の説明に従って、 Workspace ONE Access 用にOktaで作成したIDプロバイダーを選択します。

ルールを作成（Create Rule）をクリックします。

OktaでDevice Trustの設定を有効化する

このセクションでは、このOktaとWorkspace ONEの統合専用のDevice Trustを有効化する方法について説明します。構成すると、これらの設定がIDPルーティングルールと連携して、iOSまたはAndroidデバイス、あるいはその両方のデバイスとターゲットアプリケーションからの認証リクエストをWorkspace ONEにリダイレクトします。その他の認証リクエストは、デフォルトのルーティングルールで処理されます。

信頼されたデバイスを許可するアプリサインオンポリシー（アプリケーション（Applications） > [app] > サインオン（Sign On））も構成している場合は、セキュリティ（Security） > Device Trust ページでDevice Trust設定を無効にしないでください。無効にすると、Device Trustの設定に矛盾が生じた状態になります。

OrgのDevice Trustを無効にするには、まず、Device Trustの設定を含むアプリのサインオンポリシーをすべて削除してから、セキュリティ（Security） > Device Trust でDevice Trustを無効にします。

Admin Consoleでセキュリティ（Security） > Device Trust に移動します。
iOS向けDevice Trust（iOS Device Trust）またはAndroid向けDevice Trust（Android Device Trust）セクションで、編集（Edit）をクリックします。
[iOSまたはAndroid]向けDevice Trustを有効化（Enable [iOS or Android] Device Trust）を選択します。
信頼の確立元（Trust is established by）で、Workspace ONEを選択します。
統合タイプ（Integration type）で、Workspace ONE UEMWorkspace ONE UEM+vIDM)］を選択します。
次へ（Next）をクリックします。
デバイスIDプロバイダー（Device Identity provider）で、「Oktaでモバイルデバイス用のIDプロバイダーのルーティングルールを構成する」の説明に従いWorkspace ONE Access用にOktaで作成したIDプロバイダーを選択します。
（オプション）モバイルデバイス管理プロバイダー（Mobile device management provider）（the Mobile device management provider）フィールドには、Workspace ONEがデフォルトで事前入力されています。これは必要に応じて変更できます。ここに入力したMDMプロバイダーは、デバイス登録時にエンドユーザーに表示されます。
登録リンク（Enrollment link）フィールドに、未登録のデバイスがあるエンドユーザーをリダイレクトするためのWebアドレスを入力します。たとえば、登録手順が記載されたページやWorkspace ONEの登録ページにこれらのユーザーを送ることができます。
保存（Save）をクリックします。

Oktaでアプリサインオンポリシールールを構成する

アプリのサインオンポリシーを構成できるのは、アプリ管理者、Org管理者、およびスーパー管理者のみです。
信頼されたデバイスを許可するアプリサインオンポリシー（アプリケーション（Applications） > [app] > サインオン（Sign On））も構成している場合は、セキュリティ（Security） > Device Trust ページでDevice Trust設定を無効にしないでください。無効にすると、Device Trustの設定に矛盾が生じた状態になります。

OrgのDevice Trustを無効にするには、まず、Device Trustの設定を含むアプリのサインオンポリシーをすべて削除してから、セキュリティ（Security） > Device Trust でDevice Trustを無効にします。
このDevice TrustソリューションをOrgで無効にするようOktaに依頼する場合は（「でDevice Trustの設定を有効化するOkta 」で有効化したDevice Trust設定とは別）、最初にアプリサインオンポリシールールでDevice Trust設定を任意（Any）（アプリケーション > アプリ > サインオン）に変更します。この変更を行わず、後でOktaにorgのDevice Trust機能の再有効化を依頼した場合、アプリサインオンポリシールールのDevice Trustの設定がすぐに有効になるという予期しない動作が発生します。

アプリサインオンポリシールールについて

アプリサインオンルール（［App Sign On Rule）］ダイアログボックス内のすべてのクライアントオプションはデフォルトで事前選択されています。アプリへのアクセスを詳細設定するには、以下を反映させるルールを作成します。

対象となるユーザー、または対象者が属するグループ
対象者がネットワークに接続しているか、接続していないか、定義されたネットワークゾーンに属しているか
対象者のデバイスで実行されているクライアントのタイプ（Office 365アプリのみ）
対象者のモバイルまたはデスクトップデバイスのプラットフォーム
対象者のデバイスが信頼されているかどうか

サインオンポリシールールへの許可リストによるアプローチ

アプリへのアクセスを許可するシナリオをサポートする1つまたは複数の許可ルールを作成し、これらのルールに最高優先度を割り当てます。
ステップ1で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。

注:

アプリサインオンポリシールールの作成についての重要なセキュリティ情報は、「アプリのサインオンポリシーについて」を参照してください。

手順

注：以下の許可リストの例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。他のアプリでは、［If the user's client is any of these（ユーザーのクライアントが次のいずれかに該当する場合）］セクションは表示されません。

Admin Consoleで、アプリケーション（Applications） > アプリケーション（Applications）に移動します。
Device Trustで保護するSAMLまたはWS-Fed対応のアプリをクリックします。
サインオン（Sign On）タブをクリックします。
下にスクロールしてサインオンポリシー（Sign On Policy）に移動し、ルールを追加（Add Rule）をクリックします。
次の許可リストの例を参考にしてルールを1つ以上作成します。

許可リストの例

非信頼デバイスを使用するユーザーは、Workspace ONEの登録に誘導されるか、このステップで構成した登録リンクの宛先にリダイレクトされます。

ルール例1：Webブラウザー、先進認証、iOSまたはAndroidあるいはその両方、信頼できる、アクセスを許可 +多要素認証

ルールにわかりやすい名前を付けて入力します。
ユーザー（PEOPLE）で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
ロケーション（LOCATION）で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
クライアント（CLIENT）で、次の設定を構成します。
- Webブラウザー（Web browser）：選択
- Modern Authクライアント（Modern Auth client）：選択
- Exchange ActiveSyncクライアント（Exchange ActiveSync client）：選択解除
- モバイル（Mobile）
- iOS ：選択済み。
- Android を選択済み
- 他のモバイル（Other mobile）：選択解除
- デスクトップ
- Windows ：選択解除
- macOS ：選択解除
- 他のデスクトップ（Other desktop）：選択解除
Device Trust（DEVICE TRUST）で以下を構成します。
- Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
  - Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
  - Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
  - Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
- すべて（Any）：選択解除
- 信頼（Trusted）：選択解除
- 非信頼（［Not trusted）］：選択解除
アクセス（Access）を構成します。
- 許可（Allowed）：選択
- 要素をプロンプト（Prompt for factor）：選択
保存（Save）をクリックします。
ルール2（Rule 2）を作成します。

ルール例2：Webブラウザー、先進認証、iOSおよび/またはAndroidを除くすべてのプラットフォーム、任意の信頼、アクセスを許可 + 多要素認証

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
クライアント（CLIENT）で、次の設定を構成します。
- Webブラウザー（Web browser）：選択
- Modern Authクライアント（Modern Auth client）：選択
- Exchange ActiveSyncクライアント（Exchange ActiveSync client）：選択解除
- モバイル（Mobile）
- iOS ：選択解除
- Android を選択済み
- 他のモバイル（Other mobile）：選択
- デスクトップ
- Windows ：選択済み
- macOS ：選択済み
- 他のデスクトップ（Other desktop）：選択
Device Trust（DEVICE TRUST）で以下を構成します。
- Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
  - Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
  - Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
  - Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
- すべて（Any）：選択
- 信頼（Trusted）：選択解除
- 非信頼（Not trusted）：選択解除
アクセス（Access）を構成します。
- 許可（Allowed）を選択します。
- 要素をプロンプト（Prompt for factor）を選択します。
保存（Save）をクリックします。
ルール3（Rule 3）を作成します。

ルール例3：Webブラウザー、先進認証、iOSまたはAndroidあるいはその両方、信頼できない、アクセスを拒否

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
クライアント（CLIENT）で、次の設定を構成します。
- Webブラウザー（Web browser）：選択
- Modern Authクライアント（Modern Auth client）：選択
- Exchange ActiveSyncクライアント（Exchange ActiveSync client）：選択解除
- モバイル（Mobile）
- iOS ：選択済み
- Android ：選択済み
- 他のモバイル（Other mobile）：選択解除
- デスクトップ
- Windows ：選択解除
- macOS ：選択解除
- 他のデスクトップ（Other desktop）：選択解除
Device Trust（DEVICE TRUST）で以下を構成します。
- Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
  - Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
  - Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
  - Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
- すべて（Any）：選択解除
- 信頼（Trusted）：選択解除
- 非信頼（Not trusted）：選択解除
アクセス（Access）を構成します。
拒否（Denied）を選択します。
保存（Save）をクリックします。

例：Rule 4 - Default sign on rule – Any client, All platforms; Any Trust; Allow access

デフォルトのサインオンルールはすでに作成されており、編集できません。この例では、デフォルトルールがルール3により実質的に無効化されているため、デフォルトルールに到達することはありません。

Workspace ONE Accessでデフォルトのアクセスポリシーを構成する

Workspace ONE Accessでデフォルトのアクセスポリシーを更新して、iOSおよびAndroidデバイスのポリシールールを含めます。デフォルトのアクセスポリシーがWorkspace ONEカタログの動作を管理します。モバイルSSOポリシールールの構成は必須です。これはDevice Trust情報をアプリに渡すアクションの一部であるためです。

認証方法としてモバイルSSOを使用し、フォールバック方法としてOkta認証を使用して、iOSおよびAndroidのポリシールールを作成します。Workspace ONEアプリとハブアプリ、およびWebブラウザーのルールも構成します。ポリシールールが正しい順序になっていることを確認してください。

システム管理者として、Workspace ONE Accessコンソールにログインします。
IDとアクセスの管理（Identity & Access Management）タブをクリックしてから、ポリシー（Policies）タブをクリックします。
デフォルトのアクセスポリシーの編集（Edit Default Access Policy）をクリックします。
ポリシーの編集（Edit Policy）ウィザードで、構成（Configuration）をクリックします。
ポリシールールを追加（Add Policy Rule）をクリックしてiOSデバイス用のポリシールールを作成します。
1. 最初の認証方法としてモバイルSSO（iOS）を設定し、フォールバック認証方法としてOkta認証を設定します。
  
  ユーザーのネットワーク範囲がすべての範囲（ALL RANGES）で iOS からコンテンツにアクセスしているのであれば、認証に使用（Authenticate using）アクションを実行すると、ユーザーはモバイルSSO（iOS）（Mobile SSO (iOS)）で認証できるようになります。
  
  前述の方法が失敗する、または適用できない場合は、ユーザーはOkta認証方法（Okta Auth Method）で認証できます。
  
  注：Okta認証方法では、「で新しいIDプロバイダーの作成を完了するWorkspace ONE Access 」でOkta のIdP用に作成した認証方法を選択します。
2. 保存（Save）をクリックします。
ポリシールールを追加（Add Policy Rule）をクリックしてAndroidデバイス用に同様のポリシールールを作成します。
1. 最初の認証方法としてモバイルSSO（Android）を設定し、フォールバック認証方法としてOkta認証を設定します。
  
  ユーザーのネットワーク範囲がすべての範囲（ALL RANGES）で Android からコンテンツにアクセスしているのであれば、モバイルSSO（Android）（Mobile SSO (Android)）で認証に使用（Authenticate using）アクションを実行します。
  
  前述の方法が失敗する、または適用できない場合は、ユーザーはOkta認証方法（Okta Auth Method）で認証できます。
2. 保存（Save）をクリックします。
Workspace ONEアプリとハブアプリのポリシールールを構成します。
1. Workspace ONEアプリとハブアプリのポリシールールをクリックして編集します。
2. ルールを構成します。
  
  ユーザーのネットワーク範囲がすべての範囲（ALL RANGES）で Workspace ONEアプリまたはハブアプリからコンテンツにアクセスしているのであれば、認証に使用（Authenticate using）アクションを実行します。
  
  Mobile SSO (for iOS)（モバイルSSO（iOS向け））で
  
  前述の方法が失敗する、または適用できない場合は、ユーザーはMobile SSO (for Android)（モバイルSSO（Android向け））で認証できます。
  
  前述の方法が失敗する、または適用できない場合は、Okta認証方法（Okta Auth Method）を使用します。
ポリシールールを上から順に次の順序で並べます。
1. Workspace ONEアプリまたはHubアプリ、iOSまたはAndroid
2. iOSまたはAndroid
3. Webブラウザー（Web browser）

ネイティブAndroidアプリの構成設定方法の例

Androidデバイスのユーザーに最高のユーザーエクスペリエンスを提供するために、AndroidモバイルSSOフローの特定の設定を構成できます。

ネイティブのAndroidアプリでは、Workspace ONEトンネルをダウンロードしてエンドユーザーのデバイスにインストールする必要があります。Workspace ONEとOktaの統合環境のベストプラクティスとして、各ネイティブAndroidアプリの自動デプロイメント設定を構成して、ユーザーの登録後にアプリとトンネルが自動的にユーザーのデバイスにデプロイされるようにします。アプリの管理対象アクセスも有効にします。

これらの設定は、Workspace ONEコンソールで構成します。

Workspace ONE UEMでアプリケーションとブック（Apps & Books） > アプリケーション（Applications） > ネイティブ（Native）ページに移動します。
アプリ名をクリックします。
割り当て（Assign）をクリックします。
割り当てを追加（Add Assignment）をクリックして新しい割り当てを追加するか、編集する割り当てを選択して編集（Edit）をクリックします。
必要に応じて割り当てを構成し、ベストプラクティスとして次のように選択します。
- アプリの配信方法（［App Delivery Method）］：自動（AUTO）
- 管理アクセス（［Managed Access）］：有効（ENABLED）
- アプリのトンネリング（［App Tunneling）］：有効（ENABLED）
アプリのトンネリング（［App Tunneling）］を有効にする場合は、アプリで使用するVPN構成プロファイルも選択する必要があります。

例：
割り当てを保存します。

ユーザーがデバイスを登録すると、アプリがカタログに表示されます。アプリのアイコンは、トンネルが含まれていることを示しています。ユーザーがアプリをインストールすると、アプリとトンネルの両方がインストールされます。