アプリ統合要求を処理する

エンド・ユーザーがOkta End-User Dashboardを介してアプリを要求すると、要求の詳細とリンクを含むメール通知がワークフローの最初の承認者に送られます。承認者はリンクを開いて要求を承認または拒否できます。ワークフロー内のすべての承認者が権限を付与するか、1人の承認者がリクエストを拒否するまでこのプロセスは継続します。

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

アプリ統合のセルフ・サービス構成ワークフローに承認者が個人またはグループの一部としてリストされる必要がある場合を除き、要求の承認に特別なロールは必要ありません。

スーパー管理者またはアプリ管理者は承認プロセスに介入し、通常の承認プロセス外で承認を実行できます。

開始する前に

管理者はOkta管理コンソールにサインインする必要があります。

この手順を開始する

要求を承認するために必要な手順は、承認者が個別の承認者としてリストされているか、承認者のグループの一部であるか、組織の管理者であるかによって異なります。

個人承認者

エンド・ユーザーがアプリを要求すると、最初の承認者は要求とリンクを含むメールを受信します。リンクをクリックすると、要求を承認または拒否するオプションが表示されます。また、承認者はEnd-User Dashboardを使用して、いつでもキュー内の未処理の承認を確認することができます。ダッシュボードの[タスク]タブを選択すると、承認待ちの要求がすべて表示されます。

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

[承認アクション]セクションに入力したコメントはすべてシステム・ログに記録されますが、このテキストは要求者へのメール通知には含まれません。

グループ承認者

グループが承認者として指定されている場合、グループのメンバー全員が要求を承認するためのリンクを含む同一のメール通知を受信します。グループの1人のメンバーが要求を承認または拒否すると、承認手順全体が完了し、ほかのグループ・メンバー全員のタスクがキューから削除されます。

管理者

Okta管理者は承認プロセスに介入して以下のアクションを実行できます。

  • 未処理の要求を表示し、現在の承認プロセス手順を確認する。
  • 現在の承認者に承認通知を再送する。
  • 未処理のエンド・ユーザー要求をキャンセルする。
  • プロセスを上書きし、アプリを迅速にエンド・ユーザーに割り当てる。

要求を表示、再送信、削除するには

  1. 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]
  2. エンド・ユーザーが要求したアプリ統合を選択します。
  3. [割り当て]タブで、[セルフ・ サービス]ペインの[アプリ の要求] セクションの[要求を管理]をクリックします。

    [保留中の要求を管理]ウィンドウで:

    • をクリックして[要求履歴]を表示します。
    • 青い紙飛行機アイコンをクリックして、通知送信の確認ダイアログを開きます。[メールを送信]をクリックすると、ワークフローの現在の承認者に通知メールが送信され、[割り当て]タブに戻ります。[送信して戻る]をクリックすると、メールが送信され、[保留中の要求を管理]ウィンドウに戻ります。
    • 青いゴミ箱アイコンをクリックして、要求を削除する確認ダイアログを開きます。[削除]をクリックすると、この承認要求が削除され、[割り当て]タブに戻ります。[削除して戻る]をクリックすると、要求が削除され、[保留中の要求を管理]ウィンドウに戻ります。要求が削除された場合でも、管理者はアプリ統合を手動で割り当てることができます。
注

管理者が承認プロセスを上書きし、アプリ統合をすぐに割り当てると、承認プロセスは停止し、承認ワークフローの残りの手順はすべて削除されます。エンド・ユーザーはダッシュボードからアプリ統合にアクセスできます。

既知の問題

一部の管理アクションは、セルフ・サービス機能の承認ワークフローに影響を与える可能性があります。次のいずれかを実行すると、既存および将来のアクセス要求で問題が発生する可能性があります。

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

アプリ統合または承認者にこれらの変更を加える前に、まず保留中のリクエストを解決してから、アプリ統合のセルフ・サービス機能を無効にしてください。変更を加えた後に、アプリ統合の承認ワークフローを復元できます。

システム・ログ・エントリー

次のセルフ・サービス機能イベントはシステム・ログで追跡されます。

  • ユーザーによるアプリの要求:要求者のコメントはystem.DebugContext.DebugDataセクションに記録されます。
  • 個人承認者の承認および拒否: 承認者タイプはUSERとして記録され、承認者のコメントはSystem.DebugContext.DebugDataセクションに記録されます。
  • グループ承認者の承認および拒否: 承認者タイプはGROUPとして記録され、承認者のグループIDグループ名コメントはすべてSystem.DebugContext.DebugDataセクションに記録されます。
  • アプリの承認:すべての承認者が要求を承認し、エンド・ユーザーにアクセス権が付与されました。これらのイベントは承認者のアクションではなく、Oktaシステムによるアクセス権の付与または拒否によってトリガーされます。
  • アプリの拒否: 承認者が要求を拒否し、エンド・ユーザーのアクセス権が拒否されました。これらのアイテムは承認者のアクションではなく、Oktaシステムによるアクセス権の付与または拒否によってトリガーされます。
  • 要求の削除: エンド・ユーザーのアプリ統合要求が削除されました。

次も参照

セルフ・サービス承認ワークフローを構成する

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