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

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

前提条件

ステップ1：OktaでVMware Identity ManagerをIDプロバイダーとして構成する

ステップ2：VMware Identity ManagerでOktaアプリケーション・ソースを構成する

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

OktaでiOSまたはAndroidのDevice Trustが構成されている場合、ユーザーは、モバイルSSO（iOS）またはモバイルSSO（Android）の認証方法を使用した認証のために、VMware Identity Managerにリダイレクトされます。VMware Identity Managerにより、SAML応答でデバイス状態情報がOktaに返されます。

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

この統合のために、Okta管理コンソールでDevice Trust機能を構成するには、次のタスクを実行する必要があります。

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

VMware Identity ManagerのOktaアプリケーション・ソースの構成で、［Device SSO Response（デバイスのSSO応答）］、［Enable Force Authn Request（強制認証要求を有効にする）］、および［Enable Authentication Failure Notification（認証失敗通知を有効にする）］のプロパティーが［Yes（はい）］に設定されていることを確認します。iOSおよびAndroidデバイスのデバイスの信頼ソリューションでは、これらのプロパティーは要件です。詳細については、「ステップ2：VMware Identity ManagerでOktaアプリケーション・ソースを構成する」を参照してください。

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

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

  1. Okta管理コンソールで、［Security（セキュリティ）］>［Identity Providers（IDプロバイダー）］に移動します。
  2. ［Routing Rules（ルーティングルール）］タブをクリックします。
  3. ［Add Routing Rule（ルーティング・ルールを追加）］をクリックします。
  4. 以下を構成します。

    5. 設定 アクション
    ［Rule Name（ルール名）］ 作成するルールの名前を入力します。
    IF［User's IP is（ユーザーのIP）］ 実装に適している場合は、ルーティングを適用するネットワーク・ゾーンと適用しないネットワーク・ゾーンを指定できます。ここでゾーンを指定するには、少なくとも1つのネットワークゾーンがすでにOktaで定義されている必要があります。詳細については、「ネットワークゾーン」を参照してください。
    ユーザーのデバイス・プラットフォーム：

    実装に応じて、［Any of these devices（これらのデバイスのいずれか）］を選択してから、［iOS］または［Android］、あるいはその両方を選択します。
    AND［User is accessing（ユーザーがアクセスしています）］

    ［Any of the following applications（次のアプリケーションのいずれか）］を選択してから、ルーティング・ルールを適用するアプリケーションを入力します。
    AND［User matches（ユーザーが一致）］

    適切なアクションを選択します。

    • ［Anything（すべて）］。任意のユーザーを指定します。これはデフォルトです。
    • ［Regex on login（ログインに関する正規表現）］。ユーザーのログインに基づいた、照合に使用する有効な正規表現を入力できます。これは、ドメインを指定する場合や、ユーザー属性では照合に不十分な場合に便利です。「IDプロバイダーのルーティング・ルール」を参照してください。
    • ［Domain list on login（ログインに関するドメイン・リスト）］。一致するドメインの一覧を指定します（例：example.com）。ドメイン名に@記号を追加しないでください。複数のドメインを追加できます。文字をエスケープする必要はないことに注意してください。
    • ［User attribute（ユーザー属性）］。左側のリストで属性名を選択し、［Starts with（次から開始：）］リストで比較のタイプを選択して、右側のテキスト・フィールドに一致させる値を入力します。
    THEN［Use this identity provider（このIDプロバイダーを使用）］ 「ステップ1：OktaでVMware Identity ManagerをIDプロバイダーとして構成する」の説明に従って、Oktaで作成したIDプロバイダーを［VMware Identity Manager］に選択します。

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

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

