人事システムからOktaにユーザを取り込もう(SmartHR編)
今回はADとかないよーって組織向けのお話。
人事システム(SmartHR)に登録されたユーザをOktaに作っていく内容です。
はじめに
SmartHRいいですね。思わず弊社でも使いたくなりました。
API Tokenの権限の考え方がしっかりしているなと思いました。発行するAPI Tokenごとに各属性項目の参照/更新権限を設計できるのが特に気に入りました。
ご参考:https://developer.smarthr.jp/api/index.html
ITは別に人事情報なんて欲しくないんですよ。欲しいのはちょっとした姓名情報があれば十分なんです。見えるところに置いておかないでください、個人情報ハラスメントやめてください。
※SSOが組まれた人事システムがIdpからログインできてしまうのは棚上げ。
管理者はローカル管理するか厳密な監査で対応してね。
免責事項
今回の記事は以下ルールにしました。多方面への配慮です
・メールアドレスは人事・総務側で決める
・Okta登録時はメールボックス未作成。また個人メアドも利用しない
・入社・退社は人事システムであらかじめデータ登録済み。あと入れなし
・人事イベントに応じたアカウントの登録と失効はするが更新はしない
・性善説
取り込み方式
実はちょっと悩みました。先にも書きましたが、SmartHRのAPIは細かく権限を設定できるので是非使いたい。
ただ、入社日を指定してのユーザ取得は簡単にできるのに、退職日を指定してのユーザ取得ができなかったのでやめました。
(取得方法があればこっそり教えてください)
別にSmartHRのユーザをリスト取得して格納しちゃえばよかったのですが、組織規模によっては無駄に処理が大きくなるのでやめました。
結局Webhookで作ることに
APIの権限設定どこいった。。。
Webhookはリアルタイムに処理できるところがいいですが、エンドポイントにユーザ情報がまるっといくので、そこは注意。
Okta WorkflowsでAPIエンドポイントを作成
Workflowsの使い方を見ていきましょう。
今回はSmartHRのWebhookから受け取ったデータを一時DBに格納するFlowを作っていきます。
1.まずは、Tableをひとつ作成。Oktaに登録したい属性情報のカラムを作成しておきましょう。とりあえずこんな感じ。
2.次に、Flowをひとつ作成。
3.「Add Event」から「API Endpoint」を選択。
4.作成したEventの1「</>」マークを選択してEndpointを作成。
5.ここで表示されるURLとClient TokenはSmartHR側で登録します。
6.Webhookのbodyから受けとりたいデータを設定していきます。データの構造を見ながらやるのがポイントです。
7.人事システムを新規導入なんてことは稀有だと思いますので、ガツンと初回移行するか、徐々に紐づけていくか。今回は徐々に紐づけていく方式を選択。SmartHR側の更新・新規のイベントを受け、ユーザをDBに格納します。
・DBに特定の従業員No.がない場合、新規レコードとして登録
・DBに特定の従業員No.がある場合、そのレコードを人事情報で更新する
8.一連の流れでOktaへのユーザ登録までやらないのは、入社日にアカウントを作りたいと言った要望も多いだろうと思い、登録・失効のタイミングは柔軟に設定できるようにしました。
SmartHRでWebhookを登録
1.「共通設定」から「アプリケーション連携」を選択します。
2.「アクセストークン」に後ろ髪を引かれながら、「Webhook」を選択します。
3.先ほどOkta Workflowsで取得したURLとClient Tokenを登録します。
送信のトリガーは「従業員の追加」・「従業員の更新」にチェックをしておきます。ここは各組織による運用次第だと思うので、収まりがいいものを選択してください。
Oktaへの登録Flow
1日1回8:00にスケジュールされたFlowを作成します。
内容はこんな感じ。
1.本日日付けを使って、DBから本日入社のユーザリストを取得。
2.ユーザリストに対し子フローを実行。
3.ユーザデータに対しメールアドレスがない場合はメールアドレスを付与
4.初期パスワードを発行
※完全ランダムでもいいが「小文字L」など紛らわしいものを避けるため数字メインのものに(一応NIST準拠)
5.人事データを元にした情報でOktaにアカウントを作成。
6.管理者に対し、登録情報をメール通知
割愛しますが、ユーザ無効化のFlowも同じように作っています。
無効化Flowは退職日の18:00時にスケジュール。退職の挨拶メール出さないといけないから、ギリギリまでITサービスを変えるようにしておかないとね。
おわりに
今回はかなりざっくりと作りましたが、本来人事データとITデータの結合は結構大変です。組織のユーザ規模や運用、データの整備有無、認可の制御など検討していくと100倍くらい複雑な仕様になることもしばしば。
エンドユーザへの影響を避けて既存運用を残していくか、ドラスティックに社内ポリシーごと変えていくか、人事とITの統合は悩ましいところだと思います。
この記事が気に入ったらサポートをしてみませんか?