Okta Workflowsを簡単に紹介
先日GAになったばかりのWorkflowsの機能についてご紹介します。
未だによくわからないという方も多くいらっしゃると思いますので、是非一緒にみていきましょう！
ちなみに、さらっと触った感触ですが、そもそも別サービスであったものを取り入れただけあって、できることが大幅に広がりました。
ちょっと高価だなと思っていたAdvanced-Lifecycle Managementですが、値段以上の価値があると思います。
*新しい機能（玩具）を触ったテンションのため評価が上振れ気味です。
本記事は2020/05の機能初実装時点の記事となりますので、時間経過によっては実際の環境と機能差異があります。
また、修行中の身であるため、あまり複雑なフローはご紹介できません。
はじめに
ワークフローというと何を思い浮かべるでしょうか？
誰かが「申請」して、上長が「承認」→「承認」→……→「処理」
なんてイメージの方も多いと思います。私も初めはそうでした。
ですが、海外のエンジニアとの会話やサービスを繰り返し見ているうちに、日本でよく聞く「ワークフロー」と海外でいう「Workflow」が異なるものだと気づきました。
すでに知っている方には、いまさらな話になってしまいますが、「Workflow」は主にプロセスの自動化の意味で使われます。
データの登録をトリガにして後続の処理を次々に回していくようなものです。
その処理の一つの中に「人による承認」などが含まれます場合もあります。
今回、Oktaに追加されたのは「ワークフロー」ではなく「Workflow」の方です。ただ、作りしだいでは上に書いたような処理の一つとして「人による承認」を含めることもできそうだなとは思います。
機能概要
特定のイベントを起点にして、定義されたアクションを実行するフローを作成し、自動実行させる機能です。
■イベント
作成するフローの起点になるものです。
Okta Appsというのは、Okta内部でのイベントですね。
今回の機能紹介ではわかりやすいScheduleを使って紹介します。
Scheduleは定期的にフローを実行する、時間を起点にしたものです。
Child Flowは他のフローと連動する子フロー、API EndpointはOkta上にエンドポイントを登録しフローのトリガにするものみたいです。
Okta以外のアプリケーションをトリガにできるというのも面白いですね。
Office 365 Mailだと、「新しいメールを受信」をトリガにできるようです。
定期的に見に行く作りだと思うので、多少ラグはでそうです。
■アクション
トリガの後続処理です。主にOkta内部の処理や他サービスに対するデータ連携やサービスの内部処理を定義できます。
処理のリレーや値の検証や受け渡し、値の加工なども制御できるようになっているようなので、細かい制御も設計次第でできそうです。
Okta内部の処理も、今までは管理者がGUIを使わなくてはいけなかったり、APIを叩くツールの開発が必要だったりしたものが、定義できたりするので一見の価値ありです。
ゼロトラストモデルを進めるにあたり、SIEM（Security Information and Event Management）を使ったふるまい検知＋セッションの失効やポリシーの割り当て制御なんかも捗りそうです。
今回のレシピ
はじめて作るので無難な、まず動くだろうという確認の元フローをつくっていきます。
あらかじめ登録したユーザに対して、指定した時間にアクティベーションメールを送る
指定した時間じゃなくて、指定した「日時」にした方が実用的でしたね。
あとで気づきました。日時指定も簡単にできます。
Workflowsのダッシュボードにログイン
何をするにしても、まずは新機能を扱える画面に遷移しましょう。
１．Oktaに管理者でログイン
２．「Workflow」メニューの中にある「Workflows console」を選択
３．Workflowsのダッシュボードにログイン完了
Workflows自体アプリケーションとして登録してあるようで、OIDC(Open ID Connect)を使ったシングルサインオンになっています。
Connectionの登録
Connectionというのは、トリガにするにもアクションするにも相手のサービスを登録する必要があります。
今回のレシピでのフローは私が管理しているOktaの中だけの話なので、サービスの新規登録はいらないのかと思っていきや、別サービスとして構成されていますので、Connectionの登録が必要になります。
１．上部メニューで「Settings」を選択
２．「New Connection」を選択
３．ポップアップから「Okta」を選んで「Create」を選択
４．登録情報を入力
Client IDとClient Secretの値ってなんだ？って思った方は、記事をもう少し下にスクロールしてください。どこから取得するのかを書いておきました。
-Client IDとClient Secretの取得方法-
Workflowsが有効になっているテナントには、いつのまにかApplicationが2つ追加されています。
ひとつはWorkflows自体。もうひとつはWorkflowsからOktaのデータを参照、更新するための認可アプリケーションです。
「Okta Workflows OAuth」を選択してください。
「Sign On」タブにClient IDとClient Secretの値があるのでこれを先ほどの画面に入力してください。
５．エラーが出なければConnectionの登録完了
フローの作成
それでは肝心のフローの作成にはいりましょう。
１．「Home」の画面に戻り「Create a Flow Now」を選択
「Default Folder」使いたくない人は個別にFolderを追加してください。
割愛してますが私はDefaultは使わない派なので新しく作りました。
２．トリガとなる「イベント」を登録します。「Add Event」を選択
３．Okta Appsから「Schedule」を選択
４．実行設定を入力して「Save」を選択
一回だけ試せればいいので、時間を絞って実行する設定にしました。
５．次は「アクション」を登録します。「App Action」を選択
６．カタログから「Okta」を選択
７．リストから「Activation User」を選択
８．「Send Email？」のオプションで「Yes」を指定し「Done」を選択
９．対象のユーザを入力
明示的にUsernameを指定しました。本来であれば、ここはグループ制御したり、ユーザの属性にActivateする日付を持たせて自動制御したりするのでしょうね。
１０．フローを有効化
なんと、次のイベントが起動される時間が表示されています。
地味ですがこういうのは結構好みです。
この時、実はまだ実行対象となるユーザを作成していませんでした。
イベントの実行まで、あと7分……すぐさま対象のユーザを準備しました。
実行結果
■実行前
■実行後
ユーザのStatusが「Staged」から「Pending user action」に変わりました。
これはユーザのアクション（初回認証）を待っているという状態です。
そしてユーザにはアクティベーションメールを出す設定になっているので、メールボックスを探してみると……
ちゃんとメールも送信されていました。時間もぴったりでした。
なんて、そもそもこれで失敗するようであれば、機能としてリリースされるはずがないですよね。
まとめ
いかがだったでしょうか？
ノンコードでフローを作成できることを売りにしているだけあって、容易な設定でできたんじゃないかなと思います。
操作性もなかなか良かったです。少なくとも大きな区分けでどこ触ったらいいんだろうみたいな混乱はありませんでした。
設定に関してはServiceNowのWorkflow Editorとかを触りなれている方であれば、困るようなことは少なそうです。
Slackのアクションも試してみたところ、チャンネルへの投稿がリアルタイムにできました。
Oktaのイベントログで怪しい動きをしているものをトリガにメッセージをポストするものとか、これから作ってみようかなと思います。
この記事が気に入ったらサポートをしてみませんか？