アプリの統合リクエストの取り扱い

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

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

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

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

はじめに

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

この手順を開始する

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

個人の承認者

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

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

［Approval Action（承認アクション）］セクションに入力したコメントはすべてSystem Logに記録されますが、このテキストはリクエスト提出者へのメール通知には含まれません。

グループの承認者

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

管理者

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

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

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

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

    ［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 Logの内容

以下のセルフサービス機能イベントをSystem Logで追跡できます。

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

関連項目

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

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