このセクションでは、特にこのVMwareWorkspace ONEとOktaの統合用に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を無効にします。

  1. 管理コンソールで、［Security（セキュリティ）］［Device Trust（デバイスの信頼）］に移動します。
  2. ［iOS Device Trust］または［Android Device Trus］セクションで、［Edit（編集）］をクリックします。
  3. ［Enable [iOS or Android] Device Trust（[iOSまたはAndroid]のDevice Trustを有効化）］を選択します。
  4. ［Trust is established by（信頼の確立元）］で、［VMware］を選択します。
  5. ［Integration type（統合タイプ）］で、［SAML-based (Workspace ONE UEM+vIDM)］を選択します。

  6. ［Next（次へ）］をクリックします。
  7. ［Device Identity provider（デバイスIDプロバイダー）］で、「Oktaでモバイル・デバイス用のIDプロバイダーのルーティング・ルールを構成する」の説明に従いVMware Identity Manager用にOktaで作成したIDプロバイダーを選択します。
  8. （オプション）［Mobile device management provider（モバイル・デバイス管理プロバイダー）］フィールドには、Workspace ONEがデフォルトで事前入力されています。これは必要に応じて変更できます。ここに入力したMDMプロバイダーは、デバイスの登録時にエンド・ユーザーに表示されます。
  9. ［Enrollment link（登録リンク）］フィールドに、未登録のデバイスがあるエンド・ユーザーをリダイレクトするためのWebアドレスを入力します。たとえば、登録手順が記載されたページやWorkspace ONEの登録ページにこれらのユーザーを送ることができます。
  10. ［Save（保存）］をクリックします。

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

  • アプリのサインオンポリシーを構成できるのは、アプリ管理者、組織管理者、およびスーパー管理者のみです。

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

  • このDevice Trustソリューションを組織で無効にするようOktaに依頼する場合は（「OktaでDevice Trustの設定を有効化する」で有効化したDevice Trust設定とは別）、最初にアプリ・サインオン・ポリシー・ルールでDevice Trust設定を［Any（任意）］（［Applications（アプリケーション）］>［app（アプリ）］>［Sign On（サインオン）］）に変更します。この変更を行わず、後でOktaに組織のDevice Trust機能の再有効化を依頼した場合、アプリのサインオン・ポリシー・ルールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。

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

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

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

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

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

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

手順

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

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

許可リストの例

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

<MadCap:dropDownHotspot>Example Rule 1: Web browser; Modern Auth; iOS and/or Android; Trusted; Allow access + MFA </MadCap:dropDownHotspot>

  1. ルールにわかりやすい名前を付けて入力します。
  1. ［PEOPLE（ユーザー）］で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  2. ［LOCATION（ロケーション）］で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  3. ［CLIENT（クライアント）］で、次の設定を構成します。

    4. ［Web browser（Webブラウザー）］：選択

    ［Modern Auth client（Modern Authクライアント）］：選択

    ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］：選択解除

    ［Mobile（モバイル）］

    ［iOS］：選択

    ［Android］：選択

    ［Other mobile（他のモバイル）］：選択解除

    ［Desktop（デスクトップ）］

    ［Windows］：選択解除

    ［macOS］：選択解除

    ［Other desktop（他のデスクトップ）］：選択解除

  4. ［DEVICE TRUST］で以下を構成します。

    5. ［Device Trust（デバイスの信頼）］ セクションの［Trusted（信頼）］と［Not trusted（非信頼）］オプションは、［Client（クライアント）］セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

    • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
    • ［Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））］
    • ［Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））］

    ［Any（すべて）］：選択解除

    ［Trusted（信頼）］：選択解除

    ［Not trusted（非信頼）］：選択解除

  1. ［Access（アクセス）］を構成します。

    2. ［Allowed（許可）］：選択

    ［Prompt for factor（要素をプロンプト）］：選択

  2. ［Save（保存）］をクリックします。
  3. ［Rule 2（ルール2）］を作成します。

<MadCap:dropDownHotspot>Example Rule 2: Web browser; Modern Auth; All platforms except iOS and/or Android; Any Trust; Allow access + MFA </MadCap:dropDownHotspot>

  1. ルールにわかりやすい名前を付けて入力します。

条件

  1. ［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じ［People（ユーザー）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  2. ［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  3. ［CLIENT（クライアント）］で、次の設定を構成します。

    4. ［Web browser（Webブラウザー）］：選択

    ［Modern Auth client（Modern Authクライアント）］：選択

    ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］：選択解除

    ［Mobile（モバイル）］

    ［iOS］：選択解除

    ［Android］：選択

    ［Other mobile（他のモバイル）］：選択

    ［Desktop（デスクトップ）］

    ［Windows］：選択

    ［macOS］：選択

    ［Other desktop（他のデスクトップ）］：選択

  4. ［DEVICE TRUST］で以下を構成します。

    5. ［Device Trust（デバイスの信頼）］ セクションの［Trusted（信頼）］と［Not trusted（非信頼）］オプションは、［Client（クライアント）］セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

    • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
    • ［Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））］
    • ［Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））］

    ［Any（すべて）］：選択

    ［Trusted（信頼）］：選択解除

    ［Not trusted（非信頼）］：選択解除

