リクエストの作成と承認
リクエストを管理するためのアクセスリクエストの設定方法に応じて、アクティブなリクエストタイプまたは条件が1つ以上ある場合、要求者は Okta End-User Dashboard、Slack、またはMicrosoft Teamsを使ってリソース向けのリクエストを送信できます。
送信したリクエストに対してチームメンバーまたは承認者が何もアクションを起こさないときは、要求者はアクセスリクエストWebアプリを使ってそのリクエストをキャンセルできます。要求者には、自分でセットアップした通知設定に基づいて、リクエストのキャンセルに関する通知が送信されます。
両方のユーザーがリクエストタイプまたは条件のオーディエンスである場合、ユーザーは、エンドユーザーダッシュボード、Slack、またはMicrosoft Teamsから別のユーザーに代わってリクエストを送信することもできます。リクエスト作成者と要求者は通知設定に基づいて、リクエストに関する通知をMicrosoft TeamsとSlackで受信できます。リクエストを作成したユーザーはSystem Logに記録されます。
たとえば、マネージャーは新入社員に代わってアプリへのアクセスを要求して、新入社員が最初の日に利用できるようにすることができます。新入社員はチームに参加した後にアプリへのアクセスをリクエストする必要はありません。
Org全体のアクセスリクエストの設定
アクセスリクエストの設定のほとんどは、構成したアプリ、リソースコレクション、管理者ロールにのみ適用されます。別のユーザーに代わってアクセスを要求できるユーザーや、職務分掌の競合の処理方法をセットアップするには、「アプリの要求設定を構成する」を参照してください。
その他の設定はorg全体に適用されます。これらの設定は、アプリまたはリソースコレクション固有の構成に関係なく、すべてのユーザー、アプリ、リソースコレクションに影響します。
アクセスを要求する（Request access）ボタンとリソースカタログを表示および使用できるユーザーを制御できます。「リソースカタログエントリポイントの可視性を構成する」を参照してください。
要求者のエクスペリエンス
Oktaエンドユーザーダッシュボードを使用してアクセスをリクエストする
- アクセスリクエスト条件によって管理されるリクエスト：
アプリまたはリソースコレクションのアクセスリクエスト条件を設定する場合、これらの条件を満たすユーザーはダッシュボードのリソースカタログ、Slack、またはMicrosoft Teamsから直接アプリまたはコレクションへのアクセスをリクエストできます。条件に要求者が指定したアクセス期間が含まれる場合、ユーザーはアクセスに必要な期間（設定する制限期間まで）を示します。
アプリに職務の分離（SoD）ルールを定義し、アプリまたはリソースコレクションにアクセスリクエスト設定を構成した場合は、アクセスリクエスト設定応じて、要求者のエクスペリエンスが異なる可能性があります。「アプリリクエスト設定を構成する」を参照してください。
デフォルトでは、すべてのリクエストはプライベートとしてマークされるため、これを表示できるのは、要求者、リクエスト割り当て先、リクエスト内のステップが割り当てられているユーザーのみです。
アクセスリクエストを初めて使用するときは、最初に条件（conditions）を使ってアクセスリクエストを管理します。
- リクエストタイプによって管理されるリクエスト：
アクティブなリクエストタイプが1つ以上ある場合、要求者はOktaエンドユーザーダッシュボード、Slack、またはMicrosoft Teamsを使ってリソース向けのリクエストを送信できます。
ユーザーがダッシュボードからアクセスを要求すると、リクエストタイプがアプリやコレクションの横にタイルとして表示されます。リクエストタイプのオーディエンスの設定は、引き続きどのユーザーがダッシュボードとリクエストアクセスでリクエストタイプを表示できるかを管理します。
デフォルトでは、すべてのユーザーがリクエストを表示できます。送信されたリクエストをプライベートとしてマークできます。または、チーム設定を更新して、チームのすべての受信リクエストをプライベートとしてマークできます。「アクセスリクエストのチームを作成する」を参照してください。
「Oktaエンドユーザーダッシュボード」を参照してください。
SlackとMicrosoft Teamsを使用してアクセスをリクエストする
SlackまたはMicrosoft Teamsを通してリクエストする際、要求者がI need a Grammarly accountやI need to access Jiraというメッセージを送信すると、Oktaはリクエストに最適なリソースを特定しようとします。Oktaがリクエストの分類を誤った場合、要求者はリクエストを手動で調整できます。
Slackとの統合後、ユーザーが実行できるアクションを設定（Settings）ページから制御できます。リクエストを送信（Submit requests）トグルをオンにしている場合、ユーザーはエンドユーザーダッシュボードにリダイレクトされることなく、Slackから直接アクセスリクエストを送信できます。このトグルは、リクエストタイプによる管理と条件による管理の両方のアクセスリクエストに適用されます。
「Slack」と「Microsoft Teams」を参照してください。
ユーザーがSlackを使用してリクエストを送信または承認する場合、OktaセッションではなくSlackセッションを使用します。org向けのグローバルセッションポリシーとアプリサインインポリシーを構成する際は、この点に留意してください。「SlackとMicrosoft Teamsを統合するための考慮事項とベストプラクティス」を参照してください。
承認者のエクスペリエンス
承認者のエクスペリエンスは、承認者がOkta アクセスリクエスト Webアプリ、Slack、Microsoft Teams、メールのどこでアクションを実行するかによって異なります。Okta アクセスリクエスト Webアプリでの承認手順については、「タスクを管理する」を参照してください。