アプリ統合リクエストの処理

エンドユーザーがOkta End-User Dashboardからアプリをリクエストすると、Oktaはワークフローの最初の承認者にメールでリクエストの詳細とリンクを通知します。承認者はリンクを開いてリクエストを承認または拒否できます。このプロセスは、ワークフロー中のすべての承認者が許可するか、一人の承認者が拒否するまで続行します。

このタスクの管理者ロールについて

アプリ統合向けセルフサービス構成ワークフロー内に承認者が一覧表示される必要があることを除き、リクエストの承認に必要な特別なロールはありません。承認者は、個人またはグループの一員として一覧表示できます。

スーパー管理者やアプリ管理者は承認プロセスに介入して、通常の承認プロセス外で承認することができます。

開始する前に

管理者はOkta Admin Consoleにサインインする必要があります。

この手順を開始する

リクエストを承認するプロセスは、承認者が個人の承認者であるか、承認者グループの一員であるか、あるいはorgの管理者であるかどうかによって異なります。

• 個人の承認者
• グループの承認者
• 管理者（Administrator）

個人の承認者

エンドユーザーがアプリをリクエストした後、最初の承認者がそのリクエストとリンクを含むメールを受信します。リンクに従うと、リクエストを承認または拒否するオプションが得られます。承認者はまた、随時、自分のEnd-User Dashboardにあるキューで承認待ちのリクエストをチェックすることもできます。ダッシュボードでタスク（Tasks）タブを選択すると、承認待ちのすべてのリクエストが表示されます。

• ワークフロー内の最初の承認者がリクエストを承認すると、次の承認者がメールを受信します。
• リクエストを承認する最後または唯一の承認者の場合：
  • アプリの統合がプロビジョニング用に構成されていれば、エンドユーザーは外部アプリ用にプロビジョニングされ、アプリの統合に割り当てられ、SSOアクセス許可を受け取ります
  • アプリの統合がプロビジョニング用に構成されていなければ、エンドユーザーはアプリの統合に割り当てられ、SSOアクセス許可を受け取ります
• リクエストを拒否すると、エンドユーザーはアクセス許可を付与されず、システムログエントリが更新されます。

グループの承認者

承認者としてグループが指定されている場合、グループのメンバーは全員、リクエストを承認するためのリンクを含む同じメール通知を受信します。グループメンバーの1人がリクエストを承認または拒否すると、承認ステップ全体が完了し、このタスクは他のグループメンバーすべてのキューから削除されます。

管理者

Okta管理者は、承認プロセスに介入して、以下のいずれかのアクションを行うことができます。

• 承認待ちのリクエストを表示して、承認プロセスの現在のステップを見る。
• 現在の承認者に承認通知を再送信する。
• 承認待ちのエンドユーザーリクエストをキャンセルする。
• プロセスをオーバーライドして、即時エンドユーザーにアプリを割り当てる。

リクエストを表示、再送信、または削除するには

1. Admin Consoleで、アプリケーション（Applications） > アプリケーション（Applications）に移動します。

2. エンドユーザーがリクエストしたアプリの統合を選択します。
3. 割り当て（Assignments）タブで、セルフサービス（SELF SERVICE）（Manage Requests）ペインのアプリのリクエスト（APP REQUESTS）セクションでリクエストの管理（Manage Requests）（SELF SERVICE）をクリックします。

   承認待ちリクエストの管理（Manage Pending Requests）ウィンドウで：

   • をクリックして、リクエストの履歴（Request History）を表示します。
   • をクリックして、通知を送信するための確認ダイアログを開きます。メールの送信（Send Email）をクリックし、通知メールをワークフロー内の現在の承認者に送信して、割り当て（Assignments）タブに戻ります。送信して戻る（Send and Go Back）をクリックし、メールを送信して、承認待ちリクエストの管理（Manage Pending Requests）ウィンドウに戻ります。
   • をクリックして、リクエスト削除の確認ダイアログを開きます。削除（Delete）をクリックし、リクエストを承認して、割り当て（Assignments）タブに戻ります。削除して戻る（Delete and Go Back）をクリックし、リクエストを削除して、承認待ちリクエストの管理（Manage Pending Requests）ウィンドウに戻ります。リクエストが削除されても、アプリの統合はまだ管理者が手動で割り当てることができます。

既知の問題

管理アクションの中には、セルフサービス機能の承認ワークフローに影響するものがあります。以下のいずれかを行うと、既存または今後のアクセスリクエストで問題が生じる可能性があります。

• アプリの統合の非アクティブ化
• 承認者の非アクティブ化
• グループの承認者として指定されたグループの削除
• アプリの統合スキーマの変更

アプリの統合または承認者にこれらのいずれかの変更を行う前に、承認待ちのリクエストをすべて解決してからアプリの統合のセルフサービス機能を無効にします。変更を行った後、アプリの統合の承認ワークフローを復元できます。

システムログの内容

以下のセルフサービス機能イベントをシステムログで追跡できます。

• ユーザーアプリのリクエスト ：リクエスト提出者のコメントがSystem.DebugContext.DebugDataセクションにログされます。
• 個人の承認者の承認と拒否 ：承認者タイプがUSERとしてログされ、承認者のコメントがSystem.DebugContext.DebugDataセクションにログされます。
• グループの承認者の承認と拒否 ：承認者タイプがGROUPとしてログされ、承認者のgroupId、group name、およびcommentがすべてSystem.DebugContext.DebugDataセクションにログされます。
• アプリの承認：すべての承認者がリクエストを承認し、エンドユーザーにアクセス許可が付与されました。これらのイベントは、一人の承認者のアクションによってではなく、Oktaシステムのアクセス許可の付与または拒否によってトリガーされます。
• アプリの拒否：一人の承認者がリクエストを拒否し、エンドユーザーのアクセス許可が拒否されました。これらの項目は、一人の承認者のアクションによってではなく、Oktaシステムのアクセス許可の付与または拒否によってトリガーされます。
• リクエストの削除：エンドユーザーのアプリの統合へのアクセスリクエストが拒否されました。

次も参照

セルフサービス承認ワークフローの構成

エンドユーザーとしてアプリの統合を追加する