［Actions（アクション）］

  1. ［Access（アクセス）］を構成します。

    2. ［Allowed（許可）］を選択します。

    ［Prompt for factor（要素をプロンプト）］を選択します。

  2. ［Save（保存）］をクリックします。
  3. ［Rule 3（ルール3）］を作成します。

<MadCap:dropDownHotspot>Example Rule 3: Web browser; Modern Auth; iOS and/or Android; Not Trusted; Deny access</MadCap:dropDownHotspot>

  1. ルールにわかりやすい名前を付けて入力します。

条件

  1. ［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じ［People（ユーザー）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  2. ［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  3. ［CLIENT（クライアント）］で、次の設定を構成します。

    4. ［Web browser（Webブラウザー）］：選択

    ［Modern Auth client（Modern Authクライアント）］：選択

    ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］：選択解除

    ［Mobile（モバイル）］

    ［iOS］：選択

    ［Android］：選択

    ［Other mobile（他のモバイル）］：選択解除

    ［Desktop（デスクトップ）］

    ［Windows］：選択解除

    ［macOS］：選択解除

    ［Other desktop（他のデスクトップ）］：選択解除

  4. ［DEVICE TRUST］で以下を構成します。

    5. ［Device Trust（デバイスの信頼）］ セクションの［Trusted（信頼）］と［Not trusted（非信頼）］オプションは、［Client（クライアント）］セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

    • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
    • ［Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））］
    • ［Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））］

    ［Any（すべて）］：選択解除

    ［Trusted（信頼）］：選択解除

    ［Not trusted（非信頼）］：選択解除

［Actions（アクション）］

  1. ［Access（アクセス）］を構成します。

    2. ［Denied（拒否）］を選択します。

  2. ［Save（保存）］をクリックします。

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

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


VMware Identity Managerでデフォルトのアクセス・ポリシーを構成する

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

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

  1. システム管理者としてVMware Identity Managerコンソールにログインします。
  2. ［Identity & Access Management（IDとアクセスの管理）］タブをクリックしてから、［Policies（ポリシー）］タブをクリックします。
  3. ［Edit Default Access Policy（デフォルトのアクセス・ポリシーの編集）］をクリックします。
  4. ［Edit Policy（ポリシーの編集）］ウィザードで、［Configuration（構成）］をクリックします。
  5. ［Add Policy Rule（ポリシー・ルールを追加）］をクリックしてiOSデバイス用のポリシー・ルールを作成します。
    1. 最初の認証方法としてモバイルSSO（iOS）を設定し、フォールバック認証方法としてOkta認証を設定します。

      2. ユーザーのネットワーク範囲が［ALL RANGES（すべての範囲）］でiOSからコンテンツにアクセスしているのであれば、［Authenticate using（認証に使用）］アクションを実行すると、ユーザーは［Mobile SSO (iOS)（モバイルSSO（iOS））］で認証できるようになります。

      前述の方法が失敗する、または適用できない場合は、ユーザーは［Okta Auth Method（Okta認証方法）］で認証できます。

      注：［Okta Auth Method（Okta認証方法）］については、「VMware Identity Managerで新しいIDプロバイダーの作成を完了する」でOkta IdP用に作成した認証方法を選択します。
    2. ［Save（保存）］をクリックします。
  6. ［Add Policy Rule（ポリシー・ルールを追加）］をクリックしてAndroidデバイス用に同様のポリシー・ルールを作成します。
    1. 最初の認証方法としてモバイルSSO（Android）を設定し、フォールバック認証方法としてOkta認証を設定します。

      ユーザーのネットワーク範囲が［ALL RANGES（すべての範囲）］でAndroidからコンテンツにアクセスしているのであれば、［Mobile SSO (Android)（モバイルSSO（Android））］で［Authenticate using（認証に使用）］アクションを実行します。

      前述の方法が失敗する、または適用できない場合は、ユーザーは［Okta Auth Method（Okta認証方法）］で認証できます。

    2. ［Save（保存）］をクリックします。
  7. 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 Auth Method（Okta認証方法）］を使用します。

  8. ポリシールールを上から順に次の順序で並べます。
    1. Workspace ONEアプリまたはHubアプリ iOSまたはAndroid
    2. iOSまたはAndroid
    3. ［Web browser（Webブラウザー）］

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

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

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

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

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

    例：

  6. 割り当てを保存します。

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