こんにちは！たつみんです！
今日は検証ブログ記事というよりはコラムっぽい内容です。コーヒーでも飲みながらリラックスして読んでもらえたら嬉しいです。
はじめに
OktaはIdPとしてユーザーに対してSaaSなどに対する認証・認可を担います。この時にどのユーザーにどのようなシステムを利用させるかを検討する必要があります。
例えば営業部門所属のユーザーは必ずSalesforceに、開発部門所属のユーザーは必ずJIRAにアクセスする必要があるというように所属部門によって利用するシステムが決まっている場合は以下の例のようにすることで手動の操作を極力減らすことが可能になります。
- ユーザープロファイルで部署情報を持たせておきます。営業部門ならDepartment属性に「Sales」を入力するなどを行います。
- Oktaグループ「Sales members」を作成し、グループルールでDepartment属性がSalesであった場合に自動的に追加する設定をします。
- SalesforceアプリケーションへOktaグループ「Sales member」をグループアサインとして設定します。
これで大きく自動化できたように思えますよね？でも実は違います。以下のポイントも考慮するとよりよくなります。
- ユーザーの部署異動が発生した時のメンテナンスをどうするか？
- 入退社というユーザーのはじまりとおわりについてはどうするか？
入社・属性変更（部署異動や役職変更）そして退社といったこれら全てを含めて、IDライフサイクルと呼ばれています。
入退社や部署異動の情報はHR部門が掌握していることが多く、近年ではHR部門でのSaaSの利用が一般的になってきました。海外のHR SaaSではWorkday,BambooHRなどがありますが、日本国内においてはSmartHR,ジョブカン,ジンジャー,カオナビ,freeeなど多数のHR SaaSが存在します。
このようなHR SaaSをOktaのユーザーIDの源泉として利用できれば入退社含む対応の自動化が可能となります。
HR-DrivenなIT Provisioningとは上記なようなHR SaaSを起点にITシステムに対してProvisioningを行うことです。
HR-DrivenなIT Provisioningの実現方法
前置きが長くなりましたがどのように実現するのかについて解説します。大まかに以下の2パターンで対応することができます。
- SCIM連携を利用する
- APIやWebhookを利用する
SCIM連携を利用する
一般的なSCIM連携のイメージとして多くの場合はOktaを起点としてその他のSaaSに対してユーザーの作成や属性の更新、ユーザーの無効化などを行いますが、HR-Drivenな構成ではHR SaaSを起点としてOktaに対してユーザーの作成や属性の更新、ユーザーの無効化を行います。
上記で挙げたHR SaaSの中ではWorkday,BambooHR,SmartHRが対応しています。
OktaとSmartHRのSCIM連携については検証ブログ記事を以前執筆しておりますのでご参照ください。
SCIM連携のメリットは連携方法が確立されており、画面の提示されているオプションを設定することで比較的容易に構成が行えることです。ただしデメリットとしてはオプションとして用意されていない部分は設定ができないことです。
APIやWebhookを利用する
SCIM連携に対応していないHR SaaSの場合はAPIやWebhookで連携できる可能性を探ってみましょう。また、SCIM連携のデメリットである用意されていないオプションを活用したい場合もAPIやWebhookの検討対象となります。
もちろんHR SaaSがAPIやWebhookを公開していない場合はなにもできないのですが、APIやWebhookを公開している場合も多くなってきました。
APIが利用可能な場合は実行環境を用意しHR SaaSのAPIを利用し、HR SaaSに登録されているユーザー情報を定期的に取得するような構成を考えます。実行環境は様々な手段が考えられますがOktaであればOkta Workflowsの利用を検討してみましょう。
Okta Workflowsでは取得したデータを基にOktaユーザーを新規作成したり、既存のOktaユーザーの属性値を更新したりすることが可能です。
OktaからHR SaaSに情報を取得しに行くイメージです。
Webhookが利用可能である場合はHR SaaS側でユーザーが作成された場合や登録されている情報が更新された場合にその情報をOktaと連携するというタイムリーな連携を行うことが可能です。この場合も実行環境としてはOkta Workflowsを活用できます。
Okta WorkflowsでWebhookを受け取る設定をすれば、あとはAPI連携時とさほど変わらずに設定を行うことができます。
HR SaaSからOktaに通知するようなイメージです。
下記の検証ブログ記事ではOkta WorkflowsのSmartHR Connectorに焦点を当てていますが、SmartHRに限らず他のHR SaaSの場合であってもAPIやWebhookを活用してOktaと連携するという考え方としては応用が可能かと思います。ぜひご参照ください。
システム連携ができればそれでいいんだっけ？
答えはいいえです。
そもそもHR SaaSは情シス部門ではなくHR部門がメインで利用し、情報の登録や更新を行なっている場合がほとんどだと思います。
システム間の連携ができてもそれで終わりではなく、HR部門と情報の登録・更新のタイミングの認識合わせを行う必要があります。場合によってはHR部門としては不要だと考えている属性項目を登録してもらう必要性もあるかもしれません。
例えば、HR部門ではHR SaaSへの入力は入社日の当日でもよいと考えていたり、退職予定者も当日やもしかしたら退職日を過ぎてからHR SaaSに反映しているかもしれません。
属性項目としてローマ字表記がHR SaaSではデフォルトで用意されていないために入力されていないということもありがちです。
このような作業はHR-DrivenなIT Provisioningを行うための基盤作りの一部です。正直この作業は地味ですが全体最適を目指して地道に頑張りましょう。
私は以前の職場でHR部門とGoogleスプレッドシートで入退社の情報のやりとりを行なっていましたが、APIが利用できるSaaSに入れ替えてシステム間連携を行いました。当時はHR部門との認識合わせに苦労をしましたが結果として人間が介在する部分が最小化されたので曖昧なやりとりが減り、阿吽の呼吸が必要だった調整業務を標準化することができました。
最後に
HR-DrivenなIT Provisioningができるとスマートでかっこよく感じますよね。でもそこに至るまでは泥臭いこともたくさんあります。ITで苦労することもありますが最後はITで幸せになって笑っていたい。ふと最近そんなことを思うようになりました。
だいぶポエミーになってきたので今日はこの辺で！バイバーイ?
