ステップ3:iOSおよびAndroidデバイス用にOktaでルーティングルール、Device Trust、クライアントアクセスポリシーを構成する
これは早期アクセス機能です。有効にするには、Okta Admin Consoleで[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 Admin Consoleでのみ構成できます。
OktaでiOSまたはAndroidのDevice Trustが構成されている場合、ユーザーは、モバイルSSO(iOS)またはモバイルSSO(Android)の認証方法を使用した認証のために、VMware Identity Managerにリダイレクトされます。VMware Identity Managerにより、SAMLレスポンスでデバイス状態情報がOktaに返されます。
次に、Oktaで構成したアクセスポリシーによって、アプリケーションにアクセスするためにデバイスを信頼する必要があるかどうかが決定されます。デバイスが信頼できない場合は、デバイス登録ページが表示されます。
この統合のために、Okta Admin ConsoleでDevice Trust機能を構成するには、次のタスクを実行する必要があります。
- iOSおよびAndroidデバイス用にOkta IDプロバイダーのルーティングルールを構成します。
- OktaでグローバルなDevice Trust設定を有効にします。
- アプリサインオンポリシールールを構成します。
- VMware Identity Managerでデフォルトのアクセスポリシーを構成します。
VMware Identity ManagerのOktaアプリケーションソースの構成で、[Device SSO Response(デバイスのSSO応答)]、[Enable Force Authn Request(強制認証リクエストを有効にする)]、および[Enable Authentication Failure Notification(認証失敗通知を有効にする)]のプロパティーが[Yes(はい)]に設定されていることを確認します。iOSおよびAndroidデバイスのDevice Trustソリューションでは、これらのプロパティーは要件です。詳細については、「ステップ2:VMware Identity ManagerでOktaアプリケーションソースを構成する」を参照してください。
モバイルデバイス用にOktaでIDプロバイダーのルーティングルールを構成する
このVMwareWorkspace ONEとOktaの統合専用に、iOSとAndroid用のOkta IdPルーティングルールを構成します。構成すると、これらのルーティングルールはアプリケーションのサインオンポリシーと連携して、iOSまたはAndroidデバイス、あるいはその両方のデバイスからの認証リクエストをWorkspace ONEにリダイレクトします。
- Okta Admin Consoleで に移動します。
- [Routing Rules(ルーティングルール)]タブをクリックします。
- [Add Routing Rule(ルーティングルールを追加)]をクリックします。
- 以下を構成します。
設定 アクション Rule Name(ルール名) 作成するルールの名前を入力します。 IF [User's IP is(ユーザーのIP)] 実装に適している場合は、ルーティングを適用するネットワークゾーンと適用しないネットワークゾーンを指定できます。ここでゾーンを指定するには、少なくとも1つのネットワークゾーンがすでにOktaで定義されている必要があります。詳細については、「ネットワークゾーン」を参照してください。 AND [User's device platform is(ユーザーのプラットフォーム)] 実装に応じて、[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]に選択します。 - [Create Rule(ルールを作成)]をクリックします。
OktaでDevice Trustの設定を有効化する
このセクションでは、特にこのVMwareWorkspace ONEとOktaの統合向けにDevice Trustを有効化する方法について説明します。構成すると、これらの設定がIDPルーティングルールと連携して、iOSまたはAndroidデバイス、あるいはその両方のデバイスとターゲットアプリケーションからの認証リクエストをWorkspace ONEにリダイレクトします。その他の認証リクエストは、デフォルトのルーティングルールで処理されます。
信頼されたデバイスを許可するアプリサインオンポリシー(
)も構成している場合は、 ページでDevice Trust設定を無効にしないでください。無効にすると、Device Trustの設定に矛盾が生じた状態になります。OrgのDevice Trustを無効にするには、まず、Device Trustの設定を含むアプリのサインオンポリシーをすべて削除してから、 でDevice Trustを無効にします。- Admin Consoleで、 に移動します。
- [iOS Device Trust(iOS Device Trust)]または[Android Device Trust(AndroidDevice Trust)]セクションで、[Edit(編集)]をクリックします。
- [Enable [iOS or Android] Device Trust([iOSまたはAndroid]のDevice Trustを有効化)]を選択します。
- [Trust is established by(信頼の確立元)]で、[VMware]を選択します。
- [Integration type(統合タイプ)]で、[SAML-based (Workspace ONE UEM+vIDM)]を選択します。
- [Next(次へ)]をクリックします。
- [Device Identity provider(デバイスIDプロバイダー)]で、「Oktaでモバイルデバイス用のIDプロバイダーのルーティングルールを構成する」の説明に従いVMware Identity Manager用にOktaで作成したIDプロバイダーを選択します。
- (オプション)[Mobile device management provider(モバイルデバイス管理プロバイダー)]フィールドには、Workspace ONEがデフォルトで事前入力されています。これは必要に応じて変更できます。ここに入力したMDMプロバイダーは、デバイス登録時にエンドユーザーに表示されます。
- [Enrollment link(登録リンク)]フィールドに、未登録のデバイスがあるエンドユーザーをリダイレクトするためのWebアドレスを入力します。たとえば、登録手順が記載されたページやWorkspace ONEの登録ページにこれらのユーザーを送ることができます。
- [Save(保存)]をクリックします。
Oktaでアプリサインオンポリシールールを構成する
- アプリのサインオンポリシーを構成できるのは、アプリ管理者、Org管理者、およびスーパー管理者のみです。
-
信頼されたデバイスを許可するアプリサインオンポリシー(
)も構成している場合は、 ページでDevice Trust設定を無効にしないでください。無効にすると、Device Trustの設定に矛盾が生じた状態になります。OrgのDevice Trustを無効にするには、まず、Device Trustの設定を含むアプリのサインオンポリシーをすべて削除してから、 でDevice Trustを無効にします。 - このDevice TrustソリューションをOrgで無効にするようOktaに依頼する場合は(「OktaでDevice Trustの設定を有効化する」で有効化したDevice Trust設定とは別)、最初にアプリサインオンポリシールールでDevice Trust設定を[Any(任意)]([Applications(アプリケーション)]>[app(アプリ)]>[Sign On(サインオン)])に変更します。この変更を行わず、後で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で、 に移動します。
- Device Trustで保護するSAMLまたはWS-Fed対応のアプリをクリックします。
- [Sign On(サインオン)]タブをクリックします。
- 下にスクロールして[Sign On Policy(サインオンポリシー)]に移動し、[Add Rule(ルールを追加)]をクリックします。
- 次の許可リストの例を参考にしてルールを1つ以上作成します。
許可リストの例
非信頼デバイスを使用するユーザーは、Workspace ONEの登録に誘導されるか、このステップで構成した登録リンクの宛先にリダイレクトされます。
ルール例1:Webブラウザー、先進認証、iOSまたはAndroidあるいはその両方、信頼できる、アクセスを許可 +多要素認証
- ルールにわかりやすい名前を付けて入力します。
- [PEOPLE(ユーザー)]で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Web browser(Webブラウザー)]:選択
- [Modern Auth client(Modern Authクライアント)]:選択
- [Exchange ActiveSync client(Exchange ActiveSyncクライアント)]:選択解除
- [Mobile(モバイル)]
- [iOS]:選択
- [Android]:選択
- [Other mobile(他のモバイル)]:選択解除
- [Desktop(デスクトップ)]
- [Windows]:選択解除
- [macOS]:選択解除
- [Other desktop(他のデスクトップ)]:選択解除
- [Device Trust(Device Trust)]で以下を構成します。
[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(非信頼)]:選択解除
- [Access(アクセス)]を構成します。
- [Allowed(許可)]:選択
- [Prompt for factor(要素をプロンプト)]:選択
- [Save(保存)]をクリックします。
- [Rule 2(ルール2)]を作成します。
ルール例2:Webブラウザー、先進認証、iOSおよび/またはAndroidを除くすべてのプラットフォーム、任意の信頼、アクセスを許可 + 多要素認証
- ルールの記述名を入力します。
- [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Web browser(Webブラウザー)]:選択
- [Modern Auth client(Modern Authクライアント)]:選択
- [Exchange ActiveSync client(Exchange ActiveSyncクライアント)]:選択解除
- [Mobile(モバイル)]
- [iOS]:選択解除
- [Android]:選択
- [Other mobile(他のモバイル)]:選択
- [Desktop(デスクトップ)]
- [Windows]:選択
- [macOS]:選択
- [Other desktop(他のデスクトップ)]:選択
- [Device Trust(Device Trust)]で以下を構成します。
[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(非信頼)]:選択解除
- [Access(アクセス)]を構成します。
- [Allowed(許可)]を選択します。
- [Prompt for factor(要素をプロンプト)]を選択します。
- [Save(保存)]をクリックします。
- [Rule 3(ルール3)]を作成します。
ルール例3:Webブラウザー、先進認証、iOSまたはAndroidあるいはその両方、信頼できない、アクセスを拒否
- ルールの記述名を入力します。
- [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Web browser(Webブラウザー)]:選択
- [Modern Auth client(Modern Authクライアント)]:選択
- [Exchange ActiveSync client(Exchange ActiveSyncクライアント)]:選択解除
- [Mobile(モバイル)]
- [iOS]:選択
- [Android]:選択
- [Other mobile(他のモバイル)]:選択解除
- [Desktop(デスクトップ)]
- [Windows]:選択解除
- [macOS]:選択解除
- [Other desktop(他のデスクトップ)]:選択解除
- [Device Trust(Device Trust)]で以下を構成します。
[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(非信頼)]:選択解除
- [Access(アクセス)]を構成します。
[Denied(拒否)]を選択します。
- [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ポリシールールの構成は必須です。これはDevice Trust情報をアプリに渡すアクションの一部であるためです。
認証方法としてモバイルSSOを使用し、フォールバック方法としてOkta認証を使用して、iOSおよびAndroidのポリシールールを作成します。Workspace ONEアプリと ハブアプリ、およびWebブラウザーのルールも構成します。ポリシールールが正しい順序になっていることを確認してください。
- システム管理者としてVMware Identity Managerコンソールにログインします。
- [Identity & Access Management(IDとアクセスの管理)]タブをクリックしてから、[Policies(ポリシー)]タブをクリックします。
- [Edit Default Access Policy(デフォルトのアクセスポリシーの編集)]をクリックします。
- [Edit Policy(ポリシーの編集)]ウィザードで、[Configuration(構成)]をクリックします。
- [Add Policy Rule(ポリシールールを追加)]をクリックしてiOSデバイス用のポリシールールを作成します。
- 最初の認証方法としてモバイルSSO(iOS)を設定し、フォールバック認証方法としてOkta認証を設定します。
ユーザーのネットワーク範囲が[ALL RANGES(すべての範囲)]でiOSからコンテンツにアクセスしているのであれば、[Authenticate using(認証に使用)]アクションを実行すると、ユーザーは[Mobile SSO (iOS)(モバイルSSO(iOS))]で認証できるようになります。
前述の方法が失敗する、または適用できない場合は、ユーザーは[Okta Auth Method(Okta認証方法)]で認証できます。
注:[Okta Auth Method(Okta認証方法)]については、「VMware Identity Managerで新しいIDプロバイダーの作成を完了する」でOkta IdP用に作成した認証方法を選択します。 - [Save(保存)]をクリックします。
- 最初の認証方法としてモバイルSSO(iOS)を設定し、フォールバック認証方法としてOkta認証を設定します。
- [Add Policy Rule(ポリシールールを追加)]をクリックしてAndroidデバイス用に同様のポリシールールを作成します。
- 最初の認証方法としてモバイルSSO(Android)を設定し、フォールバック認証方法としてOkta認証を設定します。
ユーザーのネットワーク範囲が[ALL RANGES(すべての範囲)]でAndroidからコンテンツにアクセスしているのであれば、[Mobile SSO (Android)(モバイルSSO(Android))]で[Authenticate using(認証に使用)]アクションを実行します。
前述の方法が失敗する、または適用できない場合は、ユーザーは[Okta Auth Method(Okta認証方法)]で認証できます。
- [Save(保存)]をクリックします。
- 最初の認証方法としてモバイルSSO(Android)を設定し、フォールバック認証方法としてOkta認証を設定します。
- Workspace ONEアプリと ハブアプリのポリシールールを構成します。
- Workspace ONEアプリと ハブアプリのポリシールールをクリックして編集します。
- ルールを構成します。
ユーザーのネットワーク範囲が[ALL RANGES(すべての範囲)]でWorkspace ONEアプリまたはハブアプリからコンテンツにアクセスしているのであれば、[Authenticate using(認証に使用)]アクションを実行します。
[Mobile SSO (for iOS)(モバイルSSO(iOS向け))]で
前述の方法が失敗する、または適用できない場合は、ユーザーは[Mobile SSO (for Android)(モバイルSSO(Android向け))]で認証できます。
前述の方法が失敗する、または適用できない場合は、[Okta Auth Method(Okta認証方法)]を使用します。
- ポリシールールを上から順に次の順序で並べます。
- Workspace ONEアプリまたはHubアプリ iOSまたはAndroid
- iOSまたはAndroid
- Webブラウザー
ネイティブAndroidアプリの構成設定方法の例
Androidデバイスのユーザーに最高のユーザーエクスペリエンスを提供するために、AndroidモバイルSSOフローの特定の設定を構成できます。
ネイティブのAndroidアプリでは、VMwareトンネルをダウンロードしてエンドユーザーのデバイスにインストールする必要があります。Workspace ONEとOktaの統合環境のベストプラクティスとして、各ネイティブAndroidアプリの自動展開設定を構成して、ユーザーの登録後にアプリとトンネルが自動的にユーザーのデバイスに展開されるようにします。アプリの管理対象アクセスも有効にします。
これらの設定は、VMware Workspace ONE UEMコンソールで構成します。
- Workspace ONE UEMで ページに移動します。
- アプリ名をクリックします。
- [Assign(割り当て)]をクリックします。
- [Add Assignment(割り当てを追加)]をクリックして新しい割り当てを追加するか、編集する割り当てを選択して[Edit(編集)]をクリックします。
- 必要に応じて割り当てを構成し、ベストプラクティスとして次のように選択します。
- [App Delivery Method(アプリの配信方法)]:[AUTO(自動)]
- [Managed Access(管理アクセス)]:[ENABLED(有効)]
- [App Tunneling(アプリのトンネリング)]:[ENABLED(有効)]
[App Tunneling(アプリのトンネリング)]を有効にする場合は、アプリで使用するVPN構成プロファイルも選択する必要があります。
例:
- 割り当てを保存します。
ユーザーがデバイスを登録すると、アプリがカタログに表示されます。アプリのアイコンは、トンネルが含まれていることを示しています。ユーザーがアプリをインストールすると、アプリとトンネルの両方がインストールされます。