Okta Access Requests の「Conditions」と「Request types」の違いはなんだろう？
はじめに
皆様こんにちは、あかいけです。
最近Okta Identity Governance(OIG)のAccess Requests機能を設定する機会がありました。
ただ設定を進めていく中で、
「あれ、申請フォームを作成できる場所が2箇所ある...?」と戸惑う場面がありました。
具体的には「各アプリのAccess requestsタブ (Conditions)」と「Okta Access Requestsアプリ (Request types)」という2つの設定場所があり、初めて触った私はめちゃくちゃ混乱しました。
なので今回は、この2つの違いについてまとめてみました。
同じく混乱している方の参考になれば幸いです。
Okta Access Requestsとは
Okta Access Requestsは、Okta Identity Governance(OIG)の機能の一つで、
ユーザーがアプリ、グループなどへのアクセスをリクエストするプロセスをワークフローとして作成できます。
従来の課題
従来ではアクセス申請/承認は手動プロセスで行われていました。
例えば「Slackで上長に連絡 → 上長がIT部門にメール → IT部門が手動で権限付与」といった流れです。
このような手動プロセスには以下の問題がありました。
- ユーザー体験の低さ: 申請方法がわかりにくい、進捗が見えない
- 人的エラーのリスク: 手作業での権限付与はミスが発生しやすい
- IT部門の生産性低下: 定型作業に時間を取られる
- 監査対応の困難さ: 誰がいつ承認したかの記録が一元的に管理されない
Okta Access Requestsで解決できること
Okta Access Requestsを使用することで、これらの課題を解決できます。
- セルフサービス化: ユーザーがダッシュボードから直接アクセスをリクエスト
- 承認依頼の自動通知: 承認者へリクエストが自動的に通知される
- ノーコードでワークフロー構築: 申請/承認フローをGUIで設定可能
- 外部アプリケーション連携: Slack、Microsoft Teams、Jira、ServiceNowなどと統合し、リクエスト/承認が可能
- 監査の自動記録: 誰がいつ何を申請/承認したかなどが自動で記録される
2つのAccess Requestsは一体何がどう違う?
さて、本題です。
まずAccess Requestsのフォームを作成できる場所は以下の2つがあります。
| 設定場所 | 方式名 |
|---|---|
| 各アプリのAccess requestsタブ | Conditions(条件) |
| Okta Access Requestsアプリ | Request Types(リクエストタイプ) |
そして以下はそれぞれの公式ドキュメントの引用ですが、
おそらくこれだけで理解でき方はいないでしょう…。
- 条件
条件は、誰がアクセスをリクエストできるか、リクエストできるアクセスのレベル、アクセス期間、Admin Consoleでのアプリのプロファイルページからの直接的な各アプリの承認シーケンスを定義するルールです。承認シーケンスは、質問、Okta Workflows、承認、タスクなどの一連の直線的なステップです。これらのステップは、特定のユーザーが提供する必要がある情報、要求の承認または拒否を担当するユーザー、完了する必要があるアクションを管理します。
条件を使ってリソースへのアクセスを管理する場合、要求者は直接End-User Dashboardに移動してリソースのタイルを選択し、アクセスをリクエストするために必要な情報を入力できます。
アクセスリクエストを初めて使用するときは、最初に条件を使ってアクセスリクエストを管理します。
- リクエストタイプ
リクエストタイプは、リクエストのライフサイクルを定義する構造化フローです。これらのフローは、質問、タスク、タイマーなどのステップから構成されます。リクエストタイプは、構成リストを使ってリソース（アプリ、グループ、エンタイトルメントバンドル）と関連付けることができます。各アクセスリクエストチームは、複数のリクエストタイプと関連リクエストを所有および管理します。自動化された一部のアクションは、Oktaや、Jira、ServiceNowなどの統合外部システムでセットアップすることもできます。
要求者は、リクエストタイプを使ってエンドユーザーダッシュボードからOkta アクセスリクエストWebアプリに移動してリクエストタイプを選択し、アクセスを要求するために必要な情報を入力します。要求者は、SlackまたはMicrosoft Teamsからアクセスを要求することもできます（アクセスリクエストと統合されている場合）。
リクエストタイプを作成してOkta管理者ロールバンドルのアクセスリクエストを管理することはできません。また、リクエストタイプによって管理されるアクセスリクエストを使って、Okta管理者ロールを付与するグループを割り当てることはできません。このようなグループをリクエストしたユーザーは、リクエストの詳細ページでエラーを受け取ります。
というわけで、
それぞれ実際の設定画面や申請画面を詳しく見ていきます。
OktaアプリのAccess requestsタブ(Conditions方式)
こちらは 各アプリケーションのプロファイルページから直接設定する方式 です。
管理者の設定画面
管理者は以下の手順で申請フォームを作成できます。
Admin Consoleのアプリケーションのアクセスリクエストのタブを開くと、以下のような画面が表示されます。
ここの「+ Create condition」ボタンから条件を作成します。
Create conditionをクリックすると、条件の設定画面が表示されます。
条件では以下の項目を設定できます。
- リクエスター範囲: 組織全体のユーザー、または特定のグループ
- アクセスレベル: アプリのみ、関連するグループ
- アクセス期間: 固定期間、またはユーザーに指定させる
- 承認シーケンス: 既存のシーケンスを選択、または新規作成
Approval sequenceでは、承認フローを新規作成するか、既存のシーケンスを選択できます。
New sequenceを選択すると、承認シーケンスの作成画面が表示されます。
Trigger(開始)とDeliver(完了)の間にステップを追加していきます。
Templatesボタンをクリックすると、よく使われる承認パターンのテンプレートを選択できます。
「Justification + Manager Approval」など、すぐに使えるテンプレートが用意されています。
Saveの際に任意の名前をつけます。
承認シーケンスを作成すると、選択リストに表示されるようになります。
その後、以下はもろもろ設定した画面です。
設定が完了したら、Createボタンをクリックして条件を作成します。
作成完了直後は「Disabled」になっているので、右のメニューから「Enabled」に変更します。
利用者(申請者)の申請画面
利用者は以下の手順でアクセスをリクエストします。
End-User Dashboardの右上に「アクセスを要求する」ボタンがあります。
ここからConditions方式で設定されたアプリへのアクセスを申請できます。
Request Access画面では、アクセス可能なアプリが一覧表示されます。
検索ボックスでアプリを絞り込むこともできます。
アプリを選択すると、アクセスレベルの選択画面が表示されます。
管理者が設定した項目(アクセス期間、申請理由など)を入力して申請します。
申請が完了すると、Access Requestsコンソールで申請状況を確認できます。
承認待ち(IN PROGRESS)のステータスや、承認者の情報が表示されます。
申請が送信されると、承認者にメールで通知が届きます。
メールには申請者、リソース、アクセスレベル、アクセス期間、申請理由などの情報が含まれます。
ポイントは、利用者はEnd-User Dashboardから直接リクエストできるという点です。
専用のアプリを開く必要がなく、直感的に申請できます。
Okta Access Requestsアプリ(Request Types方式)
こちらは専用のAccess Requestsコンソールから設定する方式です。
管理者の設定画面
管理者は以下の手順で設定を行います。
End-User Dashboardのマイアプリ一覧に「Okta Access Requests」アプリが表示されています。
これをクリックしてAccess Requestsコンソールを開きます。
Access Requestsコンソールの「Request Types」画面です。
まだRequest Typeが作成されていない場合は、以下のような画面が表示されます。
「Create request type」をクリックすると、Request Type Detailsダイアログが表示されます。
名前、説明、担当チーム、対象者(Audience)を設定します。
設定例です。
名前に「okta-access-request-test」、チームに「IT」、対象者に「okta-test-aws-read」グループを指定しています。
リクエストタイプでは以下の要素を組み合わせてフローを構築できます。
- Question: ユーザーから情報を収集するための質問
- Task: 承認者やタスク担当者へのアクション依頼
- Approval: 承認/拒否を依頼
- Action: 他のアプリでアクションをトリガー(Okta Workflowsなど)
- Timer: フロー内のタイミング制御
「Add a step to the request type」画面で、
Question、Task、Approval、Actionなどのステップを追加できます。
以下は作成したRequest Typeの詳細画面です。
Questionsセクションには申請者への質問項目、Tasks & Actionsセクションには承認フローやアクションが表示されます。
この例では、申請理由の入力、権限の選択、権限付与日時の指定などの質問と、承認フェーズ、待機タイマー、自動アクション(権限付与/剥奪)が設定されています。
これらの設定についての具体的な設定方法については、よろしければ以下ブログをご参照ください。
利用者(申請者)の申請画面
利用者は以下の手順でアクセスをリクエストします。
利用者視点のAccess Requestsコンソールです。
作成されたRequest Type「okta-access-request-test」が表示されており、「Request access」ボタンから申請を開始できます。
Request Typeで設定した質問項目(申請理由、権限の選択、権限付与日時など)を入力して申請します。
申請が完了すると、Access Requestsコンソールで申請状況を確認できます。
申請が送信されると、承認者にメールで通知が届きます。
ポイントは、利用者も専用のAccess Requestsアプリを開いて申請するという点です。
Conditions方式とは異なり、専用アプリ経由でのリクエストになります。
2つの方式の比較
ここまで設定してきた内容や公式ドキュメントを確認した結果から、
2つの方式の比較をしてみます。
管理者(設定者)の視点
| 観点 | Conditions | Request Types |
|---|---|---|
| 設定場所 | アプリのAccess requestsタブ | Access Requestsコンソール |
| 設定の複雑さ | シンプル (テンプレートを使用する場合) |
カスタマイズ性が高く複雑 |
| カスタマイズ性 | 質問、承認、タスク、Okta Workflows | 質問、承認、タスク、アクション、タイマー |
| 承認シーケンス | 複数アプリで再利用可能 | Request Typeごとに設定 |
利用者(申請者)の視点
| 観点 | Conditions | Request Types |
|---|---|---|
| 申請場所 | End-User Dashboard | Access Requestsアプリ |
| 申請の導線 | ダッシュボードから直接 | 専用アプリを開く必要あり |
| Slack/Teams対応 | 対応 | 対応 |
| Jira SrviceNow対応 | 非対応 | 対応 |
| 申請時の入力項目 | 承認シーケンスで設定した質問項目 | Request Typeで設定した質問項目 |
どちらを使うべき?
Oktaの公式ドキュメントでは、
新規ユーザーにはConditions方式を推奨しているように見えます。
アクセスリクエストを初めて使用するときは、最初に条件を使ってアクセスリクエストを管理します。
私の所感としても、以下のように使い分けるのが良いと思います。
- まずはConditions方式から始める
- シンプルでわかりやすく、アプリ単位で管理できる
- 複雑な要件が出てきたらRequest Types方式を検討
- 条件分岐や複数ステークホルダーの承認が必要など複雑な要件の場合に検討する
もちろん、両方の方式を併用することも可能です。
ただし、同じリソースに対して両方の方式を設定すると混乱の元になるので、最終的にはどちらかに統一するのが良いのではないかと思います。
補足: 統一された要求者のエクスペリエンスについて
本記事ではConditionsとRequest Typesで申請者の申請場所が異なると記載しましたが、
「統一された要求者のエクスペリエンス」(Unified requester experience)を有効にすることで、申請場所を統一できます。
この機能は早期アクセスリリース(Early Access)のため、利用するには「セルフサービス機能を有効にする」の設定が必要です。
私はまだ試していないので、試す機会があればまたブログにしたいと思います。
統一された要求者のエクスペリエンスを有効にすると、リソースアクセスの管理方法(条件によるかリクエストタイプによるか)にかかわらず、リソースへのアクセスをリクエストするプロセスは同じになります。管理者は、要件に基づいていずれかまたは両方の方法を柔軟に組み合わせて使用し、要求者のエクスペリエンスを変更することなくリソースアクセスを管理できます。
さいごに
以上、「Conditions」と「Request types」の違いについてまとめました。
正直なところ、初めて触ったときは「なぜ2箇所あるんだろう...」とかなり混乱しました。
ただ、それぞれの方式には明確な用途の違いがあり、理解してしまえばスッキリします。
私と同じく、Access Requestsの設定で迷っている方の参考になれば幸いです。
