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

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

このワークフローは、個人用の属性が必須のアプリでは使用できません。

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

次のロールの少なくとも1つが必要です。

スーパー管理者
アプリ管理者

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

はじめに

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

このタスクを開始する

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

Admin Consoleで、［Applications（アプリケーション）］［Applications（アプリケーション）］に移動します。［Search（検索）］バーを使用するか、スクロールして、構成するアプリ統合を見つけます。
結果からそのアプリの統合をクリックします。
［Assignments（割り当て）］タブを選択します。
［SELF SERVICE（セルフサービス）］セクションで［Edit（編集）］をクリックします。このパネルにはそのアプリの統合の現在のセルフサービスステータスも表示されます。

orgでグローバルにセルフサービス機能を有効にしていない場合に［Edit（編集）］をクリックすると、Oktaでセルフサービスがこのアプリの統合を構成できないというメッセージが表示されます。［Go to self service settings（セルフサービスの設定に移動）］をクリックしてこの機能を有効にします。
［Requests（リクエスト）］セクションで、［Yes（はい）］を選択して、ユーザーがOkta End-User Dashboardでこのアプリの統合をリクエストできるようにします。
任意。リクエスト提出者向けに、統合について説明したり、リクエストしているユーザーに指示を与えたりするためのメモを入力します。最大文字数は500文字です。
［Approval（承認）］セクションで、［Required（必須）］を選択します。

アプリの統合の承認ステータスを［Required（必要）］から［Not Required（不要）］に変更すると、承認待ちのリクエストはすべて削除されます。管理者用には、Okta System Logに［Deleted（削除されました）］というメッセージが表示されます。Oktaはエンドユーザーにリクエストの削除を通知しません。
［Send app requests to（アプリのリクエストの送信先）］で、アプリのリクエストを承認するユーザーまたはグループを指定します。
1. ドロップダウンリストから［Users（ユーザー）］または［Groups（グループ）］を選択します。
2. フィールドにユーザー名またはグループ名を入力します。リストから一致するユーザーまたはグループを選択します。
  
  承認者として指定されたグループに含めることができるメンバーは100人までです。
3. ［Entitlements（エンタイトルメント）］ドロップダウンリストから、承認者の権限を選択します。
  - ［Hidden（非表示）］：承認者はアカウント属性を表示できません。
  - ［Read（参照）］：承認者はアカウント属性を表示できますが変更できません。
  - ［Write（更新）］：承認者はアカウント属性を編集できます。
4. 任意。ユーザーまたはグループをさらに追加して、承認チェーンを作成します。承認者の順序を変更するには、手順番号の左側にある点線のハンドルをクリックし、その行を目的の位置までドラッグします。承認チェーンは10レベルを超えることはできません。また、同じユーザーやグループを複数回入力することはできません。
  
  承認チェーンがアプリの統合のプロビジョニング要件を満たすよう設定することをおすすめします。
  
  アプリの統合がプロビジョニングをサポートし、割り当て時に指定する必要がある必須属性がある場合、少なくとも1人の承認者がこれらのユーザー属性を編集および設定する必要があります。
  
  アプリの統合が自動プロビジョニングをサポートしていない場合、最終承認手順はプロビジョニング手順としても機能します。外部アプリアカウントのユーザーアカウントを最終承認者としてプロビジョニングできる管理者を選択します。その後、この管理者はユーザーアカウントをプロビジョニングしてリクエストを承認し、エンドユーザーにアプリの統合を通じてすぐにシングルサインオンアクセスを許可します。
［If request is approved（リクエストが承認された場合）］では、リクエストが承認されたときにOktaが送信するメール通知を指定します。Oktaがアプリの統合をダッシュボードに追加すると、リクエスト提出者のダッシュボードに自動的に通知されます。

次のオプションを組み合わせて選択します。
- ［Send email to requester（リクエスト提出者にメールを送信）］：このオプションを選択すると、リクエスト提出者に承認通知が送信されます。
- ［Send email to approvers（承認者にメールを送信）］：このオプションを選択すると、承認者に承認通知が送信されます。
- ［Send email to others..（ほかの人にメールを送信...）］：このオプションを選択すると、指定したメールアドレスに承認通知が送信されます。
［If request is denied（リクエストが拒否された場合）］では、リクエストが拒否されたときにOktaが送信するメール通知を指定します。リクエストが拒否されても、リクエスト提出者のダッシュボードに通知されません。

次のオプションを組み合わせて選択します。
- ［Send email to requester（リクエスト提出者にメールを送信）］：このオプションを選択すると、リクエスト提出者に承認通知が送信されます。
- ［Send email to approvers（承認者にメールを送信）］：このオプションを選択すると、承認者に承認通知が送信されます。
- ［Send email to others..（ほかの人にメールを送信...）］：このオプションを選択すると、指定したメールアドレスに承認通知が送信されます。
［Approver must respond within（承認者の回答が次の期限内に必要）］では、各承認者がリクエストに回答できる時間枠を選択します。ドロップダウンリストから次のいずれかの値を選択します。
- ［1 Week（1週間）］：各承認者は、承認リクエストへの回答期間として1週間与えられます。
- ［30 Days（30日間）］：各承認者は、承認リクエストへの回答期間として30日間与えられます。
- ［Custom time period（カスタム期間）］：各承認者が承認リクエストに回答する必要がある期間を日または週で指定します。
構成可能な時間枠は、承認チェーンの各手順に適用されます。たとえば、承認時間に1週間と指定し、複数の承認者がいる場合、各承認者に回答期間として1週間ずつ与えられます。承認者が3人いる場合、チェーン全体の承認には3週間かかる可能性があります。

承認リクエストが期限切れになるとリクエストはキャンセルされ、リクエストされたアプリへのアクセス許可はエンドユーザーに付与されません。期限切れになったリクエストは明示的に拒否されたリクエストとは分けてログに記録されます。
［If request expires（リクエストの有効期限が切れた場合）］では、リクエストの有効期限が切れたときにOktaが送信するメール通知を指定します。次のオプションを組み合わせて選択します。
- ［Send email to requester（リクエスト提出者にメールを送信）］：このオプションを選択すると、リクエストの有効期限切れ通知がリクエスト提出者に送信されます。
- ［Send email to approvers（承認者にメールを送信）］：このオプションを選択すると、承認者にリクエストの有効期限切れ通知が送信されます。
- ［Send email to others..（ほかの人にメールを送信...）］：このオプションを選択すると、指定したメールアドレスにリクエストの有効期限切れ通知が送信されます。
管理者はリクエストの時間枠を使ってリクエストのサービスレベル契約（SLA）を設定でき、有効期限切れ通知では承認者からの反応がない状況に対応できます。サポートOrganizationが必要に応じてリクエスト者のフォローアップと手動でのリクエスト承認を行えるように、アプリの統合のリクエストの時間枠と承認チェーンについてサポートOrganizationに通知することをおすすめします。
［Save（保存）］をクリックします。

次の手順

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

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