Omnissa Connect では、OAuth 2.0 を使用して、組織内の保護されたリソースに対する委譲されたセキュアなアクセス権をアプリケーションに付与できるようにします。Omnissa Connect は、アプリケーション ユーザーが認証する Web アプリケーション アクセスと、アクセス トークンがアプリケーションに直接発行されるサーバ間の相互通信をサポートします。
OAuth 2.0 とは
OAuth 2.0 は、リソースへの安全なアクセス権をアプリケーションに付与するための認証プロトコルです。クライアントは、アクセス トークンを介して認証されます。アクセス トークンにはスコープが設定され、トークンがアクセスできるリソースが定義されます。OAuth 2.0 の詳細については、https://tools.ietf.org/html/rfc6749 の OAuth 仕様を参照してください。
Omnissa Connect での OAuth 2.0 の動作
Omnissa Connect は、さまざまな認証タイプを使用したアプリケーション認証をサポートします。
- サーバ間アプリケーション用のクライアント認証情報
- Web アプリケーション用の認証コード
- ネイティブ/モバイル アプリケーション用の認証コード付きパブリック クライアント
OAuth アプリケーションのドキュメントの違反ポリシー
OAuth アプリケーションのアクセス違反ポリシーを作成する方法の詳細については、ガバナンスのトピックを参照してください。
サーバ間 OAuth アプリケーションの例
Omnissa サービスへのアクセス権を持つ所有者のケースを考えます。このユーザーが株の取引を支援するアプリケーションを開発しました。このアプリケーションを Trading 1.0 と呼びます。別の Omnissa サービスによって管理されている仮想マシンで、このアプリケーションを実行しますが、その前に、API と自動化スクリプトを使用してアプリケーションを認証する必要があります。自動化スクリプトは、組織がスクリプトをホストしている場所にあります。
- Omnissa Connect で OAuth 2.0 アプリケーションを作成します。
- このシナリオは、Trading 1.0 アプリケーション（Omnissa 管理対象の仮想マシン上で実行されるアプリケーション）を Omnissa Connect（認証サーバー）に登録するものと考えてください。
- Connect の [ID 管理] > [OAuth アプリケーション] > [所有アプリケーション] タブで [OAuth アプリケーションの新規作成] を選択して、アプリケーションの作成を開始し、一連の手順を実行します。
- プロセスの最後に、Omnissa Connect はクライアント シークレットとクライアント ID を含む、クライアント認証情報を発行します。
- これらの認証情報を自動化スクリプト内の API に貼り付けて、Connect から得られるアクセス トークンを要求します。
- Connect で、アプリケーションに Omnissa Connect 組織へのアクセス権を付与します。
- アクセスを付与するには、Omnissa Connect で登録済みのアプリケーション Trading 1.0 を組織に追加します。これは、追加プロセスの最後のステップです。
- これにより、組織のサービスとリソースにアプリケーションがアクセスできるようになります。
- Trading 1.0 クライアント アプリケーションを実行すると、アプリケーションは認証サーバ (Omnissa Connect) からアクセス トークンを要求します。
- 認証されると、認証サーバの Omnissa Connect がクライアント アプリケーションにアクセス トークンを送信し、クライアント アプリケーションは Omnissa リソースへのアクセスを要求できます。
OAuth アプリケーションを作成および管理可能なユーザー
所有者ユーザー、または開発者ロール（IGA の高度な機能）を持つメンバー ユーザーは、OAuth アプリケーションを作成および管理できます。
組織内の他の所有者によって作成または追加された OAuth アプリケーションを管理することもできます。
サーバ間 - クライアント認証情報
ユーザー認証せずに、アプリケーションが別のサーバへの直接アクセスを必要とする場合は、Connect でサーバ間アプリケーションを作成します。このオプションは、OAuth 2.0 クライアント認証情報の認証タイプに基づいています。このフローでは、アプリケーションが OAuth の認証情報を使用して、Omnissa Connect からアクセス トークンを取得します。
スコープ設定
スコープ設定は、サーバ間アプリケーションでは特に重要です。スコープによって、クライアントがアクセスできる組織内の領域（具体的には、組織内のロール、サービスの種類、権限レベル）を制御できます。
所有者は、すべての組織にサーバ間アプリケーションを追加できます。そのため、多くのサービスにアプリケーションのアクセス範囲を幅広く指定できますが、最終的に組織に含まれているサービスによってアクセスは決定されます。組織に OAuth アプリケーションを追加する際、アプリケーションのスコープに含まれているサービスが組織に含まれていない場合、通知が送信されます。
前提条件
組織で OAuth アプリケーションの追加と管理を行うために必要な権限がある。
手順
- Omnissa Connect にログインし、[ID 管理] > [OAuth アプリケーション] の順に移動します。
- [所有しているアプリケーション] タブを選択し、 [OAuth アプリケーションの新規作成] を選択します。
- [サーバ間アプリケーション] を選択し、[続行] を選択します。
- 名前と説明を入力して、クライアントを登録します。
- 新しい OAuth アプリケーションの [アクセス トークンの有効期間 (TTL)] 値を設定します。
アクセス トークンの有効期間 (TTL) により、アクセス トークンが有効な期間が定義されます。- アクセス トークンのデフォルトの TTL は 30 分です。
- 設定できるアクセス トークンの最大有効期間 (TTL) は 300 分（5 時間）です。
- アクセス トークンの TTL に設定できる最小時間は 1 分です。
- スコープを定義します。
- スコープによって、クライアントがアクセスできる組織内の領域（具体的には、組織内のロール、サービスの種類、権限レベル）を制御できます。
- [作成] をクリックして、クライアントの認証情報を生成します。
- [OAuth アプリケーションが作成されました] ポップアップ ウィンドウで、認証情報をコピーするか、JSON ファイルをダウンロードし、[続行] をクリックします。
- 認証情報は、お客様の手で安全な場所に保存してください。
- 認証情報を自動化スクリプト内のアプリケーションの認証 API に貼り付けるか、アプリケーションがアクセス トークンを取得するために安全に使用できる場所に認証情報 JSON ファイルを安全に保存します。
- クライアント アプリケーションは、アクセス トークンを検証する必要があります。
- 検証後、アプリケーションはリソースにアクセスするためのアクセス トークンを要求できるようになります。
- （オプション）Connect でアクティブな組織にアプリケーションを追加します。
- この手順により、Connect 組織のサービスとリソースにアプリケーションがアクセスできるようになります。
- この手順をスキップして、この組織や他の組織にアプリケーションを後で追加できます。
Web アプリケーション - 認証コード
アプリケーションが、サーバ上で実行される通常の Web アプリケーションで、ユーザーの認証が必要な場合は、Connect で Web アプリケーションを作成します。このオプションは、OAuth 2.0 認証コードの認証タイプに基づいています。
このフローでは、ユーザーは、アプリケーションがリソースにアクセスする前に、認証リクエスト URL を介してアプリケーションを認証し、認証コードを取得します。アプリケーションで、認証コードが Connect からのアクセス トークンと交換されます。アクセス トークンを使用すると、ユーザーはアプリケーションを介して Omnissa リソースにアクセスできます。アプリケーションはオプションで、Connect から更新トークンを取得できます。
前提条件
組織で OAuth アプリケーションの追加と管理を行うために必要な権限がある。
手順
- Omnissa Connect にログインし、[ID 管理] > [OAuth アプリケーション] の順に移動します。
- [所有しているアプリケーション] タブを選択し、 [OAuth アプリケーションの新規作成] を選択します。
- [Web/モバイル アプリ] を選択し、[続行] を選択します。
- アプリケーションの詳細を入力して、アプリケーションを登録します。
- 新しい OAuth アプリケーションの名前と説明を入力します。
- 1 つ以上のリダイレクト URI を入力します。
- ユーザーがクライアントを認証すると、認証サーバはアクセス トークンで指定した URI を使用して、ユーザーをクライアントにリダイレクトします。
- 1 つ以上の URI を追加することをお勧めします。
- http://acme.com の形式を使用します。
- アクセス トークンの有効期間を指定します。
- アクセス トークンのデフォルトの有効期間 (TTL) 設定は 30 分です。
- 設定できる最大値は 300 分（5 時間）です。
- 設定できる最小値は 1 分です。
- アクセス トークンを使用して継続的にリクエストを認証する場合は、[更新トークンの発行] チェックボックスを選択し、[更新トークンの有効期間 (TTL)] 値を設定します。
- 更新トークンのデフォルトの TTL は 30 分です。
- 設定できる最大値は 300 分（5 時間）です。
- 設定できる最小値は 1 分です。
- スコープを定義します。
- スコープによって、クライアントがアクセスできる組織内の領域（具体的には、サービスと権限レベル）を制御できます。
- アプリケーションを認証するユーザーに関する情報を取得するには、[OpenID] チェックボックスを選択します。
- [作成] をクリックして、クライアントの認証情報を生成します。
- 認証情報をコピーするか、認証情報を含む JSON ファイルをダウンロードします。
- 認証情報は、お客様の手で安全な場所に保存してください。
- Connect クライアントの認証情報をアプリケーションの認証 API に貼り付けるか、アプリケーションが Connect からアクセス トークンおよび更新トークンを取得するために安全に使用できる場所に、認証情報 JSON ファイルを安全に保存します。
- 続行 を選択します。
モバイル アプリ - 認証コード付きパブリック クライアント
ネイティブ アプリケーションおよびモバイル アプリケーションなどのパブリック クライアントは、クライアント シークレットの機密性を維持することはできません。モバイル アプリに OAuth 2.0 を使用している場合、Omnissa Connect はアプリケーション ID を生成し、Proof Key for Code Exchange (PKCE) を使用して追加の検証を提供します。
PKCE は、クライアント シークレットを使用しないパブリック クライアントを保護する手法です。詳細については、「OAuth 仕様の Proof Key for Code Exchange by OAuth Public Clients」(https://datatracker.ietf.org/doc/html/rfc7636) を参照してください。
このフローでは、ユーザーは、Connect で生成されたアプリケーション ID を含む認証リクエスト URL を介して、アプリケーションがリソースにアクセスする前にアプリケーションを認証し、認証コードを取得します。アプリケーションで、認証コードが Connect からのアクセス トークンと交換されます。アクセス トークンを使用すると、ユーザーはアプリケーションを介して Omnissa リソースにアクセスできます。アプリケーションはオプションで、Connect から更新トークンを取得できます。
前提条件
この組織で OAuth アプリケーションの追加と管理を行うために必要な権限がある。
手順
- Omnissa Connect にログインし、[ID 管理] > [OAuth アプリケーション] の順に移動します。
- [所有しているアプリケーション] タブを選択し、 [OAuth アプリケーションの新規作成] を選択します。
- [Web/モバイル アプリ] を選択し、[続行] を選択します。
- アプリケーションの詳細を入力して、アプリケーションを登録します。
- 新しい OAuth アプリケーションの名前と説明を入力します。
- 1 つ以上のリダイレクト URI を入力します。
- ユーザーがクライアントを認証すると、認証サーバはアクセス トークンで指定した URI を使用して、ユーザーをクライアントにリダイレクトします。
- 1 つ以上の URI を追加することをお勧めします。
- http://acme.com の形式を使用します。
- アクセス トークンの有効期間を指定します。
- アクセス トークンのデフォルトの有効期間 (TTL) 設定は 30 分です。
- 設定できる最大値は 300 分（5 時間）です。
- 設定できる最小値は 1 分です。
- アクセス トークンを使用して継続的にリクエストを認証する場合は、[更新トークンの発行] を選択し、[更新トークンの有効期間 (TTL)] 値を設定します。
- 更新トークンのデフォルトの TTL は 30 分です。
- 設定できる最大値は 300 分（5 時間）です。
- 設定できる最小値は 1 分です。
- スコープを定義します。
- スコープによって、クライアントがアクセスできる組織内の領域（具体的には、サービスと権限レベル）を制御できます。
- アプリケーションを認証するユーザーに関する情報を取得するには、[OpenID] チェックボックスを選択します。
- [作成] をクリックして、認証情報を生成します。
- アプリケーション ID をコピーするか、アプリケーション ID を含む JSON ファイルをダウンロードします。
- これらの認証情報は、お客様の手で安全な場所に保存してください。
- アプリケーション ID をアプリケーションの認証 API に追加するか、アプリケーションが Connect からアクセス トークンおよび更新トークンを取得するために安全に使用できる場所に、アプリケーション ID の JSON ファイルを安全に保存します。
- 続行 を選択します。
OAuth 2.0 アプリケーションを管理する方法
所有者は、組織内の OAuth アプリケーションの詳細を作成、表示、変更できます。組織内の他の所有者によって作成または追加された OAuth アプリケーションを管理することもできます。所有者ロールを保持している任意の組織で作成された、アプリケーションにアクセス権を付与する。
| 目的 | 手順 |
|---|---|
| 組織へのアクセス権がある OAuth アプリケーションを表示する。 | - [ID 管理] > [OAuth アプリケーション] を選択します。 - [ロールが割り当てられたアプリケーション] タブで、組織へのアクセス権がある、他の組織で作成されたアプリケーションを表示できます。 |
| 別の組織で作成された OAuth アプリケーションを追加する。 | 1.[ID 管理] > [OAuth アプリケーション] の順に移動し、[ロールが割り当てられたアプリケーション] タブを選択します。 2.[OAuth アプリケーションの追加] を選択します。 3. 追加する OAuth アプリケーションを特定するには、[アプリケーション ID の入力] または [組織別に検索] を選択します。 4.続行 を選択します。 5a. ID を使用して OAuth アプリケーションを識別するように選択した場合は、OAuth アプリケーション ID の入力を求められます。 5b. 作成された組織を使用して OAuth アプリケーションを識別するように選択した場合は、最初にドロップダウン メニューから組織名を選択し、その組織で使用可能な OAuth アプリケーションのリストから OAuth アプリケーションを選択するように求められます。[組織] ドロップダウン メニューには、所有者アクセス権が割り当てられている組織のみが表示されます。 6. [アプリケーションの詳細] を確認し、[追加] を選択します。 |
| 組織へのアクセス権がある、別の組織で作成された OAuth アプリケーションを削除する。 | 1.[ID 管理] > [OAuth アプリケーション] の順に移動し、[ロールが割り当てられたアプリケーション] タブを選択します。 2. 表示される OAuth アプリケーションのリストから、組織へのアクセスを禁止するアプリケーションを選択します。 3.[削除] を選択します。 |
| 組織内で作成されたアプリケーションを表示する。 | [ID 管理] > [OAuth アプリケーション] を選択し、[所有しているアプリケーション] タブを選択します。 ここでは、組織内で作成されたすべてのアプリケーションを表示できます。 |
| 組織で新しい OAuth アプリケーションを作成する。 | 1.[ID 管理] > [OAuth アプリケーション] の順に移動し、[所有アプリケーション] タブを選択します。 2.[OAuth アプリケーションの新規作成] を選択します。 3. 追加するアプリケーションのタイプを選択します。 |
| 組織内で作成された OAuth アプリケーションを管理する。 | [ID 管理] > [OAuth アプリケーション] を選択し、[所有しているアプリケーション] タブを選択します。管理するアプリを選択します。 - OAuth アプリケーションを変更するには、[編集] を選択します。 注：アプリケーションのスコープを変更しても、他の組織内にあるアプリケーションのインスタンスには変更が適用されません。スコープを更新するには、所有者が組織からアプリケーションを削除して再度追加するか、更新されたスコープが反映されるようにアプリケーションを編集する必要があります。 - アプリケーションを削除するには、[削除] を選択します。 注：このアクションを元に戻すことはできません。これらのクライアント認証情報を使用しているアプリケーションは保護対象リソースにアクセスできなくなり、認証情報は無効になります。 - 組織内で作成されたが、組織へのアクセス権をまだ与えられていないサーバ間アプリケーションを追加するには、アプリケーションを選択して、[ロールの割り当て] を選択します。必要に応じて、アプリケーションのスコープで許可されている使用可能な組織ロールとサービス ロールを変更し、[追加] を選択します。 - 最初にアプリケーションのスコープを変更する場合は、[編集] を選択し、組織ロールとサービス ロールに必要な変更を加えます。準備ができたら、[この組織に追加] を選択します。 注：Web/モバイル アプリケーションは、組織に追加することはできません。 |
アプリケーション シークレットを再生成できますか。
所有者は、組織内の OAuth アプリケーションのアプリケーション シークレットを再生成できます。これは、OAuth アプリケーションを作成した所有者が、退職などで企業に所属しなくなり、アプリケーションを引き続き実行する必要がある場合に便利です。
OAuth アプリケーションの代わりに API トークン認証を使用できますか。
はい。API によって、ユーザーが認証プロセスで認証されたエンティティであることが義務付けられている場合は、API トークンを使用する必要があります。
OAuth アプリケーションと API トークンの違いは何ですか。
Omnissa Connect API を操作するには、OAuth アプリケーションと API トークンを両方とも使用します。Connect のこの IGA 機能の詳細については、API トークンを参照してください。
重要：サービスの自動呼び出しでサーバ間タイプの OAuth アプリケーションを使用する前に、関連する API のドキュメントを参照してください。
API トークンは組織内のユーザーによって発行され、ユーザーのアカウントと、API トークンを生成したユーザーが所属する組織に関連付けられます。API トークンを作成したユーザーのみがアプリケーションを管理できます。
組織内のユーザーによって作成された OAuth アプリケーションは、サーバ間の操作におけるエンティティとして機能し、複数の組織で使用できます。OAuth アプリケーションの所有者は、作成元の組織です。所有者、または開発者ロールを持つメンバーであるユーザーが管理できます。ロール申請の管理の詳細については、申請のトピックを参照してください。
API を操作するプロセスを自動化する場合は、OAuth アプリケーションと API トークンを両方使用できます。これらの違いは、API トークンの場合はアクセス トークンにユーザー アカウントが組み込まれているのに対して、OAuth アプリケーションはユーザー アカウントを使用せずに認証を実行することです。API 呼び出しの実行に API トークンと OAuth アプリケーションのいずれを使用するかを選択する際は、その操作に関連する API サービスの具体的な要件を考慮する必要があります。
API によっては、ユーザー アカウントが認証済みのエンティティであることが必要な場合と、その必要がない場合があります。たとえば、API を呼び出して、Omnissa Connect 内で組織のサブスクリプションの情報を取得する場合は、サーバ間タイプの OAuth アプリケーションまたは API トークンを使用して、API サービスを呼び出すことができます。これは、ユーザー認証情報による認証を必要とせず、クライアントの認証情報を同様に受け入れるためです。組織のユーザーがパスワードを更新するために API を使用する場合は、ユーザーが認証エンティティとして機能する必要があります。
このページは役に立ちましたか?