概要

以前から、Okta System Logに書き込まれるイベントを介して、Okta Access RequestsのリクエストフローからOkta Workflowsのワークフローをトリガーする機能がありました。イベントは、開始および終了されるリクエストに対して作成されていました。このアプローチには、リクエストとその処理方法を決定するためにワークフロー内で多くの処理を行うなどの、いくつかの制限があります。また、このアプローチは、リクエストプロセスが開始または終了されるときのワークフローの実行に制限されます。

Okta Access Requestsプラットフォームでは、リクエストタイプフローのどの段階でも、またはResource Centric Access Request（RCAR）承認シーケンス内から、特定のOkta Workflowを呼び出すことができます。この記事では、リクエストタイプを使用して手動で行われる特定のビルディングへのバッジアクセスのリクエストの例で、この統合について説明します。 
 

注：この統合は、Oktaプレビュー環境における早期アクセス（EA）機能です。これは、Admin Consoleの［設定］>［機能］で有効にできます。この機能が一般提供になると、自動的に有効になります。
 

統合の概要

次の図に、統合の概要を示します。

Okta Access RequestsとOkta Workflowsが、2つの主要コンポーネントです（Okta Workforce Identity Cloud（または単にOkta）が果たす役割は大きくありません）。手動プロビジョニングアクティビティ、メールの送信、チケットのロギングなどの、一部のビジネス機能を実装するために、ワークフローがOkta Workflowsに組み込まれています。これらのワークフローは委任されたフローです（これは、アクセスリクエストに対してどのように公開できるかを示しています）。
 

使用可能なワークフローのリストは、Oktaのユーザー、グループ、アプリケーションが同期されるのと同じ方法で、Okta Access Requestsに同期されます（注：ワークフローリストは、一部のセキュリティ構成に基づいてOktaから取得されます）。
 

特定のOkta Workflowを呼び出すための新しいアクションがアクセスリクエストにあり、リクエストタイプフローの任意の時点に追加できます。
 

このアクションでは、リクエストタイプフロー内のデータからフィールドセットを入力するように求められます。これらのフィールドは、ワークフローの［Delegate Flow（委任フロー）］カードのフィールドと同じです。これらのフィールドに渡される値は次のいずれかです。

• ［Requester email（依頼者メール）］、［リクエスト件名］、または［Request assignee’s email（リクエスト割り当て先のメール）］の標準リクエストタイプ属性のいずれか
• ビジネス上の正当性や終了日などの、フロー内の質問に関連付けられているフィールド

これには、いくつかの制約があります。

• ワークフローに渡せるフィールドは、テキスト、数値、日時、またはtrue/falseのみです。オブジェクト（Oktaアクションなど）は渡すことができません。
• 現在、リクエストIDをワークフローに渡す方法はありません。
• ワークフローからリクエストタイプフローには何も返せません。これは一方向の実行であり、アクセスリクエストフローはワークフローを呼び出したらすぐに処理を続行します。

上記の制約を踏まえて、統合を構成する方法を以下に示します。

統合の構成

この統合では、次の4つのアクティビティのセットを構成する必要があります。

1. アクセスリクエストフローから呼び出すことができるOkta Workflowsのワークフロー。複数のワークフローを構成できますが、必要なのは1つです。
2. アクセスリクエストにワークフローの可視性を持たせるために、Okta Workforce Identity Cloudでいくつかのロールとリソースの定義が必要です。
3. チームと構成リストに関して、いくつかのアクセスリクエストの構成が必要です。
4. ワークフローを呼び出すために、アクセスリクエストフローが必要です。

これらについては、以下のセクションで詳しく説明します。
 

この記事の例は、1つのビルディングへのアクセスをリクエストするためのアクセスリクエストフローを実装するサンプル要件に基づいています。これを自動的に行う方法はないため、リクエストを手動で実行し、終了したらリクエストをクローズするために、チームにメールを送信する必要があります。このチームは、アクセスリクエストで特定の「チーム」として定義され、アクセスリクエストで割り当てられたチームメンバーにメールが送信されます。
 

Okta Workflowsでのワークフローの構築

まず、ワークフローを作成します。技術的にはこれは後で行うこともできますが、最初に行う理由は次のステップでわかります。まだ完璧である必要はありませんが、作成しておく必要があります。
 

最も重要なのは、このフローが委任されたフローであるということです。これは、［委任されたフロー］カードで開始されます。このカードには、アクセスリクエストフローから渡されるフィールドが含まれています。この例のフローでは、依頼者のメール、ビジネス上の正当性、アクセスがリクエストされたビルディング、割り当て先のメール（つまり、このリクエストを自動的に割り当てられたバッジアクセスチームメンバー）、追加のビルディングアクセスの終了日が使用されます。
 

フローのステップはカスタマイズできますが、この例のフローでは、Oktaでユーザーを検索して名前とメールの詳細を取得し、テキストを作成して、割り当て先にメールを送信します。

 

 

注：このワークフローは、Okta Workflowsのどこに保存されていてもかまいません。このワークフローへのアクセスはOktaのセキュリティポリシーによって制御されます。これは、委任されたフローであることのみを前提としています。このフローをアクセスリクエストタイプのセットアップで使用するには、フローが有効である必要があります。

Oktaでのロールとリソースの構成

カスタムのロールとリソースを作成して、アクセスリクエストに使用可能なワークフローの可視性を持たせます。 

1. まず、アクセスリクエストが委任されたフローにアクセスするための新しいOkta管理者ロールを作成します（Okta Workflowsで委任されたフローを実行する必要がある他のユーザー/アプリと同様）。［管理者］の［ロール］タブに移動し、［委任されたフローを実行］のワークフロー権限を持つ新しいロールを作成します。

