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

セルフサービス機能を有効にすると、承認ワークフローを構成することで、ビジネスアプリ所有者がエンドユーザーにアクセス許可を付与し、エンタイトルメントを割り当てる事ができるようになります。このアクションにより、エンドユーザーからのアプリリクエストの取り扱いがITグループからビジネスアプリ所有者に移行します。

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

このタスクを実行する管理者は、以下のロールのうち少なくとも1つを持つ必要があります。

  • Okta orgのスーパー管理者
  • Okta orgのアプリ管理者

読み取り専用ロールの管理者は、各アプリの統合の承認ワークフローを表示できますが、変更はできません。

開始する前に

スーパー管理者はセルフサービス機能をグローバルに有効にする必要があります。セルフサービスリクエスト機能を有効にするを参照してください。

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

このタスクを開始する

エンドユーザーがセルフサービス機能を用いて追加できるようにアプリの統合を構成するには:

  1. 管理コンソールで、[アプリケーション] > に移動します。 アプリ。構成済みアプリの統合リストから対象となるアプリの統合を見つけます。リストのアプリ数が多い場合は、検索バーを使ってそのアプリの統合を見つけることもできます。
  2. 結果からそのアプリの統合をクリックして、設定ページを開きます。
  3. [Assignments(割り当て)]タブを選択します。
  4. 右側に表示される[SELF SERVIE(セルフサービス)]セクションで[Edit(編集)]をクリックします。このパネルにはそのアプリの統合の現在のセルフサービスステータスも表示されます。

    注

    組織でグローバルにセルフサービス機能を有効にしていない場合に[Edit(編集)]をクリックすると、Oktaでセルフサービスがこのアプリの統合を構成できないというメッセージが表示されます。[Go to self service settings(セルフサービスの設定に移動)]をクリックしてこの機能を有効にします。

  5. エンドユーザーが自分のエンドユーザーダッシュボードでこのアプリの統合をリクエストできるようにするかを選択できます。

    スクリーンショットに、ユーザーにアプリの統合のリクエストを許可する選択を示します。

  6. エンドユーザーにアプリのリクエストを許可する場合、以下を構成する必要があります。

    • Note for requester(リクエスト提出者へのメモ):このフィールドは、アプリの統合の説明またはリクエストしているエンドユーザーに指示を与えるために使用します。最大文字数は500文字です。
    • Approval(承認)Not Required(不要)またはRequired(必要)

    スクリーンショットは承認要件のオプションを表示しています。

    注

    アプリの統合の承認ステータスをRequired(必要)からNot Required(不要)に変更すると、承認待ちのリクエストはすべて削除されます。管理者用には、Okta System Logs(システムログ)Deleted(削除されました)というメッセージが表示されます。Oktaはエンドユーザーにリクエストの削除を通知しません。

  7. 承認ワークフローを必要とする場合は、次のオプションを構成します。

    • Send app requests to(アプリのリクエスト送信先):承認リクエストを受信するユーザーまたはグループを指定します。

      個々のユーザーを指定するには、選択フィールドに名前を入力します。一致するユーザーのリストが表示されるので、そこから正しいユーザーを選択できます。

      グループを指定するには、ドロップダウン・リストを[グループ]に変更し、グループ名を入力します。承認者として指定されたグループに含めることができるメンバーは100人までです。

      複数の個人またはグループを指定して、承認チェーンを作成できます。承認チェーンは10レベルを超えることはできません。また、同じ個人やグループを複数回入力することはできません。

      [資格]ドロップダウン・リストでは、リクエスト者のアカウントの属性を表示または変更する承認者の権限を指定します。次の3つの選択肢があります。

      • 非表示:承認者はアカウント属性を表示できません。
      • 読み取り:承認者はアカウント属性を表示できますが変更できません。
      • 書き込み:承認者はアカウント属性を編集できます。

      スクリーンショットには、アクセスリクエストワークフローの承認者オプションを示しています

      ヒント

      承認チェーンがアプリの統合のプロビジョニング要件を満たすよう設定することをおすすめします。

      • アプリの統合がプロビジョニングをサポートし、割り当て時に指定する必要がある必須属性がある場合、少なくとも1人の承認者がこれらのユーザー属性を編集および設定する必要があります。
      • アプリの統合が自動プロビジョニングをサポートしていない場合、最終承認手順はプロビジョニング手順としても機能します。外部アプリアカウントのユーザーアカウントを最終承認者としてプロビジョニングできる管理者を選択します。その後、この管理者はユーザーアカウントをプロビジョニングしてリクエストを承認し、エンドユーザーにアプリの統合を通じてすぐにシングルサインオンアクセスを許可します。
      注

      承認者の順序を変更するには、手順番号の左側にある点線のハンドルをクリックし、その行を順序の目的の場所までドラッグします。

    • リクエストが承認された場合:リクエストが承認されたときにOktaによって送信する追加の通知を指定します。アプリの統合がダッシュボードに追加されると、リクエスト者のダッシュボードに自動的に通知されます。[Send email to others...(ほかの人にメールを送信...)]を選択すると、任意の有効なメールアドレスを入力できます。
    • リクエストが拒否された場合:リクエストが拒否されたときにOktaによって送信する追加の通知を指定します。リクエストが拒否されても、リクエスト者に自動で通知は送られません。[Send email to others...(ほかの人にメールを送信...)]を選択すると、任意の有効なメールアドレスを入力できます。

      スクリーンショットには、承認および拒否されたリクエストの通知オプションを示しています。

    • Approver must respond within(承認者の応答が次の期限内に必要):各承認者がリクエストに応答できる時間枠を指定します。1週間、30日、またはカスタム期間を指定できます。
      • 承認リクエストが期限切れになるとリクエストはキャンセルされ、リクエストされたアプリへのアクセス許可はエンドユーザーに付与されません。 期限切れになったリクエストは明示的に拒否されたリクエストとは分けてログに記録されます。
      • 構成可能な時間枠は、承認チェーンの各手順に適用されます。たとえば、承認時間に1週間と指定し、複数の承認者がいる場合、各承認者に回答期間として1週間ずつ与えられます。承認者が3人いる場合、チェーン全体の承認には3週間かかる可能性があります。
      • リクエストの有効期限が切れた場合:時間枠が終了した後にOktaによって送信する追加の通知を指定します。[Send email to others...(ほかの人にメールを送信...)]を選択すると、任意の有効なメールアドレスを入力できます。
      • 管理者はリクエストの時間枠を使ってリクエストのサービスレベル契約(SLA)を設定でき、有効期限切れ通知では承認者からの反応がない状況に対応できます。サポート組織が必要に応じてリクエスト者のフォローアップと手動でのリクエスト承認を行えるように、アプリの統合のリクエストの時間枠と承認チェーンについてサポート組織に通知することをおすすめします。

      スクリーンショットには、リクエスト承認の時間枠のオプションを示しています。

次の手順

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

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