(Okta Workflows)ユーザの更新情報の保管

しばらくWorkflowsでいろいろ作って遊んでみようと思います。とりあえずは練習の意味も込めて簡単なものから。
この記事を通して、あーこんなことができるのかーと伝わればいいなと思います。こんなの作って欲しいというご意見も大歓迎です。

今回の課題

ユーザのプロファイル更新情報をため込んでいくだけのものを作りますね。
Oktaはディレクトリなので基本的に歴情報は持たず、常に最新の情報のみが格納されています。更新されたことはログに残るのですが、特定の属性が「いつ」、「なんの値」から「どうやって」更新されたかというのは残りません。

本来Oktaのフロントに人事マスタやIDマスタがあるのであれば、そのあたりもカバーできるのですが、イレギュラーデータでOktaに直接登録したとか、人事マスタの管理者権限がITにないとかの場合に利用できるかなと思います。

テーブルの作成

まずはデータの格納先を作りましょう。Workflowsの強みは内部DBを作成することができることです。外部のスプレットシートに出力することもいいですが、内部DBにため込んでおいても大丈夫です。データを参照するのがWorkflowsの参照権限有無を判断基準においてもいいです。

ちなみにWorkflowsの内部DBはCSVを用いたImport, ExportがGUIでできるのでOktaのデータをAPIツールを開発せずに出力する場合にも活用できます。

話がそれました。。。
テーブルを一つ作って、カラムをセットします。ユーザの全プロファイル分作ってもいいですし、取りたい情報だけ作ってもいいです。
今回は、会社・部署といった組織情報と姓名、あとは更新の起因となった操作者と更新日時を格納することにします。

カラムの作成時には、基本的にカラム名だけ考えておけばいいです。データ型もいくつかありますが、大体においてtext型を使うことがほとんどだと思います。やはりtext型は最強。

フローの作成

今回の作成物は簡単すぎましたね。ちょっと反省。
こんなレベルです。

Flowのトリガ
「User Okta Profile Update」を使います。
Oktaユーザの更新のログが登録されればすぐにFlowがキックされ、そのログの詳細情報がパラメータとしてFlowに渡されます。
今回はOktaのユーザ更新によってリアルタイムにデータを格納するので、これで間違いありません。1日に2回以上更新があっても安心です。

1日に10万件とか更新ある場合は日次バッチをご検討ください。
（※テーブルのレコード上限は10万レコードなので注意）

Flow
冒頭でOktaのログでは特定の属性の値までは取れないと書きました。
そのため「User Okta Profile Update」をトリガとしても、何の属性に更新が加わったのかは取得できません。

そのため、一度OktaにGETのAPIを投げてユーザ情報の取得を行います。
それが「Read User」ですね。

「Read User」はユーザのIDかLogin IDからユーザ情報を取得します。
何度か試してみましたが、IDでもLogin IDでもそんなに性能差は出なかったのでLogin IDにしています。個人的にはID使うほうが好きですが、3回くらい試したらLogin IDの方が平均0.1秒早かったので今回はLogin IDにしました。100回くらい試したら、またレポートするかも。

そして最後に「Create Row」ですね。これは最初に作ったテーブルに取得した情報を格納しているだけです。「Read User」でユーザの更新情報を、「User Okta Profile Update」でいつ、誰が更新したのかを取得し、格納しています。

エラー処理は？

そんなものはない。
いや、普段ならそれなりに作るんだけども。

「Read User」でユーザ取れない場合と、「Create Row」でレコード登録できない場合かな？
更新→即削除だと「Read User」で拾えない可能性はありますが、削除するならケア不要。Workflowsのエラーログでユーザは追えるし。
レコードが10万件に達して登録できない場合はありそうですね。管理者にメール通知とか作っておけばいいかな？それはまた今度。

動作確認

こんな簡単なFlowでもちゃんと仕事をこなします。が、しかし、
この画像を選択したのは失敗だね。黒塗りだらけでセンスがないね。もうちょっと何とかならなかったのか。

せっかくなので、処理時間に注目しておいてくださいね。
OktaのAPIコールはWorkflowsの内部処理と比較して結構時間がかかります。

大きなFlowを作っていくとユーザのプロファイルみたり、グループ取ったり何度もAPIをコールすることになるので1件当たりの処理に10秒とかかかってしまうこともありますので、利用されるユーザ規模に応じてサイジングは行ってくださいね。

登録されたテーブルのスクショも取ったんですが、こっちも黒塗りだらけになったので割愛します。サンプルデータ流せばよかった。

では、また次回