セルフサービス承認ワークフローを構成する
セルフサービス機能を有効にすると、承認ワークフローを構成できるようになります。これにより、アプリ所有者はユーザーにアクセス権を付与し、エンタイトルメントを割り当てることができます。このアクションにより、ユーザーからのアプリリクエストの取り扱いがITグループからアプリ所有者に移行されます。
このワークフローは、個人用の属性を必要とするアプリでは使用できません。
開始する前に
- 必ずスーパー管理者またはアプリ管理者としてサインインしてください。
- orgでセルフサービス機能が有効化されていることを確認します。「セルフサービス用にorgを構成する」を参照してください。
このタスクを開始する
-
Admin Consoleで、に移動します。
- 構成するアプリ統合を検索し、選択します。
- 割り当て（Assignments）タブを選択します。
- セルフサービス（SELF SERVICE）セクションで編集（Edit）をクリックします。
- リクエスト（Requests）セクションでユーザーによるアプリのリクエストを許可（Allow user to request app）をYesに設定します。
- 任意。要求者向けに、統合について説明したり、リクエストしているユーザーに指示を与えたりするためのメモを入力します。最大文字数は500文字です。
- 承認（Approval）セクションで必須（Required）を選択します。注:
アプリ統合の承認ステータスを必要（Required）から不要（Not Required）に変更すると、承認待ちのリクエストはすべて削除されます。管理者用には、Okta System Logに削除されました（Deleted）というメッセージが表示されます。Oktaはエンドユーザーにリクエストの削除を通知しません。
-
アプリのリクエストの送信先（Send app requests to）で、アプリのリクエストを承認するユーザーまたはグループを指定します。
- ドロップダウンリストからユーザー（Users）またはグループ（Groups）を選択します。
- フィールドにユーザー名またはグループ名を入力します。リストから一致するユーザーまたはグループを選択します。注:
承認者として指定されたグループに含めることができるメンバーは100人までです。
- エンタイトルメント（Entitlements）ドロップダウンリストから承認者の権限を選択します。
- 非表示（Hidden）：承認者はアカウント属性を表示できません。
- 参照（Read）：承認者はアカウント属性を表示できますが変更できません。
- 書き込み（Write）：承認者はアカウント属性を編集できます。
- 任意。ユーザーまたはグループをさらに追加して、承認チェーンを作成します。承認者の順序を変更するには、手順番号の左側にある点線のハンドルをクリックし、目的の位置までドラッグします。承認チェーンは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週間（1 Week）：各承認者は、承認リクエストへの回答期間として1週間与えられます。
- 30日間（30 Days）：各承認者は、承認リクエストへの回答期間として30日間与えられます。
- カスタム期間（Custom time period）：各承認者が承認リクエストに回答する必要がある期間を日または週で指定します。
構成可能な時間枠は、承認チェーンの各手順に適用されます。たとえば、承認時間に1週間と指定し、複数の承認者がいる場合、各承認者に回答期間として1週間ずつ与えられます。承認者が3人いる場合、チェーン全体の承認には3週間かかる可能性があります。
承認リクエストが期限切れになるとリクエストはキャンセルされ、リクエストされたアプリへのアクセス許可はエンドユーザーに付与されません。期限切れになったリクエストは明示的に拒否されたリクエストとは別にログに記録されます。OktaOkta
- リクエストの有効期限が切れた場合（If request expires）では、リクエストの有効期限が切れたときにOktaが送信するメール通知を指定します。
- 要求者にメールを送信（Send email to requester）：このオプションを選択すると、要求者にリクエストの有効期限切れ通知が送信されます。
- 承認者にメールを送信（Send email to approvers）：このオプションを選択すると、承認者にリクエストの有効期限切れ通知が送信されます。
- ほかの人にメールを送信...（Send email to others..）：このオプションを選択すると、指定したメールアドレスにリクエストの有効期限切れ通知が送信されます。
注:管理者はリクエストの時間枠を使ってリクエストのサービスレベル契約（SLA）を設定でき、有効期限切れ通知では承認者からの反応がない状況に対応できます。サポートOrganizationが必要に応じてリクエスト者のフォローアップと手動でのリクエスト承認を行えるように、アプリ統合のリクエストの時間枠と承認チェーンについてサポートOrganizationに通知することをおすすめします。Okta
- 保存（Save）をクリックします。
次の手順