2. 次に、［リソース］に移動して新しいリソースセットを作成し、リソースセットに名前を付けて、アクセスするフローを選択します（注：すべての委任されたフローにアクセスすることもできます。アクセスリクエストに委任されたフローのみを使用する場合は、こちらの方が簡単な場合があります）。 

3. 新しいロールに戻り、割り当てを編集して、Okta Access Requests OAuthアプリケーションを上記で作成した新しいリソースセットに紐付けします。

4. これを保存すると、アクセスリクエストアプリはリソースセットで指定されているすべてのOkta Workflowsの可視性を持つことができます。
    

Okta Access Requestsの構成

これはアクセスリクエストへの新しい統合であるため、アクセスリクエストでの統合のセットアップと同様の、いくつかの初期構成手順があります。
 

この例では、統合用に新しいチームが作成されているため、バッジアクセスチームのメンバーをリクエストやメールの送信に対して動的に割り当てることができます。

既存のチームを使用できます。新しいチームが作成されたら、［設定］>［リソース］でワークフローへのアクセスを許可します。 

この新しいチームは、チームに割り当てられたリクエストタイプフローで使用されるその他のリソースまたは構成リストにもアクセスできる必要があります。

• たとえば、プルダウンリスト用に構成リストを構築する場合は、以下のBuildingsリストのように、それに対してチームを割り当てる必要があります。

また、アクセスリクエストコンソールでチームをOkta接続に追加する必要もあります。［設定］>［統合］に移動し、Okta構成の［Edit connection（接続を編集）］をクリックし、チームが選択されていることを確認すると、［Run a workflow（ワークフローを実行）］が有効になります。

最後に考慮するのは、Oktaからアクセスリクエストへのワークフローリストの同期です。これは通常、24時間の更新サイクルで行われますが、すぐに更新をリクエストすることもできます（バックグラウンドで実行されます）。

これにより、ワークフローを呼び出すリクエストタイプを構築できます。
 

ワークフローアクションを使用したフローの構築

Okta Workflowをアクセスリクエストに対して定義していれば、他のアクションと同様にそれらをフローに含めることができます。

この例のリクエストタイプフローでは、ユーザーは正当性を入力し、アクセスする必要があるビルディングを選択し、アクセス権を削除する終了日を選択するよう求められます。1つの承認レベル（つまり、そのマネージャー）が適用されます。キー情報がOkta Workflowに渡されます。フローの最後のステップはカスタムタスクで、割当先（メールを受信するチーム内のメンバーなど）がアクセス権を変更した後にリクエストに戻り、リクエストをクローズします。

Manual Provisioning ステップで、Okta Workflowが呼び出されます。
 

アクションを構成するときに、使用可能なワークフローのリストからワークフローを選択します。これにより、ワークフローの［委任されたフロー］カードで想定されるフィールドのリストが入力されます。この例では、次の5つのフィールドがあります。

公開すると、このリクエストタイプと関連するワークフローをテストする準備が整います。
 

統合のテスト

これをテストするには、ユーザーのリクエストを開始し、マネージャーに承認してもらい、ワークフローの実行を確認し、最後に割り当て先としてリクエストをクローズします。
 

アクセスのリクエスト

ビルディングアクセスのリクエストは、他のすべてのリクエストと同じ方法で、アクセス リクエストポータルまたはチャットインターフェイスのいずれかで開始されます。

要求されたフィールドにユーザーが入力します。

送信されると、リクエストの実行履歴が表示されます。

通常どおり、マネージャーにメールまたはチャットで通知が送られます。または、マネージャーがアクセスリクエストポータルにいる場合は、マネージャーのリクエストリストに通知が表示されます。マネージャーがレビューして承認します。

ワークフローの実行

承認されると、Okta Workflowを呼び出すアクションが実行されます。

ワークフローが実行され、この例では、割り当て先へのメールが生成されます（割り当て先は、リクエストが割り当てられたことを知らせる一般的な通知もアクセスリクエストから受け取ります）。メール本文では、アクセスリクエストからの属性値に置き換えられています。

ワークフローの実行履歴を確認し、アクセスリクエストからワークフローに渡されたデータとその使用方法を確認します。

完了

最後のステップでは、割り当て先がリクエストに戻ってリクエストを完了します。バッジアクセスはメール主導の手動タスクであるため、手動での作業が完了するまでリクエストをオープン状態のままにします。これは、最後にカスタムタスクを使用することで可能になります。
 

これで、エンドツーエンドのフローは完了です。

 

おわりに

この記事では、Okta System Logでイベントを使用する以前の機能に加えて、Okta Access Requestsフロー内からOkta Workflowを実行する方法について説明しました。また、統合と、ワークフローに渡せるものと渡せないものについても説明しました。

この記事の大部分では、バッジアクセスを管理するチームにメールを送信するワークフローを呼び出す前に承認が必要になる、ビルディングの手動バッジアクセスリクエストの例を使用して、統合されたフローのペア（Okta Workflowを呼び出す1つのアクセスリクエストフロー）の構成とテストについて説明しました。この例は、統合がどのように機能するかを示すために設計されています。

関連資料

• Okta Access Request - アクセスリクエストタイプの作成
• Resource Centric Access Requests（RCAR）
• Okta WorkflowsでのV2アクセスリクエストの活用
• V2アクセスリクエスト（RCAR）でOkta Workflowが実行されない
• Okta Workflows - 「委任されたフロー」および「委任されたフローの構築」を参照してください。
• アクセスリクエスト内のOkta Workflowsアクションは早期アクセス機能です。有効にする方法については、「早期アクセス機能とベータ機能の管理」を参照してください。 

Okta Identity Governanceのヘルプが必要な場合は、Okta Identity Governanceの製品ハブにアクセスするか、Okta Identity GovernanceチームとOffice Hoursをスケジュールしてください。