アクセスリクエストを開始する
リソースに対するアクセスリクエストを管理するには、スーパー管理者またはアクセスリクエスト管理者である必要があります。
管理者ロールのアクセスリクエストを管理するには、代わりに「管理者ロールのアクセスリクエスト」と「はじめに」を参照してください。
開始する前に、アクセスリクエストの構成と管理に使用する方式を決定します。
セットアップ、メンテナンスタスク、制限は方式ごとに異なります。
アクセスリクエストにアクセスする前に、orgの標準Okta IPを必ず許可リストに登録します。「Okta IPアドレスへのアクセスを許可する」を参照してください。
条件
早期アクセスリリース。「セルフサービス機能を有効にする」を参照してください。
初期セットアップタスク
スーパー管理者として、またはアクセスリクエスト管理者ロールとアプリ管理者ロールの両方を持つユーザーとして、次のタスクシーケンスに従ってアプリの条件を構成します。
管理者タスク |
説明 |
---|---|
アクセスリクエスト条件 | アクセスリクエスト条件の紹介。 |
Access request conditions and Resource catalog(アクセスリクエスト条件およびリソースカタログ)機能を有効にする | この機能を有効にすると、org内のすべてのユーザーは暗黙的にOkta アクセスリクエストリソースカタログアプリに割り当てられます。既存のすべてのスーパー管理者には、自動的にOkta アクセスリクエスト管理者アプリが割り当てられます。
Oktaアクセスリクエストアプリをまだ利用していない場合、この機能を有効にするとこのアプリが自動的に追加されます。既存のすべてのスーパー管理者とアクセスリクエスト管理者には、自動的にOkta Access Requestsアプリが割り当てられます。 |
任意。新しい認証ポリシーをセットアップする |
これは任意の手順です。ユーザーエクスペリエンスを向上させるために、次のアプリの認証ポリシーを変更します。
|
アクセスリクエスト統合 | Jira、Slack、またはMicrosoft Teamsとアクセスリクエストを統合することで、追加タスクの実行が可能になります。 |
アクセスリクエスト条件を作成する | どのユーザーが特定のアプリへのアクセスを要求できるか、それらのユーザーがアクセスできる時間はどれくらいか、それらのユーザーのアクセスリクエストを承認するのは誰かを定義します。作成した条件はデフォルトで非アクティブ状態になるため、有効化するまで機能しません。 |
条件を有効にする | 新しいアクセスリクエスト条件を有効化してアクティブにします。 |
メンテナンスタスク
スーパー管理者として、またはアクセスリクエスト管理者ロールとアプリ管理者ロールの両方を持つユーザーとして、初期セットアップ後に必要に応じて次のタスクを完了します。
管理者タスク |
説明 |
---|---|
条件を管理する | 条件を有効化、無効化、表示、編集、削除するか、条件の優先順位を変更します。 |
承認シーケンスを管理する | 既存の承認シーケンスを変更してタスクと条件を追加または削除します。シーケンスに加えた変更は、そのシーケンスを利用するすべてのアクセスリクエスト条件に影響します。 |
リクエストタイプ
初期セットアップタスク
アクセスリクエストの使用を開始するには、スーパー管理者またはアクセスリクエスト管理者として次の構成タスクシーケンスに従います。
管理者タスク |
説明 |
---|---|
リクエストタイプ | リクエストタイプとそのコンポーネントの紹介。 |
リクエストタイプに合わせてOkta orgを構成する | リクエストタイプで使用する必要があるOkta内の設定とアイテムを構成します。 |
アクセスリクエストチームを作成する | 誰が新規リクエストを構成でき、誰が既存のリクエストを管理できるかを決定するチームを作成します。 |
構成リストを作成する | リソースへのエンドユーザーのアクセスをチームが自動化できるように、構成リストを作成します。構成リストを利用することで、リクエストの処理時にエンドユーザーが利用できる特定のオプションをチームが制御することもできます。 |
アクセスリクエスト統合 | Jira、ServiceNow、Slack、またはMicrosoft Teamsとアクセスリクエストを統合することで、追加タスクの実行や同期済み情報の利用が可能になります。 |
リクエストタイプを作成する | カスタマイズ可能なコードなし構造のリクエストタイプを作成します。これは、リクエストを通じてユーザーにアクセス権を付与する方法を定義、自動化します。 |
リクエストを管理する | リクエストの送信後にリクエストを管理するために管理者または割り当て先が実行する必要がある手順について理解します。彼らは常に、使用されているリクエストのリクエストタイプを所有するアクセスリクエストチームのメンバーである必要があります。 |
メンテナンスタスク
初期セットアップの後に、必要に応じてスーパー管理者として次のタスクを完了します。
管理者タスク |
説明 |
---|---|
過去のアクセスリクエストのレポートを生成する | リソースと関連データポイントへのアクセスを誰が要求したか(アクセス権が付与されたかどうか、誰がアクセス権を付与したかなど)を表示します。 |
エンドユーザーエクスペリエンス
ユーザータスクについて管理者の観点から理解します。
ユーザータスク |
説明 |
---|---|
リクエストを作成する | アクセスリクエストWebアプリ、Slack、Microsoft Teamsなどの方法で要求者がリクエストを送信する方法を理解します。アプリの条件がセットアップされている場合、要求者は自分のダッシュボードから直接アプリへのアクセスを要求できます。 |
リクエストを管理する | 条件またはリクエストタイプによって管理されるリクエストを管理するために、割り当て先が実行する必要がある手順を理解します。 |
タスクを管理する | リクエスト承認者がアクセスリクエストWebアプリからリクエストを承認または拒否する方法を理解します。リクエストは、条件またはリクエストタイプによって管理できます。 |
制限
組織、条件、リクエストタイプ、リクエストに適用される制限事項がいくつかあります。次の表を参照してください。
組織
組織が持つことができるユーザーの最大数は100,000です。
条件
制限 | 最大 |
---|---|
各アプリの条件 | 100 |
条件内の要求者スコープの定義に使用されるグループ | 100 |
組織内のすべての条件の要求者スコープの定義に使用される一意のグループ | 100 |
条件のアクセススコープ内のエンタイトルメントバンドル | 100 |
承認シーケンス内のステップ | 10 |
質問ステップ内の質問 |
5 |
リクエストタイプ
制限 | 最大 |
---|---|
各組織のアクティブなリクエストタイプ | 500 |
各リクエストタイプ内のタスク | 100 |
各リクエストタイプ内のフィールド | 100 |
使用されるアプリケーション | 5,000 |
使用されるグループ | 15,000 |
プッシュされたグループ内のユーザーの人数 | 25,000 |
構成リスト | 100 |
構成リストのアイテム | 1,000 |
リクエスト
制限 | 最大 |
---|---|
組織ごとのオープンまたは保留中のリクエスト | 10,000 |
組織ごとの解決済みのリクエスト (アプリケーション内でアクセス可能なリクエストのみがカウントの対象です) |
50,000 |
リクエストごとのタスク | 100 |
リクエストごとのフィールド | 100 |
リクエストごとのフォロワー | 100 |
リクエストごとの更新 | 500 |
リクエストリストフィルター値 | 25 |